[ANNOUNCE] String changes made in Evolution, GtkHtml
Hi, STRING CHANGES === The strings mentioned in following revisions have been modified for translation: Changes in Evolution: SVN revision: http://svn.gnome.org/viewvc/evolution?view=revision&revision=34806 Reference: http://bugzilla.gnome.org/show_bug.cgi?id=496301 SVN revision: http://svn.gnome.org/viewvc/evolution?view=revision&revision=34810 Reference: http://bugzilla.gnome.org/show_bug.cgi?id=498095 (Change in mnemonics) Changes in GtkHtml: -- SVN revision: http://svn.gnome.org/viewvc/gtkhtml?view=revision&revision=8681 Reference: http://bugzilla.gnome.org/show_bug.cgi?id=498089 (Change in mnemonics) Please do let me know if I need to furnish any more information. Thanks and regards, Suman Manjunath <[EMAIL PROTECTED]> ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: HTML tags in translatable strings - glade
On Fri, 2008-01-11 at 20:47 -0300, Jonh Wendell wrote: > Hi, folks. > > I'd like some help/direction on how to fix bug 498402 [1]. > It's about strings like 'Enter a name for this connection'. > > These strings come from glade, and are marked for translation. I know i > should cut the html tags, but is there a way to do this without need of > coding? Can glade/intltools strip those marks away automagically? Rhythmbox and Totem work around that by using "boldify" and "italicise" functions on the labels that need it. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[ANNOUNCE] String changes made in Evolution
Hi, STRING CHANGES === The strings mentioned in following revision have been added for translation: SVN revision: http://svn.gnome.org/viewvc/evolution?view=revision&revision=34816 Reference: http://bugzilla.gnome.org/show_bug.cgi?id=333695 Please do let me know if I need to furnish any more information. Thanks and regards, Suman Manjunath <[EMAIL PROTECTED]> ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Making the next gnome-applets depend on libgweather.
2008/1/14 Owen Taylor <[EMAIL PROTECTED]>: > > Comments, criticisms? > > I'm slightly concerned by this ... libgweather does something pretty > interesting (to a small set of consumers) but the API is no way ready > for any sort of freezing. It has serious namespace and memory management > issues, among other things. > > I don't think there is any proposal here to make libgweather part of the > platform, but a) is there clear messaging about the API status? b) how > would a transition to an incompatible new version be handled? Pretty much like for any other instable api, I think. Users will have to check for a version they support and will have to be ported. Do you want us to do the -DI_SWEAR_I_KNOW_LIBGWEATHER_IS_UNSTABLE dance ? That is easy enough, if you think it helps. Matthias ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Making the next gnome-applets depend on libgweather.
On Sun, 2008-01-13 at 21:13 +1300, Callum McKenzie wrote: > I have a version of the gnome-applets code base that uses an external > version of libgweather. I would like use this for the 2.21.5 release, so > I'm asking if anyone has serious objections. > > Obviously this relies on Federico getting a tarball release of > libgweather out the door (I'll be making my decisions at approximately > 9am UTC on the 14th of January, if a release isn't done by then I will > wait - possibly until 2.23 since we're getting on in the cycle). > > The effects this should have: > > i18n: No new strings, but some files with strings and the massive > Locations.xml are moving. I think everything has been migrated properly, > so translators should merely have to point their tools at a new place. > > Documentation: None, there is no UI (although the gweather applet > location selection UI may eventually be migrated) and the API isn't > actually documented. > > Bugzilla: Bugs about locations and the like will almost certainly end up > getting filed against the gweather applet rather than libgweather. This > is probably something we'll just have to live with - its the same with > all libraries. > > In principle this shouldn't be a major change since it is effectively > splitting an existing code-base in two rather than introducing a new > dependency. However, I don't want to do anything without asking first. > > Current SVN trunk has the relevant code - although I'm prepared to > revert (I managed to create a branch with the code and then commit the > same code to trunk). > > Comments, criticisms? I'm slightly concerned by this ... libgweather does something pretty interesting (to a small set of consumers) but the API is no way ready for any sort of freezing. It has serious namespace and memory management issues, among other things. I don't think there is any proposal here to make libgweather part of the platform, but a) is there clear messaging about the API status? b) how would a transition to an incompatible new version be handled? - Owen signature.asc Description: This is a digitally signed message part ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Making the next gnome-applets depend on libgweather.
On Mon, 2008-01-14 at 08:56 -0500, Matthias Clasen wrote: > 2008/1/14 Owen Taylor <[EMAIL PROTECTED]>: > > > > Comments, criticisms? > > > > I'm slightly concerned by this ... libgweather does something pretty > > interesting (to a small set of consumers) but the API is no way ready > > for any sort of freezing. It has serious namespace and memory management > > issues, among other things. > > > > I don't think there is any proposal here to make libgweather part of the > > platform, but a) is there clear messaging about the API status? b) how > > would a transition to an incompatible new version be handled? > > Pretty much like for any other instable api, I think. > Users will have to check for a version they support and will have to be > ported. > > Do you want us to do the -DI_SWEAR_I_KNOW_LIBGWEATHER_IS_UNSTABLE dance ? > That is easy enough, if you think it helps. While that dance seems annoyingly pointless at times, I think it does serve some small purposes: - Everybody who compiles the modules using the unstable API sees it repeatedly and it hopefully sinks into the unconscious - It can be pointed to when people start complaining after an API break. - Owen signature.asc Description: This is a digitally signed message part ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Making the next gnome-applets depend on libgweather.
Here is a patch for the unstable dance. Index: libgweather/weather.h === --- libgweather/weather.h (revision 37) +++ libgweather/weather.h (working copy) @@ -13,6 +13,12 @@ * */ + +#ifndef GWEATHER_I_KNOW_THIS_IS_UNSTABLE +#error "libgweather should only be used if you understand that it's subject to change, and is not supported as a fixed API/ABI or as part of the platform" +#endif + + #include G_BEGIN_DECLS Index: libgweather/gweather-gconf.h === --- libgweather/gweather-gconf.h (revision 37) +++ libgweather/gweather-gconf.h (working copy) @@ -26,6 +26,12 @@ #ifndef __GWEATHER_GCONF_WRAPPER_H__ #define __GWEATHER_GCONF_WRAPPER_H__ + +#ifndef GWEATHER_I_KNOW_THIS_IS_UNSTABLE +#error "libgweather should only be used if you understand that it's subject to change, and is not supported as a fixed API/ABI or as part of the platform" +#endif + + #include #include #include Index: libgweather/gweather-prefs.h === --- libgweather/gweather-prefs.h (revision 37) +++ libgweather/gweather-prefs.h (working copy) @@ -11,6 +11,12 @@ #ifndef __GWEATHER_PREFS_H_ #define __GWEATHER_PREFS_H_ + +#ifndef GWEATHER_I_KNOW_THIS_IS_UNSTABLE +#error "libgweather should only be used if you understand that it's subject to change, and is not supported as a fixed API/ABI or as part of the platform" +#endif + + #include #include Index: README === --- README (revision 37) +++ README (working copy) @@ -0,0 +1,11 @@ +libgweather is a library to access weather information from online +services for numerous locations. + +libgweather isn't supported in the devel platform, which means OS vendors +won't guarantee the API/ABI long-term, but authors of open source apps +should feel free to use libgweather as users can always recompile against +a new version. + +To use libgweather in your code, you need to define the +GWEATHER_I_KNOW_THIS_IS_UNSTABLE preprecessor symbol, e.g. by adding +-DGWEATHER_I_KNOW_THIS_IS_UNSTABLE to your CFLAGS. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Making the next gnome-applets depend on libgweather.
On Mon, 2008-01-14 at 09:40 -0500, Matthias Clasen wrote: > Here is a patch for the unstable dance. Thanks, merged. I see that Callum already pushed a 2.21.1 tarball, so I'll upload a 2.21.2 one with your changes (I already fixed up the .c files as well). Federico ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Making the next gnome-applets depend on libgweather.
On Mon, 2008-01-14 at 12:11 -0600, Federico Mena Quintero wrote: > On Mon, 2008-01-14 at 09:40 -0500, Matthias Clasen wrote: > > Here is a patch for the unstable dance. > > Thanks, merged. I see that Callum already pushed a 2.21.1 tarball, so > I'll upload a 2.21.2 one with your changes (I already fixed up the .c > files as well). > And I'm in the process of preparing a new gnome-applets that includes the required #defines. - Callum ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
gimp-gap 2.4 ahead
Hi, for your information: We have created a gap-2-4 branch and intend to do a 2.4.0 release of the GIMP Animation package in about a week. This branch was created from the 2.2 branch, so it provides basically the same functionality as the GAP 2.2.2 release. It will however depend on GIMP 2.4 and lots of fixes have been done to make GAP work better with the GIMP 2.4 release. Developers and users, please give the gap-2-4 branch some testing and make sure that any problems are reported at bugzilla.gnome.org for the gimp-gap product. Translators, please update the information on l10n.gnome.org and help us to ship gimp-gap 2.4.0 with lots of uptodate translations. Thanks a lot for your attention. Sven ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
String/UI changes in Accerciser release
Hi, We have some string additions and UI changes to Accerciser in the latest dev release (and in trunk). They mostly involve a new plugin. The scrollkeeper docs have also been updated. Thanks! Eitan. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String/UI changes in Accerciser release
Hi, El lun, 14-01-2008 a las 12:58 -0800, Eitan Isaacson escribió: > Hi, > > We have some string additions and UI changes to Accerciser in the latest > dev release (and in trunk). > They mostly involve a new plugin. The scrollkeeper docs have also been > updated. Could you please fix bug http://bugzilla.gnome.org/show_bug.cgi?id=508778 so I can finish accerciser translation? Without knowing what are the variables I can't translate it properly into Spanish. Thank you. -- Jorge González González <[EMAIL PROTECTED]> Weblog: http://aloriel.no-ip.org Fotolog: http://www.flickr.com/photos/aloriel ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
String and UI changes in gnome-panel (clock applet)
Hi, Federico has merged intlclock with the clock applet in the panel. It means that there are new strings and a different UI. There will still be some changes in the near future to fix some issues, and improve the UI. Vincent -- Les gens heureux ne sont pas pressés. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[ANNOUNCE] UI changes made in gnome-spell
Hi.. UI CHANGES == A new button has been added to the spell-check UI. This provides an option to 'replace all' instances of an incorrect spelling. SVN revision: http://svn.gnome.org/viewvc/gnome-spell?view=revision&revision=427 Reference: http://bugzilla.gnome.org/show_bug.cgi?id=343972 Screenshots have been attached here: http://bugzilla.gnome.org/show_bug.cgi?id=343972#c16 (before) http://bugzilla.gnome.org/show_bug.cgi?id=343972#c17 (after) Please do let me know if I need to furnish any more information. Thanks and regards, Suman Manjunath <[EMAIL PROTECTED]> ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: gimp-gap 2.4 ahead
Le lundi 14 janvier 2008 à 20:59 +0100, Sven Neumann a écrit : > Hi, > > for your information: We have created a gap-2-4 branch and intend to do > a 2.4.0 release of the GIMP Animation package in about a week. This > branch was created from the 2.2 branch, so it provides basically the > same functionality as the GAP 2.2.2 release. It will however depend on > GIMP 2.4 and lots of fixes have been done to make GAP work better with > the GIMP 2.4 release. > > Developers and users, please give the gap-2-4 branch some testing and > make sure that any problems are reported at bugzilla.gnome.org for the > gimp-gap product. > > Translators, please update the information on l10n.gnome.org and help us > to ship gimp-gap 2.4.0 with lots of uptodate translations. l10n.gnome.org updated. Thanks. Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
String changes in evolution
Hi. I fixed a couple of instances of long descriptions missing a full stop in evolution's schemas yesterday so you may want to update your translations. Cheers Kjartan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n