Re: Nautilus brake string freeze
On Wed, Mar 11, 2015 at 1:40 PM, Alexandre Franke alexandre.fra...@gmail.com wrote: So I guess you are now asking for a freeze exception. It would help if you gave us the actual strings and the number of strings added. 5 new strings: Action menu Open action menu Open view menu Search files View menu Given the importance for a11y, the ease for translating those and the fact that it's relatively early in the break, I give you i18n approval 1/2. -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Nautilus brake string freeze
On Wed, Mar 11, 2015 at 1:07 PM, Carlos Soriano Sánchez carlos.sorian...@gmail.com wrote: Hi all, A11y people wanted https://bugzilla.gnome.org/show_bug.cgi?id=745967 fixed for 3.16, and I wanted that fix for the .90 I will do in a few hours. I fixed it, but also, I pushed without asking for string freeze break (I forgot about the string freeze). The commit is https://git.gnome.org/browse/nautilus/commit/?id=7afbac0a64f1734842ed64e333c9147de1cdbcd9 Sorry for that Hi, So I guess you are now asking for a freeze exception. It would help if you gave us the actual strings and the number of strings added. -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Nautilus brake string freeze
2/2 from i18n El 11/03/2015 13:49, Alexandre Franke alexandre.fra...@gmail.com escribió: On Wed, Mar 11, 2015 at 1:40 PM, Alexandre Franke alexandre.fra...@gmail.com wrote: So I guess you are now asking for a freeze exception. It would help if you gave us the actual strings and the number of strings added. 5 new strings: Action menu Open action menu Open view menu Search files View menu Given the importance for a11y, the ease for translating those and the fact that it's relatively early in the break, I give you i18n approval 1/2. -- Alexandre Franke ___ gnome-i18n mailing list gnome-i...@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
String freeze break request for evolution-data-server (3.12)
I'd like to backport some fixes from Evolution master to 3.12 which fix GSSAPI HTTP authentication and error reporting¹. Previously, if we were unable to translate an error number into a string we would end up with an untranslated message of the form 'Unknown error code' or 'Unknown code %d' from libcom_err. Now the code is fixed, we end up handling the lookup failure in EDS, and report it slightly more coherently as _((Unknown GSSAPI mechanism code: %x)) So we have a new untranslated string... in place of a string which was previously not only untranslated but untranslatable. In a case that should hopefully never happen now that we're actually looking up the error codes the right way, and where the message text wasn't giving the user much information anyway (only the number might *possibly* be helpful. On the whole, I'm not going to lose sleep over it being untranslated :) -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ¹ Specifically commits a523ac27, bd843434, f98caca8, 581c32aa. smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: String freeze break request for evolution-data-server (3.12)
On Tue, Sep 9, 2014 at 1:23 PM, David Woodhouse dw...@infradead.org wrote: I'd like to backport some fixes from Evolution master to 3.12 which fix GSSAPI HTTP authentication and error reporting¹. Previously, if we were unable to translate an error number into a string we would end up with an untranslated message of the form 'Unknown error code' or 'Unknown code %d' from libcom_err. Now the code is fixed, we end up handling the lookup failure in EDS, and report it slightly more coherently as _((Unknown GSSAPI mechanism code: %x)) So we have a new untranslated string... in place of a string which was previously not only untranslated but untranslatable. In a case that should hopefully never happen now that we're actually looking up the error codes the right way, and where the message text wasn't giving the user much information anyway (only the number might *possibly* be helpful. On the whole, I'm not going to lose sleep over it being untranslated :) 1/2 from i18n. -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
string freeze break request for epiphany
hi all; I filed this bug[0] for epiphany to update the incognito mode string to include a warning about the fact that browsing incognito won't prevent other actors from tracking your activity. I think it's a good thing to notify the users about this detail, and other browsers do the same. there are two strings to translate, so I'm asking for a string freeze break to land this before 3.14. [0]: https://bugzilla.gnome.org/show_bug.cgi?id=736065 ciao, Emmanuele. -- http://www.bassi.io [@] ebassi [@gmail.com] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: string freeze break request for epiphany
Second +1 from i18n. Cheers El 05/09/2014 13:21, Alexandre Franke alexandre.fra...@gmail.com escribió: On Fri, Sep 5, 2014 at 1:12 PM, Emmanuele Bassi eba...@gmail.com wrote: hi all; I filed this bug[0] for epiphany to update the incognito mode string to include a warning about the fact that browsing incognito won't prevent other actors from tracking your activity. I think it's a good thing to notify the users about this detail, and other browsers do the same. there are two strings to translate, so I'm asking for a string freeze break to land this before 3.14. [0]: https://bugzilla.gnome.org/show_bug.cgi?id=736065 +1 for i18n. Next time it would be a good idea to copy the strings in your email. :-) -- Alexandre Franke ___ release-t...@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: string freeze break request for epiphany
hi Alexandre; you're absolutely right. just for reference to the i18n teams, the strings are: You are currently browsing emincognito/em. Pages viewed in this mode will not show up in your browsing history and all stored information will be cleared when you close the window. Any files you download will be kept. and: It is important to know that incognito mode will not hide your activity from your employer, your Internet Service Provider, your government, or the websites that you visit. ciao, Emmanuele. On 5 September 2014 12:20, Alexandre Franke alexandre.fra...@gmail.com wrote: On Fri, Sep 5, 2014 at 1:12 PM, Emmanuele Bassi eba...@gmail.com wrote: hi all; I filed this bug[0] for epiphany to update the incognito mode string to include a warning about the fact that browsing incognito won't prevent other actors from tracking your activity. I think it's a good thing to notify the users about this detail, and other browsers do the same. there are two strings to translate, so I'm asking for a string freeze break to land this before 3.14. [0]: https://bugzilla.gnome.org/show_bug.cgi?id=736065 +1 for i18n. Next time it would be a good idea to copy the strings in your email. :-) -- Alexandre Franke -- http://www.bassi.io [@] ebassi [@gmail.com] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
String Freeze
Hello all, The string freeze has set in, no string changes may be made without confirmation from the i18n team and notification to release team, translation team, and documentation team. From this point, developers should concentrate on stability and bug-fixing. Translators can work without worrying that the original English strings will change, and documentation writers can take accurate screenshots. For the string freezes explained, and to see which kind of changes are not covered by freeze rules, check this page: http://live.gnome.org/TranslationProject/HandlingStringFreezes. It's also important to make sure that your module's po/POTFILES.in and po/POTFILES.skip are correct and uptodate and that no source files are lacking from these files. For more information about 3.5, the full schedule, the official module lists and the proposed module lists, please see our colorful 3.5 page: http://www.gnome.org/start/unstable For a quick overview of the GNOME schedule, please see: http://live.gnome.org/Schedule Cheers, Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
String freeze and forgotten files
Hi, I just activated string freeze detection on l10n.gnome.org this morning. I'd like to warn some maintainers about missing files in po/POTFILES.in: * warn ekiga: There are some missing files from POTFILES.in: o plugins/loudmouth/loudmouth-dialect.cpp * warn evolution-data-server: There are some missing files from POTFILES.in: o libedataserverui/e-passwords-win32.c * warn glade: There are some missing files from POTFILES.in: o plugins/gtk+/glade-gtk-grid.c o plugins/gtk+/glade-gtk-table.c * warn glib: There are some missing files from POTFILES.in: o gio/gapplicationcommandline.c o gio/gdummytlsbackend.c o gio/gtcpwrapperconnection.c * warn gtk+: There are some missing files from POTFILES.in: o gtk/gtkanimationdescription.c o gtk/gtkbindings.c o gtk/gtkmodifierstyle.c o gtk/gtkstyleprovider.c Please fix it ASAP. You don't need approval to fix them, as they are existing forgotten strings. Cheers, Claude -- www.2xlibre.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
String freeze break in gnome-volume-manager
Hi Jeffrey, Your commit on February 24th to gnome-volume-manager broke the string freeze: http://cvs.gnome.org/viewcvs/gnome-volume-manager/src/manager.c?r1=1.130r2=1.131 Please revert this change and instead consider: - branching for Gnome 2.14 before introducing this change - asking for string freeze break approval (highly unlikely to get one from me, if the sole reason is the one in bug #326955[1]), following the procedure outlined on: http://live.gnome.org/ReleasePlanning/Freezes - putting a patch in Bugzilla and marking it as accepted_commit-after-freeze and committing it when you branch Cheers, Danilo [1] http://bugzilla.gnome.org/show_bug.cgi?id=326955 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: String freeze break in gnome-volume-manager
Would another accepted solution be to fix all the msgid strings in the po files to reflect the change made? e.g. s/_Ignore/Ig_nore/ ? Jeff On Mon, 2006-02-27 at 17:13 +0100, Danilo Šegan wrote: Hi Jeffrey, Your commit on February 24th to gnome-volume-manager broke the string freeze: http://cvs.gnome.org/viewcvs/gnome-volume-manager/src/manager.c?r1=1.130r2=1.131 Please revert this change and instead consider: - branching for Gnome 2.14 before introducing this change - asking for string freeze break approval (highly unlikely to get one from me, if the sole reason is the one in bug #326955[1]), following the procedure outlined on: http://live.gnome.org/ReleasePlanning/Freezes - putting a patch in Bugzilla and marking it as accepted_commit-after-freeze and committing it when you branch Cheers, Danilo [1] http://bugzilla.gnome.org/show_bug.cgi?id=326955 -- Jeffrey Stedfast Evolution Hacker - Novell, Inc. [EMAIL PROTECTED] - www.novell.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
string freeze explanation on the wiki
Frustrated by my inability to easily find a string freeze explanation, I created http://live.gnome.org/MaintainersCorner_2fStringFreeze based on a mail from Christian Rose during the 2.9 cycle. Feel free to further change the page or suggest places in the wiki to link from to this page. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ -*- thomas (dot) apestaart (dot) org -*- I love the way you love but I hate the way I'm supposed to love you back -*- thomas (at) apestaart (dot) org -*- URGent, best radio on the net - 24/7 ! - http://urgent.fm/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: string freeze explanation on the wiki
On 1/10/06, Thomas Vander Stichele [EMAIL PROTECTED] wrote: Frustrated by my inability to easily find a string freeze explanation, I created http://live.gnome.org/MaintainersCorner_2fStringFreeze based on a mail from Christian Rose during the 2.9 cycle. Feel free to further change the page or suggest places in the wiki to link from to this page. We had linked to Christian's email from http://live.gnome.org/ReleasePlanning_2fFreezes (under the Approving/Rejecting Freezes section; seems like it'd be better under the string section). Maybe we should move your string freeze page to go with the other stuff and then link from MaintainersCorner to all the freeze info? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
evince string freeze breackage
My apologies, I broke the string freeze in this evince commit: http://cvs.gnome.org/viewcvs/evince/ps/ps-document.c?r1=1.55r2=1.56 I wanted to commit ASAP because of the evince release and I forgot that it changed some strings. sorry. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carlos Garcia Campos a.k.a. KaL [EMAIL PROTECTED] [EMAIL PROTECTED] http://carlosgc.linups.org =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: evince string freeze breackage
On 8/17/05, Carlos Garcia Campos [EMAIL PROTECTED] wrote: My apologies, I broke the string freeze in this evince commit: http://cvs.gnome.org/viewcvs/evince/ps/ps-document.c?r1=1.55r2=1.56 I wanted to commit ASAP because of the evince release and I forgot that it changed some strings. sorry. Thanks for letting us know (though there's no need to email d-d-l, and release-team should be cc'ed -- see http://live.gnome.org/ReleasePlanning/TwoPointEleven). You'll need to either get approval from Christian or Danilo or back out the change. You may want to include a brief summary of why the change is important to help them make the decision, and include a link to the bug report where it was discussed (http://bugzilla.gnome.org/show_bug.cgi?id=309915, right?). Cheers, Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: evince string freeze breackage
On Wed, 2005-08-17 at 19:23 +0200, Danilo Šegan wrote: Hi Carlos, Today at 18:45, Carlos Garcia Campos wrote: My apologies, I broke the string freeze in this evince commit: http://cvs.gnome.org/viewcvs/evince/ps/ps-document.c?r1=1.55r2=1.56 Nice that you reported it yourself. Can you now tell us why is introducing these three strings Error while decompressing file\n Cannot open file.\n Failed to load document actually necessary and important at this stage of the game? They are used only if g_locale_to_utf8 fails to convert filename to UTF-8 for display purposes, right? (you can reuse the same string with something like g_strdup_printf(_(Cannot open file: %s\n), ?) until string freeze ends.) Wouldn't those be available in the GError passed back by g_locale_to_utf8 anyway? And if those are user-facing messages, they sure could use some love. Cheers --- Bastien Nocera [EMAIL PROTECTED] I'll hear whispering: 'There's that Renfro, the stupid motherfucker who forgot to untie the boat.' -- Brad Renfro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: evince string freeze breackage
El mié, 17-08-2005 a las 19:23 +0200, Danilo Šegan escribió: Hi Carlos, Today at 18:45, Carlos Garcia Campos wrote: My apologies, I broke the string freeze in this evince commit: http://cvs.gnome.org/viewcvs/evince/ps/ps-document.c?r1=1.55r2=1.56 Nice that you reported it yourself. Can you now tell us why is introducing these three strings Error while decompressing file\n Cannot open file.\n Failed to load document if we can't convert a filename to a utf-8 string, we prefer not to show that filename. actually necessary and important at this stage of the game? maybe not, but I guess evince maintainers should answer it. They are used only if g_locale_to_utf8 fails to convert filename to UTF-8 for display purposes, right? (you can reuse the same string with something like g_strdup_printf(_(Cannot open file: %s\n), ?) until string freeze ends.) yes Can you please revert these string additions or please provide more evidence to why is this really beneficial. Thanks. I wanted to commit ASAP because of the evince release and I forgot that it changed some strings. sorry. Regarding recent when freeze actually begins[1] thread, are you saying that this is about a release done for the Beta2? Beta2 was already announced on August 11th, and the patch was committed only on August 16th. oh no, I meant new evince release to fix building problems: http://bugzilla.gnome.org/show_bug.cgi?id=309915#c10 [1]http://mail.gnome.org/archives/gnome-i18n/2005-August/msg00160.html Cheers, Danilo -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carlos Garcia Campos a.k.a. KaL [EMAIL PROTECTED] [EMAIL PROTECTED] http://carlosgc.linups.org =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: evince string freeze breackage
On Wed, 2005-08-17 at 19:40 +0200, Carlos Garcia Campos wrote: El mié, 17-08-2005 a las 19:23 +0200, Danilo Šegan escribió: Hi Carlos, Today at 18:45, Carlos Garcia Campos wrote: My apologies, I broke the string freeze in this evince commit: http://cvs.gnome.org/viewcvs/evince/ps/ps-document.c?r1=1.55r2=1.56 Nice that you reported it yourself. Can you now tell us why is introducing these three strings Error while decompressing file\n Cannot open file.\n Failed to load document if we can't convert a filename to a utf-8 string, we prefer not to show that filename. Glib has g_filename_display_name() for the purpose of converting filenames into something that can be displayed to the user. It tries to handle conversion failures gracefully. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: evince string freeze breackage
El mié, 17-08-2005 a las 14:34 -0400, Matthias Clasen escribió: On Wed, 2005-08-17 at 19:40 +0200, Carlos Garcia Campos wrote: El mié, 17-08-2005 a las 19:23 +0200, Danilo Šegan escribió: Hi Carlos, Today at 18:45, Carlos Garcia Campos wrote: My apologies, I broke the string freeze in this evince commit: http://cvs.gnome.org/viewcvs/evince/ps/ps-document.c?r1=1.55r2=1.56 Nice that you reported it yourself. Can you now tell us why is introducing these three strings Error while decompressing file\n Cannot open file.\n Failed to load document if we can't convert a filename to a utf-8 string, we prefer not to show that filename. Glib has g_filename_display_name() for the purpose of converting filenames into something that can be displayed to the user. It tries to handle conversion failures gracefully. I've just fixed it by using g_filename_display_name, thank you. Sorry for the problems caused, I'll be more careful in the future Matthias Greetings, -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carlos Garcia Campos a.k.a. KaL [EMAIL PROTECTED] [EMAIL PROTECTED] http://carlosgc.linups.org =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-session string freeze breakage
Hi, Thanks for that. I've created a gnome-2-10 branch now and reverted those changes from the branch. I did it that way, rather than going back and branching before the changes, so as to make sure the gnome-2-10 branch got all the translations which have been updated since then. Cheers, Mark. On Fri, 2005-05-06 at 11:43 +0200, Martin Willemoes Hansen wrote: There has been an unannounced string freeze breakage in the string frozen gnome-session for gnome-2-10, it seems that gnome-session has not branched for gnome-2.10 yet. Two new strings has been added. These are the messages: #: ../gnome-session/gnome-session.schemas.in.h:8 msgid Selected option in the log out dialog #: ../gnome-session/gnome-session.schemas.in.h:12 msgid This is the option that will be selected in the logout dialog, valid values are \logout\ for logging out, \shutdown\ for halting the system and \restart\ for restarting the system. The relevant part of the log for gnome-session.schemas seems to be this: revision 1.3 date: 2005/04/26 10:56:50; author: carlosg; state: Exp; lines: +11 -0 2005-04-26 Carlos Garnacho Parro [EMAIL PROTECTED] Fix for #76791 * gnome-session.schemas.in: new key for handling default selected option in the logout dialog * logout.c: implement option saving/restoring * headers.h: add the new key define http://cvs.gnome.org/viewcvs/gnome-session/gnome-session/gnome-session.schemas.in?r1=1.2r2=1.3 No warning had been given in advance for this addition. GNOME is in string freeze, which means that prior announcement and approval of string changes and string additions is needed, as described on http://developer.gnome.org/dotplan/tasks.html#ApprovingFreezeBreaks. I suggest that this change should be reverted from the string frozen branch. If people disagree with that, then I would like to hear some motivation on why this change is considered important enough to break the freeze and why it cannot wait until the next development cycle. Best regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gdm2 string freeze breakage
On Wed, 23 Mar 2005 12:21:46 -0600, Brian Cameron [EMAIL PROTECTED] wrote: Brian, the attached patch adds zh_SG and fix localized language name. Is it OK to commit? Hmmm. I've check the above link and it doesn't look readible in my browser. Yes, it's in Chinese, sorry for that. It was talking about fragmentation of Chinese usage and various translation issue. But if you are just changing gui/gdmlanguages.c so that the languages have the right name and zh_SG is added, then it is okay to commit. I'll review your changes after your commit and let you know if anything is wrong. Since nobody raised objection on this, I just committed it. In order to play safe, I also modified locale.alias with the same change. Abel It seems we have agreed on the following names: zh_CN = Chinese (China Mainland) zh_SG = Chinese (Singapore) zh_HK = Chinese (Hong Kong) zh_TW = Chinese (Taiwan) So please update it so it looks like that. Also, I don't know if gdm2/config/locale.alias is used. Who would know. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gdm2 string freeze breakage
On Tue, 22 Mar 2005 01:07:46 +0100, Michael Banck [EMAIL PROTECTED] wrote: We're not proclaiming it's independence of China, in the same way that we're not proclaiming Hong Kong's independence of China, even though there's a string Chinese (Hong Kong). Debian losts its kernel maintainer over this (or something related), so I'd be careful here. What, Herbert is gone!? So this looks like situation is worse than I've thought. So everybody, please stop discussing about the political meaning and introduce political sence inside technical issue now... in the end, I have never seen anybody able to drive into conclusion when discussing political issues in F/OSS. That only caused trouble, heat and argument, without materializing anything. Let politicians do their job. Abel cheers, Michael -- davyd back when I was in highschool... it was stop playing with the little green lines, and do some damned study bratsche And that was what, an Atari 2600? davyd I'm not that old... I just had my terminals set to green text ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gdm2 string freeze breakage
On Fri, 18 Mar 2005 18:53:03 -0600, Brian Cameron [EMAIL PROTECTED] wrote:
There are two affected messages. First of all, it is this added message:
#: gui/gdmlanguages.c:83
msgid A-M|Chinese (HongKong)
Now that GDM has been branched for GNOME 2.0, I went ahead and added
Hong Kong back into gdmlanguages.c. This time I include a space
Thanks a lot!
instead of HongKong so this should be taken care of. I noticed that
both zh_CN and zh_TW used the term (simplified) so to make the
descriptions different I changed it for zh_TW to be (Taiwain).
Let me know if this is incorrect or needs to be further improved.
In other words, it now looks like this in gdmlangauges.c:
Brian, is gdm2/config/locale.alias still used? Should the equivalent entry
be added there?
Abel
{ N_(A-M|Chinese (simplified)), zh_CN, [...]
/*Note translate the A-M to the A-M you used in the group label */
{ N_(A-M|Chinese (Hong Kong)), zh_HK, [...]
/*Note translate the A-M to the A-M you used in the group label */
{ N_(A-M|Chinese (Taiwan)), zh_TW, [...]
--
Brian
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Re[2]: gdm2 string freeze breakage
On Tue, 22 Mar 2005 08:21:32 +0800, Wang Jian [EMAIL PROTECTED] wrote: Hi Abel Cheung, My opinion is that before we have zh_SG locale, we'd zh_CN = Chinese (Simplified) zh_HK = Chinese (Hong Kong) zh_TW = Chinese (Taiwan) After we have zh_SG, zh_CN = Chinese (China Mainland) zh_SG = Chinese (Singapore) This will give a smooth transition for Singapore users. It is not good idea to let Singapore users choose China. That will potentially raise another politics issue anyway. Agreed. Probably it's desirable to do it once and for all -- add zh_SG right now as well. Chinese is starting to fragment like English do, so according to [1], it looks like zh_SG is sooner or later needed. Brian, the attached patch adds zh_SG and fix localized language name. Is it OK to commit? Abel [1] http://lists.debian.org/debian-simplified-chinese/2000/07/msg00116.html The potential politics issue should be avoided by using Country and/or Area (Region) instead of Country everywhere Taiwan and China appear simultaneously. On Tue, 22 Mar 2005 07:05:12 +0800, Abel Cheung [EMAIL PROTECTED] wrote: On Mon, 21 Mar 2005 23:36:09 +0100, Danilo ?egan [EMAIL PROTECTED] wrote: (Removed myself, I already subscribe gnome-i18n; and added Funda because he is maintaining most of zh_CN translation. Comment below.) Brian, I believe the preferred nomenclature for zh_TW is traditional', to distinguish it from 'simplified'. I believe traditional is used in Taiwan and Hong Kong, and with separate entry being added for Hong Kong, it's no long necessary to call it that. Okay, should I leave things the way they are, then? zh_CN = (simplified) zh_HK = (Hong Kong) zh_TW = (Taiwan) Should I change zh_CN to Chinese or is (simplified) the best? Lets ask those who're more likely to know: Wang and Abel, listed as respective Chinese coordinators at http://developer.gnome.org/projects/gtp/teams.html Abel, Wang, should we expect any sort of political discussions and/or official problems from the following choice of entries in GDM: 1. Chinese or Chinese (simplified) (pick one which is more appropriate) 2. Chinese (Hong Kong) 3. Chinese (Taiwan) Basically, if Chinese is not written in traditional way anywhere else, I'm almost certain that we're safe with this, but you guys certainly know better than I do. If Wang Jian and Funda see no problem with my proposal, I'd suggest 1. Chinese (Mainland) 2. Chinese (Hong Kong) 3. Chinese (Taiwan) Using geographical name should be able to avoid all those official name arguments, as well as listing the names in balanced manner -- otherwise it is sort of like pt (Portuguese) pt_BR (Brazil) One in language name and another in country name is a little bit strange. Finally, this will be more expandable -- at least allows zh_SG (Singapore) to fit nicely later on, in case this locale is added later. Abel Thanks, Danilo -- lark gdm-languages.diff Description: Binary data ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gdm2 string freeze breakage
Brian, I believe the preferred nomenclature for zh_TW is 'traditional',
to distinguish it from 'simplified'.
regards,
Bill
...
In other words, it now looks like this in gdmlangauges.c:
{ N_(A-M|Chinese (simplified)), zh_CN, [...]
/*Note translate the A-M to the A-M you used in the group label */
{ N_(A-M|Chinese (Hong Kong)), zh_HK, [...]
/*Note translate the A-M to the A-M you used in the group label */
{ N_(A-M|Chinese (Taiwan)), zh_TW, [...]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gdm2 string freeze breakage
Danilo egan wrote: Today at 11:33, Bill Haneman wrote: Brian, I believe the preferred nomenclature for zh_TW is traditional', to distinguish it from 'simplified'. I believe traditional is used in Taiwan and Hong Kong, and with separate entry being added for Hong Kong, it's no long necessary to call it that. Perhaps. But with the political issues surrounding 'Taiwan', would it not be safer not to introduce this string? - Bill Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gdm2 string freeze breakage
Today at 13:48, Bill Haneman wrote: Perhaps. But with the political issues surrounding 'Taiwan', would it not be safer not to introduce this string? We're not proclaiming it's independence of China, in the same way that we're not proclaiming Hong Kong's independence of China, even though there's a string Chinese (Hong Kong). Taiwan _is_ the name of the province/country (depending on who you are :), so I see nothing disputable there (clearly, the Hong Kong example should indicate that we're not insisting on territories being countries in there, since it's a Special Administrative Region of People's Republic of China; we're simply not saying that Taiwan is not as well, but we aren't saying that it is either). Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gdm2 string freeze breakage
On Mon, 21 Mar 2005 23:36:09 +0100, Danilo egan [EMAIL PROTECTED] wrote: (Removed myself, I already subscribe gnome-i18n; and added Funda because he is maintaining most of zh_CN translation. Comment below.) Brian, I believe the preferred nomenclature for zh_TW is traditional', to distinguish it from 'simplified'. I believe traditional is used in Taiwan and Hong Kong, and with separate entry being added for Hong Kong, it's no long necessary to call it that. Okay, should I leave things the way they are, then? zh_CN = (simplified) zh_HK = (Hong Kong) zh_TW = (Taiwan) Should I change zh_CN to Chinese or is (simplified) the best? Lets ask those who're more likely to know: Wang and Abel, listed as respective Chinese coordinators at http://developer.gnome.org/projects/gtp/teams.html Abel, Wang, should we expect any sort of political discussions and/or official problems from the following choice of entries in GDM: 1. Chinese or Chinese (simplified) (pick one which is more appropriate) 2. Chinese (Hong Kong) 3. Chinese (Taiwan) Basically, if Chinese is not written in traditional way anywhere else, I'm almost certain that we're safe with this, but you guys certainly know better than I do. If Wang Jian and Funda see no problem with my proposal, I'd suggest 1. Chinese (Mainland) 2. Chinese (Hong Kong) 3. Chinese (Taiwan) Using geographical name should be able to avoid all those official name arguments, as well as listing the names in balanced manner -- otherwise it is sort of like pt (Portuguese) pt_BR (Brazil) One in language name and another in country name is a little bit strange. Finally, this will be more expandable -- at least allows zh_SG (Singapore) to fit nicely later on, in case this locale is added later. Abel Thanks, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re[2]: gdm2 string freeze breakage
1. Chinese or Chinese (simplified) (pick one which is more appropriate) 2. Chinese (Hong Kong) 3. Chinese (Taiwan) Basically, if Chinese is not written in traditional way anywhere else, I'm almost certain that we're safe with this, but you guys certainly know better than I do. I would suggest distinguish Chinese (Hong Kong) by the actual content of zh_HK. If Abel is transating it into Cantonese, the better list is Chinese (Simplified), Chinese (Cantonese), Chinese (Traditional). Abel Using geographical name should be able to avoid all those official name Abel arguments, as well as listing the names in balanced manner -- otherwise Abel it is sort of like If geographical names be used, I would suggest Taiwan Island instead of Taiwan. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gdm2 string freeze breakage
On Mon, Mar 21, 2005 at 02:18:49PM +0100, Danilo egan wrote: Today at 13:48, Bill Haneman wrote: Perhaps. But with the political issues surrounding 'Taiwan', would it not be safer not to introduce this string? We're not proclaiming it's independence of China, in the same way that we're not proclaiming Hong Kong's independence of China, even though there's a string Chinese (Hong Kong). Debian losts its kernel maintainer over this (or something related), so I'd be careful here. cheers, Michael -- davyd back when I was in highschool... it was stop playing with the little green lines, and do some damned study bratsche And that was what, an Atari 2600? davyd I'm not that old... I just had my terminals set to green text ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: eog string freeze breakages
Any news on this, Jens? Last Tuesday at 22:57, Danilo egan wrote: Hi Jens, (Though I suspect this was unintentional, and Jens only forgot to branch EOG for gnome-2-10 [at least I don't see it], I'm using almost standard mail template for string freeze breakages.) There have been numerous string freeze breakages (at least twelwe new/changed messages) in EOG: http://cvs.gnome.org/viewcvs/eog/libeog/eog-image.c?r1=1.44r2=1.45 http://cvs.gnome.org/viewcvs/eog/shell/eog-window.c?r1=1.125r2=1.126 Both seem to be part of a single commit: 2005-03-14 Jens Finke [EMAIL PROTECTED] * Merged the experimental-job-mgr branch back to head. What you probably want to do is to branch eog at some point before these changes, because I can hardly think of a reason to add 12 new strings in a string frozen branch now. If you still feel there's a need for string freeze breakage, I suggest to follow the procedure outlined below: http://developer.gnome.org/dotplan/tasks.html#ApprovingFreezeBreaks. Basically, we need (very) good reasons why are these new strings necessary. Cheers, Danilo ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gdm2 string freeze breakage
Abel/i18n team:
There are two affected messages. First of all, it is this added message:
#: gui/gdmlanguages.c:83
msgid A-M|Chinese (HongKong)
Which, AFAIK, includes a typo. It is supossed to read Hong Kong,
right?
You are right. I'm from Hong Kong too, so let me express my opinion on
this:
Hong Kong users have been using Taiwan locale for ages, and major
release is imminent, so it's not very fatal to have the change delayed.
However, if possible, I'd wish the string change be proposed to
gnome-i18n again after a few days after this release, as Hong Kong
users are starting to realize the necessity of having zh_HK.
Now that GDM has been branched for GNOME 2.0, I went ahead and added
Hong Kong back into gdmlanguages.c. This time I include a space
instead of HongKong so this should be taken care of. I noticed that
both zh_CN and zh_TW used the term (simplified) so to make the
descriptions different I changed it for zh_TW to be (Taiwain).
Let me know if this is incorrect or needs to be further improved.
In other words, it now looks like this in gdmlangauges.c:
{ N_(A-M|Chinese (simplified)), zh_CN, [...]
/*Note translate the A-M to the A-M you used in the group label */
{ N_(A-M|Chinese (Hong Kong)), zh_HK, [...]
/*Note translate the A-M to the A-M you used in the group label */
{ N_(A-M|Chinese (Taiwan)), zh_TW, [...]
--
Brian
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
eog string freeze breakages
Hi Jens, (Though I suspect this was unintentional, and Jens only forgot to branch EOG for gnome-2-10 [at least I don't see it], I'm using almost standard mail template for string freeze breakages.) There have been numerous string freeze breakages (at least twelwe new/changed messages) in EOG: http://cvs.gnome.org/viewcvs/eog/libeog/eog-image.c?r1=1.44r2=1.45 http://cvs.gnome.org/viewcvs/eog/shell/eog-window.c?r1=1.125r2=1.126 Both seem to be part of a single commit: 2005-03-14 Jens Finke [EMAIL PROTECTED] * Merged the experimental-job-mgr branch back to head. What you probably want to do is to branch eog at some point before these changes, because I can hardly think of a reason to add 12 new strings in a string frozen branch now. If you still feel there's a need for string freeze breakage, I suggest to follow the procedure outlined below: http://developer.gnome.org/dotplan/tasks.html#ApprovingFreezeBreaks. Basically, we need (very) good reasons why are these new strings necessary. Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gdm2 string freeze breakage
On 2005-03-06(Sun) 16:28:57 +0100, Jordi Mallach wrote: On Sat, Mar 05, 2005 at 08:32:15PM +0100, Christian Rose wrote: There are two affected messages. First of all, it is this added message: #: gui/gdmlanguages.c:83 msgid A-M|Chinese (HongKong) Which, AFAIK, includes a typo. It is supossed to read Hong Kong, right? You are right. I'm from Hong Kong too, so let me express my opinion on this: Hong Kong users have been using Taiwan locale for ages, and major release is imminent, so it's not very fatal to have the change delayed. However, if possible, I'd wish the string change be proposed to gnome-i18n again after a few days after this release, as Hong Kong users are starting to realize the necessity of having zh_HK. Abel Jordi -- Jordi Mallach Prez -- Debian developer http://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.sindominio.net/ GnuPG public key information available at http://oskuro.net/ ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n -- Abel Cheung +-+-+ |GPG Key: (0xC67186FF)| http://deaddog.org/gpg.asc| |Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF| +-+-+ pgpWgbToBjeut.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
String freeze continues...
As always, once started, string freeze continues (forever) on the stable branch. That means that if you haven't branched for gnome-2-10, your HEAD branch remains in string freeze. If you have branched for gnome-2-10, your gnome-2-10 branch remains being string frozen, while you're free to do as you please in HEAD. That being said, if there's any string change or string addition that weren't previously accepted and you feel is very important to get in in GNOME 2.10.1 or subsequent GNOME 2.10.x releases, please bring it up again on gnome-i18n@gnome.org (cc:ing [EMAIL PROTECTED] and gnome-doc-list@gnome.org), and we can have another look at it. Furthermore, if you do branch, please let gnome-i18n@gnome.org, [EMAIL PROTECTED], gnome-doc-list@gnome.org and other contributors know as soon as possible, so that work won't be spent on the wrong branch by accident. Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gdm2 string freeze breakage
Christian: There has recently been an unannounced string freeze breakage in the string frozen gdm2 HEAD branch. There are two affected messages. First of all, it is this added message: #: gui/gdmlanguages.c:83 msgid A-M|Chinese (HongKong) That addition broke string freeze. As much as we'd like to have entries for locales added to the GDM login screen, right *now* (almost four weeks into the string freeze, well into the hard code freeze, and four days from the .0 release) is a very bad time to add an additional locale. Apologies. I've backed out this change. I didn't realize that this was a string freeze issue. Furthermore, it is this message: #: gui/gdmsetup.c:2191 msgid _Remove Theme The relevant parts of the big ChangeLog entry seems to be these: Fri Mar 04 12:50:00 2005 Brian Cameron [EMAIL PROTECTED] * gui/gdmsetup.c: Mark Remove Theme for translation. * gui/gdmlanguages.c: Add zh_HK and remove span tags in language display since they were causing formatting problems for some users. The second message was in order to fix a bug where a message hadn't previously been marked for translation, and as such it isn't really a string freeze breakage. But we still want translators to be notified when such things happen. No notice has been sent to translators in this case. I suggest that the message stays in though, although translators should at the very least have been given some warning. Apologies for not sending out a notification. I didn't realize that you needed to send out a notice for marking a string for translation. I thought you only needed to send notification when adding new strings. I will be more careful in the future. The first message is a string freeze breaking change -- I suggest it be reverted immediately. This is not the time for such additions. Perhaps we can discuss it again for GNOME 2.10.1, but for now it should be reverted. The first message has been backed out. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gdm2 string freeze breakage
On Sat, Mar 05, 2005 at 08:32:15PM +0100, Christian Rose wrote: There are two affected messages. First of all, it is this added message: #: gui/gdmlanguages.c:83 msgid A-M|Chinese (HongKong) Which, AFAIK, includes a typo. It is supossed to read Hong Kong, right? Jordi -- Jordi Mallach Pérez -- Debian developer http://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.sindominio.net/ GnuPG public key information available at http://oskuro.net/ signature.asc Description: Digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gdm2 string freeze breakage
There has recently been an unannounced string freeze breakage in the string frozen gdm2 HEAD branch. There are two affected messages. First of all, it is this added message: #: gui/gdmlanguages.c:83 msgid A-M|Chinese (HongKong) That addition broke string freeze. As much as we'd like to have entries for locales added to the GDM login screen, right *now* (almost four weeks into the string freeze, well into the hard code freeze, and four days from the .0 release) is a very bad time to add an additional locale. Furthermore, it is this message: #: gui/gdmsetup.c:2191 msgid _Remove Theme The relevant parts of the big ChangeLog entry seems to be these: Fri Mar 04 12:50:00 2005 Brian Cameron [EMAIL PROTECTED] * gui/gdmsetup.c: Mark Remove Theme for translation. * gui/gdmlanguages.c: Add zh_HK and remove span tags in language display since they were causing formatting problems for some users. The second message was in order to fix a bug where a message hadn't previously been marked for translation, and as such it isn't really a string freeze breakage. But we still want translators to be notified when such things happen. No notice has been sent to translators in this case. I suggest that the message stays in though, although translators should at the very least have been given some warning. The first message is a string freeze breaking change -- I suggest it be reverted immediately. This is not the time for such additions. Perhaps we can discuss it again for GNOME 2.10.1, but for now it should be reverted. Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
