gnome-menus branched for 2.16
Hi, gnome-menus has branched - 2.16 stuff on the gnome-2-16 branch. Cheers, Mark. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
vino branched for 2.16
Hi, vino has branched - 2.16 stuff on the gnome-2-16 branch. Hopefully we'll get some of the patches languishing in bugzilla into HEAD soon. I'd list which ones I'm hoping to get in, including the one I was just looking at (#333752), but bugzilla has chosen this exact instant to ban my IP address :-) Cheers, Mark. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Difficulties with vino translation
Hi Alexander, I've changed the second comment to: /* * Translators: this string is used ONLY if you * translated "vino-mdns:showusername" to anything * other than "1" */ Does that make sense now? It's all quite obtuse, though. Suggestions are welcome for how to do it in a way that's easier for translators. Cheers, Mark. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
vino branched for 2.12
Hi, vino has branched - 2.12 stuff on the gnome-2-12 branch. Cheers, Mark. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: gnome-menus string freeze breakage
Hi, Thanks Christian - I've branched and unmarked the string on the gnome-2-12 branch. Cheers, Mark. On Sun, 2006-01-08 at 21:38 +0100, Christian Rose wrote: > >From the gnome-menus ChangeLog: > > 2005-12-08 Mark McLoughlin <[EMAIL PROTECTED]> > > [...] > * util/test-menu-spec.c: (main): add -n arg to allow > testing. > > > That addition seems to have broken gnome-2-12 string freeze, about a > month ago (sorry that I didn't notice this earlier). > Perhaps gnome-menus should be branched? > > > Christian ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
gnome-menus branched for 2.12
Hi, gnome-menus has branched - 2.12 stuff on the gnome-2-12 branch. Cheers, Mark. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
GConf branched for 2.12
Hi, GConf has branched - 2.12 stuff on the gnome-2-12 branch. Cheers, Mark. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GConf reverse string freeze breakage approval
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? Cheers, Mark. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GConf reverse string freeze breakage approval
On Sun, 2005-08-14 at 13:17 +0200, Danilo Šegan wrote: > Today at 12:58, Mark McLoughlin wrote: > > > This all seems a little over the top. I approved the change on the 9th > > and you committed it on the 10th. As far as I'm concerned, the string > > freeze only really comes into effect when the release goes out, which in > > this case was on the 10th. > > Translators and documentors don't work with the releases, but rather, > with CVS. Do you really expect translators to track all releases? > (note that tracking CVS and branches is not easy in itself) My point is only that freezes don't instantly come in to effect at a strict date and time. The way maintainers have generally enforced it is that the freeze comes into effect for a module either when the tarball[1] has been rolled, or if no tarball was rolled for that release, when the release itself went out. So, if I was a translator, and I looked at the schedule I would expect the string freeze for a given module to be in effect once the maintainer rolled the 2.11.91 release or once the GNOME 2.11.91 release was official. I'd probably just have waited until August the 11th. 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. Cheers, Mark. [1] - so, e.g. if the string freeze is supposed to come into effect from Beta 2 onwards, the maintainer starts enforcing it once he has rolled the 2.11.91 tarball ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GConf reverse string freeze breakage approval
On Sat, 2005-08-13 at 13:19 -0400, Adam Weinberger wrote: > I jumped the gun and committed a string change without any approval > whatsoever (except from the module maintainer). Danilo asked me to > back out the change, and I'm perfectly willing to do so. But before > I do, I wanted to see whether I can get the string change approved > to remain in rather than backing it out. > > The change is outlined in Bug #301133. This all seems a little over the top. I approved the change on the 9th and you committed it on the 10th. As far as I'm concerned, the string freeze only really comes into effect when the release goes out, which in this case was on the 10th. Cheers, Mark. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Should translators change source strings?
On Mon, 2005-08-08 at 09:48 -0400, Adam Weinberger wrote: > Absence of > po/README.TRANSLATORS will mean that translators have implicit > permission to edit the source strings themselves to resolve simple, > obvious grammar and spelling errors. I think this is mostly fair enough, but I wouldn't like to see a situation where translators routinely re-phrase messages or chose different terminology. e.g. I could imagine a situation where a translator goes on a crusade through nautilus replacing the word "directory" everywhere with the word "folder" where, in fact, there might have been a long discussion in the past about which term is most appropriate in that context. So, I think it makes sense that the maintainer should be involved (through bugzilla) with string changes, even just as an arbitrator, unless its a very obvious typo of some sort. And even with obvious typos, sending the maintainer the patch with a mail "I've just committed this obvious fix" is always polite. Also, I'd hope that translators would be well aware of when string freezes are in effect :-) Cheers, Mark. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: vino branched
On Thu, 2005-05-19 at 10:50 -0400, Luis Villa wrote: > Someone with more perl-fu than me- would it be possible to set up a > script to watch cvs-commits list and send this kind of mail out > automatically, or just update a webpage somewhere? Making maintainers > do this manually (and remember to do it automatically) seems sort of > crap... There's no commit message for branching ... Cheers, Mark. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
vino branched
Hi, I've created a gnome-2-10 branch for vino. Thanks, Mark. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
libwnck branched
Hi, I've created a gnome-2-10 branch for libwnck. Thanks, Mark. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
gnome-desktop branched
Hi, gnome-desktop is now sporting a brand spanking new gnome-2-10 branch ... Cheers, Mark. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
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.2&r2=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 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
gnome-panel and gnome-menus branched
Hey, I've branched gnome-panel and gnome-menus - GNOME 2.10 stuff should go on the gnome-2-10 branch. Cheers, Mark. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
GConf branched
Hi, GNOME 2.10.x development is now on the gnome-2-10 branch of gconf. Cheers, Mark. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
gnome-netstatus branched
Hi, GNOME 2.10.x development is now on the gnome-2-10 branch of gnome-netstatus. Cheers, Mark. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
sabayon translations
Hey, Just a heads up for all the eager beavers who have already translated the messages in sabayon in GNOME CVS - until now, the messages in the Python code weren't marked for translation because I hadn't taken the time to figure out how. Now that that's fixed there's 76 messages to be translated instead of 11. Please feel free to let us know of any i18n problems you spot. Thanks, Mark. ___ 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
Hi Davyd, Its gnome-i18n who approve string freeze breaks. Cheers, Mark. On Wed, 2005-02-09 at 18:13 +0800, Davyd Madeley wrote: > http://bugzilla.gnome.org/show_bug.cgi?id=166762 > > The patch looks like this: > Index: Locations.xml.in > === > RCS file: /cvs/gnome/gnome-applets/gweather/Locations.xml.in,v > retrieving revision 1.59 > diff -r1.59 Locations.xml.in > 33106c33106 > < <_name>Sebang > --- > > <_name>Sepang > > This is a really amateur mistake on my part, and should have noticed it. > I want to break freeze to fix this up. I can commit an update to all of > the translations too to prevent undoing the translators hard work. > > --d > > ___ > release-team mailing list > [EMAIL PROTECTED] > http://mail.gnome.org/mailman/listinfo/release-team ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translating panel clock format
Hey, On Wed, 2005-02-02 at 10:30 +0100, Christian Rose wrote: > /* Translators: This controls whether the GNOME panel clock should >display time in 24 hour mode or 12 hour mode by default. The only >valid values for this are "24-hour" and "12-hour". If your locale >uses 24 hour time notation, translate this to "24-hour". If your >locale uses 12 hour time notation with am/pm, translate this to >"12-hour". > >Do NOT translate this into anything else than "24-hour" or >"12-hour". For example, if you translate this to "24 sata" or >anything else that isn't "24-hour" or "12-hour", things will >not work. */ Thanks, I've included that now. Cheers, Mark. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Translating panel clock format
Hi, In gnome-panel, translators can translate the strings "24" and "24-hour" to "12"/"24" and "12-hour"/"24-hour" depending on whether a 12 or 24 hour clock is the norm in that locale. Unfortunately, its easy to miss the fact that you're not supposed to translate these values like other strings, so you get the likes of: msgid "24-hour" msgstr "24 sata" Which neither the panel nor gconftool-2 can understand. There are comments in the po file explaining the situation: #. Translators: the only valid values for this are "12-hour" and "24-hour" #: applets/clock/clock.schemas.in.h:4 But I guess its easy to miss that. I don't have any other ideas how to make this foolproof, though. Anyway, I've fixed up all the translations in gnome-panel to have the correct values. Thanks, Mark. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
