Re: Request for Freeze Break - Evolution
On Mon, Feb 25, 2008 at 1:34 AM, Sankar P [EMAIL PROTECTED] wrote: Hi, I have updated a plugin for Evolution - external-editor Initially this was a experimental plugin and we had to move it to the standard list of plugins. Hence, it involved some new UI Screens and strings (for error-message). The current version in trunk is bare-bones and lacks error messages and is unintuitive. We're one week away from hard code freeze and have no releases between now and the final version (well, one coming out on Wednesday but it may be too late to get the approvals and the new evolution out for that one)...and you want to break the last three freezes? I'm really uncomfortable with this... Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String additions to 'libgnomeui.gnome-2-20'
Hi Federico, On 10/14/07, Federico Mena Quintero [EMAIL PROTECTED] wrote: H, are we really string frozen for the gnome-2-20 branch? Gah, we're still failing somehow. I don't get it. To answer your question: Yes, ALL freezes remain in effect after the .0 release goes out *except* for hard code freeze. Now to my question: How can we communicate this more clearly? We've tried to remind people that freezes remain in effect after the .0 release lots of ways and lots of times going back for years, but we seem to never get the message across. We're clearly doing something wrong. :-( Then how are bugs to be fixed within the stable series? There is a freeze break approval process if you need it. Your question surprises me, though; at least for the modules I've worked on, the vast majority of bugfixes don't require string changes. Are the modules I work on weird, or are yours? ;-) Thanks for the awesome work, Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Patched libsounds in g-c-c 2.20
On 9/26/07, Rodrigo Moya [EMAIL PROTECTED] wrote: On Wed, 2007-09-26 at 12:29 +0200, Rodrigo Moya wrote: On Tue, 2007-09-25 at 20:48 +0200, Vincent Untz wrote: (Claude's mail is not reaching gnomecc-list, probably because of moderation) Le lundi 24 septembre 2007, à 22:53 +0200, Claude Paroz a écrit : Hi, We found some weird strings not in upstream when translating gnome-control-center for Ubuntu. It appears that libsounds (svn:external) in the GNOME 2.20 g-c-c tarball has been patched. http://bugzilla.gnome.org/show_bug.cgi?id=479970 This is not only a string freeze breakage, but a serious concern about security of official GNOME releases. Please, do all you can to prevent this sort of things to happen again. Is a new release planned to fix this? yes, doing it. It's been all my fault, since I had that patch applied locally and did the release from that. 2.20.0.1 released Thanks! ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: evince branched for 2.18
On 4/17/07, Nickolay V. Shmyrev [EMAIL PROTECTED] wrote: Hello all Now Evince development will continue in trunk. For list of planned features see. Mostly we target annotations support and forms http://live.gnome.org/Evince/Roadmap Adding gnome-doc-list as per instructions at http://live.gnome.org/MaintainersCorner. Cheers, Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: gconf branched for 2.18
On 4/16/07, Christian Persch [EMAIL PROTECTED] wrote: Hi, I've branched GConf for gnome 2.18, so I can commit a string change on trunk. The branch is called gnome-2-18; I've already switched the jhbuild 2.18 moduleset. Adding gnome-doc-list, gnome-i18n, and desktop-devel-list to the cc list, as per instructions at http://live.gnome.org/MaintainersCorner. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Request to break string freeze
On 3/27/07, Adam Schreiber [EMAIL PROTECTED] wrote: The patch attached to bug [1] allows complete translating of seahorse's about dialog. As per http://live.gnome.org/TranslationProject/HandlingStringFreezes (linked to from http://live.gnome.org/MaintainersCorner, which is linked to from bugzilla.gnome.org/browse.cgi as well as the development schedule), section What changes are not affected by the string freeze?: The following types of changes do not need explicit approval, however we would still very much like them to be announced so that we know about them: * Marking a message for translation that was previously not marked for translation by accident. So, if it was an accident that the string wasn't previously marked for translation, it looks like you can go ahead an commit the patch since you have now announced it. Cheers, Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: control-center branched for 2.18
On 3/19/07, Rodrigo Moya [EMAIL PROTECTED] wrote: gnome-control-center module has been branched, so now there is a gnome-2-18 branch for 2.18 development. Adding gnome-doc-list and r-t to the cc list; please don't forget them in future branching notices (complete list of who should be cc is in bold at http://live.gnome.org/MaintainersCorner, which is linked to from the bugzilla product overview page, bugzilla.gnome.org/browse.cgi). Thanks, Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Totem branched for 2.18
On 3/19/07, Bastien Nocera [EMAIL PROTECTED] wrote: SSIA Adding gnome-doc-list to the cc list; please don't forget them in future branching notices (complete list of who should be cc is in bold at http://live.gnome.org/MaintainersCorner, which is linked to from the bugzilla product overview page, bugzilla.gnome.org/browse.cgi). Thanks, Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Modules branched to gnome-2-18
On 3/15/07, Lucas Rocha [EMAIL PROTECTED] wrote: Hi Elijah, Speaking of branching, what are the plans for Metacity in GNOME 2.20? Return it to a state of active maintenance, unlike what it had during the 2.18 cycle? :-) Hopefully I'm not underestimating the amount of time involved in moving to another state for a job and in home ownership (at least I think we'll be buying), like I did the amount of time needed to finish my dissertation (which I'm still not technically done with, though I only have some trivial work left that will only take a few hours). Thomas has helped fill in some, and Havoc has been helping a lot in bugzilla, but I really need to tackle the backlog of patches and bugs. I don't have any huge concrete user-visible plans (unless said users are affected by certain bugs), though that might change as time goes on. Cheers, Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Hard code freeze break request for #416436 (gnome-system-tools)
On 3/11/07, Carlos Garnacho [EMAIL PROTECTED] wrote: Hi!, #416436 [1] is about marking a non translated string as translatable, according to the i18n team rules[2], I do not need explicit approval from them, but I guess I still need the hard code freeze approval, sorry for being too late, I hope this gets sorted out before I have to make the 2.18.0 release :) Hi Carlos, Thanks for the work on g-s-t. This close to the release, I'd prefer to only approve crashers and data loss issues, so please wait for 2.18.1 for this change (unless two others approve, of course). Thanks, Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Modules branched to gnome-2-18
On 3/5/07, Claude Paroz [EMAIL PROTECTED] wrote: Le lundi 05 mars 2007 à 16:01 -0300, Leonardo Fontenelle a écrit : l10n.gnome.org still shows statistics for metacity trunk, even if it already branched. Translations committed to trunk after 2007-02-27 will not be show in GNOME 2.18: pt_BR (I'll fix it), dz, ku, lt, nl, zh. OK, I've updated metacity on l10n.gnome.org with gnome-2-18 branch. But please, metacity guys, do inform the usual teams about branching. http://live.gnome.org/MaintainersCorner Sorry about this. I gave a lot of the maintenance work to Thomas this cycle, without remembering to point out all the rules. In general Thomas has done really well trying to do the best he could with missing directions from me, but a slip or two like this was probably inevitable. My bad; I'll do better next time I unload responsibilities onto a new co-maintainer. Thanks for your patience, Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: RTL support in Gnome
[Removing some of the cc's; it just looked like too many] On 1/16/07, Yair Hershkovitz [EMAIL PROTECTED] wrote: I've been working lately on some bugs with RTL (right to left languages) support in Gnome. I have few suggestions to help improve RTL support in Gnome: 1) I want to start a mailing list for RTL support discussions ( [EMAIL PROTECTED] ???) sysadmins can handle this...see http://live.gnome.org/NewListRequest. 2) I think we should add an rtl keyword to bugzilla, for tracking RTL issues. Would the status whiteboard be sufficient here? I typed up some guidelines about this elsehwere. I'll copy them here: 'We have too many keywords and should be removing them instead of adding them in most all cases. Basic criteria for adding new keywords that you should consider when trying to get approval of the other bugmasters: * It should not be specific to any module or small set of modules * It must be used widely (i.e. by many different people and not just some small niche) for querying. (Using extra keywords to categorize bugs, merely in order that they can be categorized more, isn't useful unless multiple people actively use those categories in searches) * It must be used for a long time, not just for some short term purpose (e.g. something like Gnome212blocker wouldn't fly) Note that everyone is free to use the status whiteboard as an alternative to keywords. It is helpful, when using the status whiteboard, if you namespace anything you add; for example, evolution[IMAP] instead of IMAP and andrew[bigbadbug] instead of bigbadbug.' Cheers, Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: 2.18 proposed modules: i18n evaluation
On 12/12/06, Danilo Šegan [EMAIL PROTECTED] wrote: Hi all, This is my evaluation (with GTP spokesperson hat on) of the Gnome modules which are proposed for inclusion in 2.18. It's based only on the perceived localizability of the app, usually untested, but judging by the strings in the PO files, and how comfortable will GTP in working with them. I didn't evaluate anything else. If I failed in being objective (no doubt I did :), please point that out if you think it will affect final 'score'. Awesome, thanks for doing this review Danilo. Looks like a lot of work, but reviews like this from spokespeople of the various major project areas really help. :) Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: control-center branched for 2.16
On 9/4/06, Rodrigo Moya [EMAIL PROTECTED] wrote: control-center has been branched for 2.16 (gnome-2-16 branch). In HEAD, new development will start, which includes: Don't forget to cc gnome-i18n, release-team, and gnome-doc-list in branch announcements as specified at http://live.gnome.org/MaintainersCorner (which is linked to from http://live.gnome.org/TwoPointFifteen). I did that for you this time. :) - probably, merging of some applets - new control-center shell, probably the one from SLED - improvements in the capplets - bug fixes -- Rodrigo Moya [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Request for UI break for Tomboy
On 9/2/06, Alex Graveley [EMAIL PROTECTED] wrote: Hi, This simple patch makes the gtkspell dependency optional, and removes the enable spell-checking checkbox in the Prefrences depending on gtkspell's availability. I could probably just commit this as it basically counts as a build fix, but I thought I'd take the safe route since I'm new to all this. Besides, it gives docs people a heads up. Yeah, sounds sane, and it does have a ui-change necessary to go with the build fix. So here's 1 of 2. I wonder if that should be 2 of 2, considering http://mail.gnome.org/archives/release-team/2006-August/msg00159.html, but it's at least 1. :-) ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: file-roller branched
On 6/20/06, Scott J. Harmon [EMAIL PROTECTED] wrote: Paolo Bacchilega wrote: Hi, the file-roller module has now a gnome-2-14 branch for version 2.14, HEAD will be used to develop version 2.16 Plans for 2.16 are: browse bugzilla and fix bugs. Bug fixing can be done without branching unless these are architecture changing bugs... Not quite -- bug fixing also can't be done on the branch if they are bugs which would require modifying translatable strings or the UI or would need some new feature to fix... (unless, of course, you get freeze break approval) ;-) ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GOK branched?
On 6/11/06, Christian Rose [EMAIL PROTECTED] wrote: On 6/11/06, Josep Puigdemont [EMAIL PROTECTED] wrote: Hi, The statistics page for G214 still shows branch HEAD for GOK, while branch gnome-2-14 seems to exist. Could it be that GOK has [silently?] branched for GNOME 2.14? /Josep It certainly looks like it. It seems there actually exists a gnome-2-14 branch of gok, but, digging through my mail archive, it seems this branch was never announced to translators nor to any other of the mailing lists I happen to subscribe to. Gok maintainers, please remember to *announce* when you create a new stable branch, as described on http://live.gnome.org/MaintainersCorner . Otherwise, many other contributors (translators, docs people, etc) will spend a lot of their time working on the wrong branch. This looks like one I should have caught. David was asking us to learn correct procedure and we apparently forgot to mention this (see http://mail.gnome.org/archives/release-team/2006-May/msg00025.html and the other emails in that thread). Sorry about that. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
id translation and gnome-2-14 branch of gnome-screensaver
Hi, A small issue has come up. Apparently, 'id' has been added to ALL_LINGUAS in the gnome-2-14 branch of configure.ac for gnome-screensaver without the accompanying translation -- twice. Naturally, this breaks the build (see http://bugzilla.gnome.org/show_bug.cgi?id=344432). At John's request, I'm sending this email hoping it gets to the right people, so that if it's added again the translation will come with it. Thanks for your hard work everyone! Cheers, Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: gcalctool tarball dist for GNOME 2.15.1 is broken.
On 4/25/06, Rich Burridge [EMAIL PROTECTED] wrote: I need some help. The tarball http://ftp.gnome.org/pub/GNOME/sources/gcalctool/5.8/ I recently generated for GNOME 2.15.1 is broken. It doesn't contain and various .../po/*.po files. I suspect it's an incomplete fix to bug #337897 http://bugzilla.gnome.org/show_bug.cgi?id=337897 Changes to use po/LINGUAS file. I received the attached email, but it doesn't seem to be the correct fix. The gedit code uses .../po/LINGUAS, doesn't have a .../po/Makefile.in.in file and uses AM_GLIB_GNU_GETTEXT in configure.in Could somebody tell me what I need to do to fix this please? Looks like I got hit by the same bug in metacity -- no translations in the release(s) I made for 2.15.1 and I also applied the po/LINGUAS fix from the Gnome Goals so I suspect it's related. But, make distcheck is all black magic to me. Anyone else know what causes this? Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: gcalctool tarball dist for GNOME 2.15.1 is broken.
On 4/25/06, Claudio Saavedra [EMAIL PROTECTED] wrote: Hi, On Tue, 2006-04-25 at 12:27 -0600, Elijah Newren wrote: Looks like I got hit by the same bug in metacity -- no translations in the release(s) I made for 2.15.1 and I also applied the po/LINGUAS fix from the Gnome Goals so I suspect it's related. But, make distcheck is all black magic to me. I think but am not 100% sure, that people need to update to a recent intltool in order to fix this I'm using CVS HEAD as of today, which definitely doesn't fix it for me. , but then appear problems with the modules which are still using the old ALL_LINGUAS instead of po/LINGUAS. For example, I can't compile gnome-session: make[2]: Entering directory `/home/claudio/cvs/gnome-2.16/gnome-session/po' make[2]: *** No rule to make target [EMAIL PROTECTED]@.gmo', needed by `all-yes'. Stop. make[2]: Leaving directory `/home/claudio/cvs/gnome-2.16/gnome-session/po' make[1]: *** [all-recursive] Error 1 Right, that's because these modules having been fixed as per GnomeGoal#2 (see http://live.gnome.org/GnomeGoals/PoLinguas). http://bugzilla.gnome.org/show_bug.cgi?id=337982 has a patch to fix gnome-session. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: gcalctool tarball dist for GNOME 2.15.1 is broken.
On 4/25/06, Elijah Newren [EMAIL PROTECTED] wrote: Looks like I got hit by the same bug in metacity -- no translations in the release(s) I made for 2.15.1 and I also applied the po/LINGUAS fix from the Gnome Goals so I suspect it's related. But, make distcheck is all black magic to me. Anyone else know what causes this? dobey tracked down the metacity issue and found it to be caused by metacity not using gnome-autogen.sh (for which I blame havoc or jamesh ;-), and the hand-rolled version metacity had only checked for AC_PROG_INTLTOOL instead of IT_PROG_INTLTOOL. It appears that the gcalctool and gdm problems can be fixed by using a decent shell (i.e. /bin/bash instead of Solaris' sh) though that's an ongoing conversation in IRC at the moment... (dobey can clear things up if I've misinterpreted anything, as this auto-voodoo is still beyond me) Cheers, Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
libwnck branched
libwnck now has a gnome-2-14 branch. We basically branched for now just so we could depend on the newer intltool (as part of GnomeGoal#2), but other plans for head might include: - try not to suck so bad at patch review - fix handling of group modal windows (as part of a bigger effort to get this done Gnome wide, hopefully...) - find someone to make sure the selector notifies of demands attention windows too (and hopefully reusing code from the tasklist) - continue whining and moaning about how the window list grouping is inherently broken and waiting for gimmie to replace the whole stupid window list thing :) - all the sekret 133t plans Vincent has been waiting to unleash on everyone as part of his quest for world Gnomination. ;-) ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Sound Juicer has been branched
On 4/14/06, Ross Burton [EMAIL PROTECTED] wrote: Hi, The subject says it all really... Don't forget to cc gnome-doc-list. ;) (And I'm pretty sure Luis will be asking for plans soon as well...) ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Request for freeze break -- feature string freeze for 2.14.x cycle
On 4/13/06, Vincent Untz [EMAIL PROTECTED] wrote: Just wondering before giving an approval: what are the plans in the future wrt to this? Do you plan to keep this option? Or do you think we can have a better solution? I believe this patch is the better solution to the strict focus patches that have been around for years and by demand found their way into Debian, Ubuntu, and RHEL despite their kludgy nature. Those other patches existed because there were complaints that Sometimes windows take focus when I don't want them to!. The solution in those other patches was to just never focus new windows. Period. (Why anyone would think that the run application dialog shouldn't be focused when the user presses Alt+F2 is beyond me. Or the open file dialog when the user pressed Ctrl+O in some app. Or a variety of other cases. But, it appears that some users never do those things and thus didn't mind such a kludge) Focus-stealing-prevention didn't mitigate demand for this dont-focus-new-windows feature either, surprisingly. The strict focus option introduced by this patch puts some rationale behind the use cases for why users wouldn't want to focus new windows (besides focus stealing prevention stuff) and only takes effect in those cases instead of kludging it in everywhere. By doing that, it became useful to a wider group of people (e.g. me) and I have reports from others that wanted the don't-focus-new-windows behavior that it solved their problem. Since this option solves a very common complaint (one of only two options I've ever found that had sufficient complaints/requests in order to get multiple major distros to patch in a kludgy option for it), and it has a decent usability rationale (even if for a niche set of users), I think it should stay. I've applied it to HEAD and it will be an option in 2.16 and beyond. I'd take an even better solution if one existed, but I really doubt one does at this point. I believe it only affects the terminal, but there are mentions of other apps in the bug, so I'm a bit lost here. Was it because users were still using an old metacity with the first buggy version of the strict mode? That's one of the reasons. Another big reason is that users are unable to distinguish between the new behavior in 2.14.0 and the old focus stealing prevention bugs being tracked in #149028 (which isn't surprising -- most users are literally unable to distinguish between the very different concepts of focusing and raising, and the different focus-new-window behaviors is a far more subtle difference). There's possibly one more reason too: the combination of the fact that users in general have a difficult time expressing themselves coherently, and the fact that they were using the terminal to launch other apps. ;) Hope that helps, Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Request for freeze break -- feature string freeze for 2.14.x cycle
On 4/12/06, Christian Rose [EMAIL PROTECTED] wrote: You have your string freeze approval from me. From looking at the patch (http://bugzilla.gnome.org/attachment.cgi?id=61971) attached to the bug report (http://bugzilla.gnome.org/show_bug.cgi?id=326159), it seems the only new strings that the patch adds is the two messages for a new GConf key in metacity. Furthermore, this sounds (from your description) like a serious problem that bothers the distros. Thanks. And yes, the strings basically will only appear to users of gconf-editor that happen to look at this particular key. As always, once you have had all approvals necessary and committed the patch, please let translators know so they know when it's time to update their metacity translations. Also, if you plan to do a new bug fix release soon, please let the translators know so they know how much time they have to fix the translations. With the three necessary approvals from you, Kjartan, and Luis, I have now committed the patch to the gnome-2-14 branch. I'd like to make a bug fix release soon. I would do it now, especially since the strings are extremely unlikely to be seen by users, but I don't want to cause any problems for translators. Would making a release about this time tomorrow be okay or are there any translators that would like more time? Thanks everyone, Elijah Thanks, Christian ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Incorrect branch listing for Metacity?
Hi, I noticed a flurry of translation updates to metacity HEAD today after I made a release from the gnome-2-14 branch. Given the previously unmarked string newly marked for translation that we announced yesterday[1], I would have suspected the barrage of updates on gnome-2-14 but only saw 3. Soeren announced the branch for gnome-2-14 in February[2], but this made me wonder if perhaps the email was missed and something didn't get updated for which branch to use with metacity for translations? Confused, Elijah [1] http://mail.gnome.org/archives/gnome-i18n/2006-March/msg00200.html [2] http://mail.gnome.org/archives/gnome-i18n/2006-February/msg00171.html ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Sylpheed-Claws support in Preferred Applications
On 3/6/06, Luca Cavalli [EMAIL PROTECTED] wrote: Hard Code Freeze is not yet in place (shouldn't it start at midnight UTC?) and I understand Sylpheed is not part of GNOME project, but it is a quite popular GTK based mail client. Yes, there's about another 40 minutes or so until hard code freeze. It seems quite late for a string addition like this so I'd be really surprised if Christian or Danilo accepted it, but it's up to them (assuming they do it fast enough, of course; asking just a few hours before a deadline is really hard to handle). Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String addition to gnome-terminal
Just to quickly follow up... On 2/17/06, Danilo Šegan [EMAIL PROTECTED] wrote: Hi Guilherme, Today at 17:13, Guilherme de S. Pastore wrote: I have applied this patch after waiting for an answer for a while and getting an OK from the docs team. It can be reverted later on if needed. Please instead follow the advice I gave in http://mail.gnome.org/archives/gnome-i18n/2006-February/msg00189.html Unless Christian Rose approves the change instead. It appears from a quick glance at the ChangeLog that you have not yet done so, Guilherme. Please revert and use Danilo's suggestion and email us when you have done so. Note that in general it is not okay to commit changes that break freezes without approval, regardless of the amount of time waited to receive that approval after sending your request. It is okay to ping if you haven't obtained a response after a while (e.g. a day or two), though. Thanks, Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String addition to gnome-terminal
On 2/18/06, Guilherme de S. Pastore [EMAIL PROTECTED] wrote: Em Sáb, 2006-02-18 às 09:13 -0700, Elijah Newren escreveu: It appears from a quick glance at the ChangeLog that you have not yet done so, Guilherme. It was agreed that I would do something else, in case you haven't followed the thread. But as you're in such a hurry, done. gnome-terminal now has three untranslatable strings. Sorry, I didn't mean to offend. I thought I was following the thread, but apparently the release-team stopped being cc'ing with http://mail.gnome.org/archives/gnome-i18n/2006-February/msg00194.html, and with a lack of response I thought the freeze was just being silently ignored. So, it looks like it was a communication disconnect. Sorry for the problems. Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Sound Juicer UI changes
On 2/13/06, Shaun McCance [EMAIL PROTECTED] wrote: On Mon, 2006-02-13 at 13:20 -0700, Elijah Newren wrote: On 2/13/06, Ross Burton [EMAIL PROTECTED] wrote: Hi, Attached is a patch that makes some minor changes to the SJ UI (following a UI review with Calum etc): * add accelerator labels to main window artist/title/genre fields * Use a multiply symbols rather than x in status bar * Add a space before strings destined for status bar for padding * Add ellipsis to Edit Profiles button * Align check boxes in Preferences dialog with dropdowns rather than labels * Change two Example Path: and /foobar/ labels into a single, small label. * Use real data for the sample track It would break string freeze, so you'll need an approval from gnome-i18n@ as well. I'll cc them. Since these changes are in response to a UI review with Calum, I'm leaning towards accepting but first want to check with the documentation people to see if this affects them. The Sound Juicer manual has always been one of the ones that I take care of myself, and I'll do so again this release cycle. Since I have not yet started updating its documentation, a string change wouldn't affect me. It's up to the translation folks. Alright, here's 1 of 2 approvals (well, 1 of 3 given that you also need i18n approval) from me then. Cheers, Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Module decisions for GNOME 2.14
On 2/12/06, Christian Rose [EMAIL PROTECTED] wrote: Ok, based on this list I have moved the following modules in the GNOME 2.14 translation status from the proposed section to the desktop section: deskbar-applet fast-user-switch-applet gnome-screensaver pessulus sabayon Based on the same information, I have moved the following modules from proposed to extras: gnome-power-manager I could find no information about the following perviously proposed modules, but I assume that they will not be included, and as a consequence I have moved them from proposed to extras: atomix nautilus-actions Please let me know if something in the above was not the right thing to assume or to do. Those were all correct. Cheers, Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
String changes in libwnck
The right-click-on-window-button-in-taskbar menu items have changed to synchronize with metacity's right-click-on-window-titlebar menu. This means that the strings _Unroll Roll _Up have been removed, while On _Top Move to Workspace _Left Move to Workspace R_ight Move to Workspace _Up Move to Workspace _Down have been added. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
metacity string changes
I've made a few string changes in metacity with various updates to metacity.schemas.in. Mostly just comments, clarifications, spacing fixes, plus a couple of new options (two new double-click-on-titlebar actions) that aren't exposed in the UI. Since these are only ever really seen if someone uses gconf-editor, I doubt this affects documentation. It's probably also very low priority for translators. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: totem string freeze breakages
On 10/26/05, Bastien Nocera [EMAIL PROTECTED] wrote: Can I move a function to another file without breaking the translations? Can I remove the use of a particular string and replace it with an already translated string without using breaking translations? Christian, Danilo: Could we get a clarified version of http://mail.gnome.org/archives/desktop-devel-list/2005-February/msg00092.html up somewhere? I was going to answer Bastien's question using that email (which is linked to from the freeze-break-request-approval page now), but that email doesn't have enough info to answer the first of the two questions. Maybe we need to make that more prominent somehow too?... I wasn't asking for the reason why. I didn't even know that there was a string freeze *after* the .0 releases. And I'm pretty sure I broke it in the past for some other modules, and didn't get told anything. Is there some way the release-team could send out this message better? The *only* freeze that ends after the .0 release is the hard-code freeze, but if you weren't aware of that fact, then many others aren't either. And yes, we definitely don't have an easy way to enforce all the freezes and probably have lots of people slipping through the cracks, which probably makes it worse when we do catch people because they thought all along that they were just doing what they've always done. Sorry about that. Thanks for all your awesome work on Totem, Bastien. Cheers, Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Eel and Nautilus branched
On 10/3/05, Alexander Larsson [EMAIL PROTECTED] wrote: Eel and Nautilus has been branched for 2.13. 2.12.x work go in the gnome-2-12 branch. Don't forget gnome-doc-list. :-) ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translations not used in Evolution (was Re: Evolution and Evolution-Data-Server branched)
On 9/19/05, Vincent Untz [EMAIL PROTECTED] wrote: On Mon, September 19, 2005 10:24, Harish Krishnaswamy wrote: However, it would be helpful if you could make incremental updates during the development cycle [2] or have all your huge changes committed at least a day prior to the deadline. This would limit the damage caused by errors in packaging or missing commits. While I agree that your first solution would be nice, some translators don't do this because it's really hard to keep translating the modules when there's no string freeze. So they only translate when string freeze is here. Translators do their best to commit before the deadline and if they could do better, I'm sure they'd do it ;-) I suggest you release the module on the Monday of the release (as requested by the release team). To my knowledge, the release team has never request this. We have only requested that tarballs be released by Monday. I think that was the whole point of Danilo's request on the 2.14 schedule, though... Translators know that if they commit their translations on Monday, it might already be too late for their translations to go in the release. But if you need to make the tarball for the release before Monday, then send an e-mail to gnome-i18n so translators know that the tarball will be made before Monday. Is Monday enough time, though? I think some modules (like evo) may want a little more time to smoketest their own modules... ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translations not used in Evolution (was Re: Evolution and Evolution-Data-Server branched)
On 9/19/05, Harish Krishnaswamy [EMAIL PROTECTED] wrote: Translators know that if they commit their translations on Monday, it might already be too late for their translations to go in the release. But if you need to make the tarball for the release before Monday, then send an e-mail to gnome-i18n so translators know that the tarball will be made before Monday. This sounds fine. It is almost always the Friday before the due-date, but I can post a heads-up to gnome-i18n in future. Actually, this is a good data point because Danilo brought this up on d-d-l in terms of the 2.14 schedule mentioning that we haven't had a don't-release-sooner-than-X guideline before, but such a guideline would help them. What would work for Evolution here? Would specifying that tarballs for a release should include translations up to Friday 23:59 UTC before the release allow you enough time? I think if we document this kind of stuff, then it'll go a long ways towards preventing misunderstandings such as this thread. Thanks everyone! Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translations not used in Evolution (was Re: Evolution and Evolution-Data-Server branched)
On 9/19/05, Harish Krishnaswamy [EMAIL PROTECTED] wrote: snip I am handicapped by the fact that 1. I do not know what languages I should watch out for - before carving out a snapshot for pre-release testing. snip [1] The build verification by the Evolution QA team was done from rpms obtained from HEAD not the stable branch at that point, due to lags in updating the red-carpet channels. Is there any way to fix these lags (or to time the branching so as to make them not be an issue)? Bugsquad, translators, the release team, and others all would be watching the stable branch instead of HEAD and it'd be much nicer, if possible, to just use the intended branch for making all testing rpms and tarballs. I understand you have a lot of constraints on you coming from a lot of different directions so this might not be possible, but it'd avoid future confusion like this that will almost certainly occur otherwise. Thanks for all your hard work to smooth out these wrinkles, Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: That splash screen not disappearing issue
On 9/6/05, Mark McLoughlin [EMAIL PROTECTED] wrote: Hi, On Mon, 2005-09-05 at 12:51 -0600, Elijah Newren wrote: 2. Splash screen doesn't disappear I saw something about smproxy possibly fixing some of the splash screen / session issues. Do I remember that correctly and has this been done? Bugreport itself mentions long running programs causing this. http://bugzilla.gnome.org/show_bug.cgi?id=116814 It's in the release notes too and isn't a regression from previous releases (this bug has always been there), but I thought this was fixed with the smproxy removal too. Mark? Even if it isn't, I don't want to hold up the release given that it's already in the release notes. Simple answer - I think this is fixed by the smproxy removal. But there are harder answers: - People may still see the issue with an existing ~/.gnome2/session - If someone puts a non-XSMP area app in their session, or session-manual or in the default session, I think they'll see the problem there too. But wrt. release notes and it being a blocker, it should be fixed and we can forget about it. Thanks Mark. So, um...are the release notes really frozen, or can we remove the paragraph about this issue? ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: That splash screen not disappearing issue
On 9/6/05, Vincent Untz [EMAIL PROTECTED] wrote: On Tue, September 6, 2005 16:55, Elijah Newren wrote: Thanks Mark. So, um...are the release notes really frozen, or can we remove the paragraph about this issue? We can remove the paragraph. It won't affect existing translations since it's just a string removal. Okay, I just wasn't sure how the translation of xml files worked -- since none of the paragraphs are marked with the _() tags, I didn't know if paragraphs were translated individually or if it was a whole-file translation kind of thing. :) ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
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 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GConf reverse string freeze breakage approval
On 8/14/05, Mark McLoughlin [EMAIL PROTECTED] wrote: On Sun, 2005-08-14 at 15:57 +0200, Danilo Šegan wrote: Today at 13:48, Mark McLoughlin wrote: All I'm really saying is that I don't think the hard string freeze was in effect when this change was approved or committed. And all I'm saying is that I disagree. But it doesn't matter much now, we shouldn't make a big fuss out of it since it's already approved (precisely for the reason that we're *early* in the string freeze). There is some merit in the claim that freeze only starts after the tarball is released, but it's unpractical to make it that (for explained reasons: tracking 69 modules is simply too much). And according to schedule, tarballs should have been ready by 8th, so we are already using that as a guideline. Okay, probably the best way to make it less confusing for translators is to say that the freeze kicks in after the release - i.e. in this case it would have been the 11th. Sound reasonable? I had thought of freezes and releases the same way Mark does (occurs when release is made, at latest the Wednesday specified in the schedule; translators would just pick after Wednesday if they wanted something simple and consistent). I do see how it wasn't very clear, though (the schedule itself is confusing as it spreads the freeze begins message over 3 days; well, except for hard code freeze that occurs on a Monday because there's no associated release). Probably yet another thing that we need to document better. That and what after Wednesday means (start of Thursday for Australia? for Hawaii?) I should start throwing all this stuff that needs to be documented into a list somewhere... Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Metacity string changes -- removing duplicate strings
Hi, I committed a patch to remove some duplicate strings in src/theme-parser.c; bug 309974. Basically it changed No \%s\ attribute on element %s to No \%s\ attribute on %s element in 6 places so that we have 14 copies of the latter string and none of the former. I'm guessing this doesn't affect translations (the latter was already translated) or documentation (I doubt these appear anywhere in documentation), but I'm sending the notification just to be careful. Cheers, Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: UI change request
On 8/3/05, Luis Villa [EMAIL PROTECTED] wrote: On 8/3/05, Dragan Sarbut [EMAIL PROTECTED] wrote: Hello, I am one of the gnopernicus module maintainers. We have a small UI patch in th bug: http://bugzilla.gnome.org/show_bug.cgi?id=308383 that we would like to get in CVS. Seems like only a small string change- i18n, this OK with you? String freeze doesn't happen until next week. ;-) Looks okay to me, 1 of 2. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
A few minor string changes in Metacity
I just committed the patch in http://bugzilla.gnome.org/show_bug.cgi?id=305331 which will change some strings related to launching Metacity. Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Metacity branched
Hi, I've created a gnome-2-10 branch for metacity (we've only had bugfixes that didn't break any freezes up until now). Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: gnome-applets string freeze breakage
On Fri, 1 Apr 2005 03:18:13 +0800, Davyd Madeley [EMAIL PROTECTED] wrote: Without wanting to tell the translators how to do their job. I don't see how having the string marked for translation is necessarily a bad thing. The string is not likely to ever be user visible, but if translators want they can translate it. Hence, the only thing it will affect is people's 100% ratings. Without being in on the culture, is this an issue? Although I am not a translator, I believe you may be looking at this from the wrong angle. Rather than does it hurt that much, I think breaking freezes should be viewed as do I have a really solid reason for doing this. Here are some educated *guesses*, however, at answering your question: I don't believe there is a mechanism in place for marking strings as important versus not-very-important for translation. Translators just check the stats to see what they have untranslated, get an updated version of the module, and then find the untranslated string and translate it. Leaving the new strings in there means translators do extra work--either to translate the string or even to just find out that the string is unimportant and doesn't need to be translated. Further, freeze breakages typically mean that something important has changed, so you're actually giving somewhat of the opposite impression from what you want. When you consider that there's tons of translators, adding up all the extra time required for all translators will probably usually outweigh the cost of reverting a string. And, of course, there's always the problem with slippery slopes as well... Thanks for your hard work on gnome-applets, Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: request to break string freeze, fix spelling regression
On Thu, 10 Feb 2005 09:21:53 +0800, Davyd Madeley [EMAIL PROTECTED] wrote: On Wed, 2005-02-09 at 10:45 +, Mark McLoughlin wrote: Hi Davyd, Its gnome-i18n who approve string freeze breaks. My bad. Do I have a second? String freezes operate differently. You only need one approval, from either Christian or Kjartan. See the What should I do in case I want to break the string freeze? section of Christian's huge email to d-d-l about this (http://mail.gnome.org/archives/desktop-devel-list/2005-February/msg00092.html) Cheers, Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String changes in libwnck and metacity
As warned... On Sat, 29 Jan 2005 14:50:16 -0700, Elijah Newren [EMAIL PROTECTED] wrote: There were two string changes in libwnck (for the right-click on tasklist popup menu): Put on _All Workspaces - _Always on Current Workspace Only on _This Workspace - _Only on This Workspace see bug 165380. However, I now think Current is probably the wrong word here (it seems to have the same meaning as only on this workspace, when it's supposed to be an opposite), so we might change it again in the next day or two. Visible is probably better. There were also the same two string changes in metacity (for the window menu): Put on _All Workspaces - _Always on Current Workspace Only on _This Workspace - _Only on This Workspace see bug 165379. Same issue with the use of Current. Yeah we went ahead and changed the string again, in both locations it's now Always on Visible Workspace instead of Always on Current Workspace. Sorry for the extra spam and extra work. Elijah ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
