Re: Totem branched for 2.26
2009-03-04 klockan 08:39 skrev Deniz Koçak: 2009/3/4 Philip Withnall philip.withn...@gmail.com: Totem's branched for GNOME 2.26. The branch name is gnome-2-26. Development will continue on trunk. l10n.gnome.org updated. Thanks. Hi Deniz, It seems like you added the branch, but did not link to it from the Gnome 2.26 release set. I have done this just now, so the correct stats show up now. — Wouter signature.asc Description: Digital signature ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Here we go again *SIGH*
On þri, 2009-03-03 at 14:41 +0100, Vincent Untz wrote: I would also point out that having no freeze break (with requests from the developers, of course) would be bad: having some breaks is a good sign, showing that the development is active and not dead. Of course, we don't want tons of freeze breaks. And of course they should be approved first. Vincent The responses from the developers indicate quite clearly that they are not satisfied with the methods of string freeze. Presently a number of developers, are deliberately breaking the string freeze and thereby creating trouble for translators. The argument seems to be: We break string freeze because we can. Both developers and translators are working on volunteer basis, doing their best. To stop this from developing into a conflict, I suggest the following changes in the development process: * The development in trunk branches very early into releases, giving developers more time to fix bugs in a release. During this time, the developers focus on the branch. * After an early branch, a string freeze is imposed on the trunk, giving translators time to translate the trunk. * We introduce release po files that are essentially the strings in a release but not in the trunk it branched from. This would make the work of the translator much easier. * When string freeze is released off the trunk, new strings and translations can be merged back from the release(es) to the trunk. So essentially this describes two ideas: release-po files, and separating the work area of developers and translators. It goes without saying that the string freeze would have to be 100% effective, with no possibility to break it. What do you think? -- Anna Jonna Ármannsdóttir coordinator The Icelandic GNOME Localisation team http://l10n.gnome.org/teams/is was 11% translated ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Here we go again *SIGH*
2009-03-04 klockan 13:21 skrev Anna Jonna Armannsdottir: On þri, 2009-03-03 at 14:41 +0100, Vincent Untz wrote: I would also point out that having no freeze break (with requests from the developers, of course) would be bad: having some breaks is a good sign, showing that the development is active and not dead. Of course, we don't want tons of freeze breaks. And of course they should be approved first. The responses from the developers indicate quite clearly that they are not satisfied with the methods of string freeze. Presently a number of developers, are deliberately breaking the string freeze and thereby creating trouble for translators. The argument seems to be: We break string freeze because we can. I wouldn't go as far as stating that the freeze breaks are deliberate. Both developers and translators are working on volunteer basis, doing their best. ...and this is why. Many people work in their spare time, and in the weeks before a release they feel more obliged to fix bugs, which, inherently, sometimes involves changing UI strings. Personally, I think we're doing quite well for this cycle, with most freeze breaks happening early in the cycle. It would be interesting to see how many strings have been changed after the string freeze came into effect, and how this situation was for earlier releases. Numbers, anyone? — Wouter signature.asc Description: Digital signature ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Here we go again *SIGH*
Am Mittwoch, den 04.03.2009, 14:15 +0100 schrieb Wouter Bolsterlee: Personally, I think we're doing quite well for this cycle, with most freeze breaks happening early in the cycle. It would be interesting to see how many strings have been changed after the string freeze came into effect, and how this situation was for earlier releases. Numbers, anyone? Numbers from my GUADEC 2007 talk: 2.13 had 24 string freeze break requests. 2.17 had 5 string freeze break requests. andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
String additions to 'libgweather.HEAD'
This is an automatic notification from status generation scripts on: http://l10n.gnome.org. There have been following string additions to module 'libgweather.HEAD': + City in Wyoming, United States::Wyoming + State in United States::Wyoming Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
String additions to 'ekiga.HEAD'
This is an automatic notification from status generation scripts on: http://l10n.gnome.org. There have been following string additions to module 'ekiga.HEAD': + Calls history + The history of the 100 last calls Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Here we go again *SIGH*
Le mercredi 04 mars 2009, à 12:21 +, Anna Jonna Armannsdottir a écrit : On þri, 2009-03-03 at 14:41 +0100, Vincent Untz wrote: I would also point out that having no freeze break (with requests from the developers, of course) would be bad: having some breaks is a good sign, showing that the development is active and not dead. Of course, we don't want tons of freeze breaks. And of course they should be approved first. Vincent The responses from the developers indicate quite clearly that they are not satisfied with the methods of string freeze. Presently a number of developers, are deliberately breaking the string freeze and thereby creating trouble for translators. The argument seems to be: We break string freeze because we can. I think it's unfair to say developers are using this argument or even that they're deliberately breaking the string freeze. If you look at the breaks, we have the following situations: + the string was not marked as translatable. = we want the break anyway, since it can only make the situation better. + the developer asked for permission before committing. = this was the decision of the coordination team to accept the break. + the developer didn't ask for permission, but it was approved afterwards. = this is bad and the developer should be told so. But the result is the same as the above case. + the developer didn't ask for permission, and it was rejected afterwards. = this is bad and the developer should be told so. The break gets reverted. (if it doesn't get reverted, please tell the release team) + this is needed for a really really really important bug fix (eg, related to security) = it doesn't happen often since it's really an exception, but in such cases, the opinion of the coordination team is bypassed (but the coordination team would likely approve such a change anyway) + the module does not follow the GNOME freezes (eg, gtk+, glib) = not a lot we can do, except ask the maintainers of such modules to think of translators (and I would say they do) I don't think developers break string freeze because they can. When they do so before asking for permission, it's mostly because they forget about it. It'd be interesting to look at what happened this cycle and see how much of the breaks had no request (and were for completely new strings, and not to mark existing strings translatable). Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String additions to 'ekiga.HEAD'
Hello Damien, GNOME Status Pages wrote: This is an automatic notification from status generation scripts on: http://l10n.gnome.org. There have been following string additions to module 'ekiga.HEAD': + Calls history + The history of the 100 last calls Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. We are currently in string freeze; could this change be reverted and postponed ? Cheers, Frederic ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [Fwd: Re: String additions to 'libgweather.HEAD']
Claude Paroz wrote: Dan, The fuzzy with Bordeaux is fixed, but there is still a problem with Wyoming which did not get back the State in United States msgctxt. Should be fixed now. Sorry. -- Dan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String additions to 'ekiga.HEAD'
I wrote: There have been following string additions to module 'ekiga.HEAD': + Calls history + The history of the 100 last calls Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. We are currently in string freeze; could this change be reverted and postponed ? Looking a bit further into this issue, it seems the string was removed yesterday (r7713) and added back today (r7714). I'll let the translators decide if it's ok (but you should pay attention to this, it is quite stressful for translators to see string additions). Cheers, Frederic ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String additions to 'libgweather.HEAD'
Le mercredi 04 mars 2009 à 13:43 +, GNOME Status Pages a écrit : This is an automatic notification from status generation scripts on: http://l10n.gnome.org. There have been following string additions to module 'libgweather.HEAD': + City in Wyoming, United States::Wyoming + State in United States::Wyoming Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. Note that this is the second revert which restore libgweather to its state before the string freeze. Thanks Dan! Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Here we go again *SIGH*
On mið, 2009-03-04 at 14:47 +0100, Vincent Untz wrote: It'd be interesting to look at what happened this cycle and see how much of the breaks had no request (and were for completely new strings, and not to mark existing strings translatable). Yes, it is probably best to wait and see what happens this cycle. If the number of freeze breaks is low, then there probably is no problem at all. From my personal point of view, it is acceptable to have a string freeze break below 1 percent (or one string) per each translation file. Anything at that level would not bother me much. Best regards, -- Anna Jonna Ármannsdóttir coordinator The Icelandic GNOME Localisation team http://l10n.gnome.org/teams/is was 11% translated ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: gpointing-device-settings
Le mardi 03 mars 2009 à 20:01 +0100, Wouter Bolsterlee a écrit : 2009-03-03 klockan 19:11 skrev Gabor Kelemen: Daniel Nylander írta: tis 2009-03-03 klockan 18:32 +0100 skrev Daniel Nylander: I found out that gpointing-device-settings doesn't seem to be in DL. .. and mousetrap Have the maintainers of these asked for adding them to d-l? I can't remember, perhaps they have good reasons for not doing so, or something. It seems that gpointing-device-settings was only imported last week, so the most likely explanation is that the developers just forgot about it. I don't know about mousetrap, though. I just added both modules: http://l10n.gnome.org/module/mousetrap/ http://l10n.gnome.org/module/gpointing-device-settings/ Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
