Re: Approving of string freeze breaks (was: Re: Fwd: String additions to 'gnome-keyring.HEAD')
Em Sex, 2008-02-15 às 14:10 +0100, Johannes Schmid escreveu: > Well, I wouldn't blame developers that much. Many teams (besides the > really big) start translating not really before string-freeze and thus > those bug-reports come in after freeze. Developers are usually not > really aware of potential translation problem before someone pokes them. Indeed. Which makes me think if it's time to change some policies. Either teams do start translating *before* the freeze (in order to file bugs in time), or we should change the term 'freeze' by a new one. My case: I've added some new strings in vino in the beginning of the cycle, and, only now, after the freeze, I got bugs against some wrong strings. I prefer to wait and change them for 2.24 :(. Regards, -- Jonh Wendell www.bani.com.br ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Approving of string freeze breaks (was: Re: Fwd: String additions to 'gnome-keyring.HEAD')
El vie, 15-02-2008 a las 10:34 -0300, Jonh Wendell escribió: > > Indeed. Which makes me think if it's time to change some policies. > Either teams do start translating *before* the freeze (in order to > file bugs in time), or we should change the term 'freeze' by a new > one. IMHO, string change announce period should be a good time for teams to start translating. Claudio -- Claudio Saavedra <[EMAIL PROTECTED]> ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Approving of string freeze breaks (was: Re: Fwd: String additions to 'gnome-keyring.HEAD')
That's what we've being doing in Brazil, but I'm not sure smaller teams can do it. (Not that ours is large :) Leonardo Fontenelle http://leonardof.org 2008/2/15, Claudio Saavedra <[EMAIL PROTECTED]>: > > El vie, 15-02-2008 a las 10:34 -0300, Jonh Wendell escribió: > > > > > Indeed. Which makes me think if it's time to change some policies. > > Either teams do start translating *before* the freeze (in order to > > file bugs in time), or we should change the term 'freeze' by a new > > one. > > > IMHO, string change announce period should be a good time for teams to > start translating. > > Claudio > > > -- > Claudio Saavedra <[EMAIL PROTECTED]> > > > ___ > gnome-i18n mailing list > gnome-i18n@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-i18n > ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Approving of string freeze breaks (was: Re: Fwd: String additions to 'gnome-keyring.HEAD')
I don't quite agree with the conclusion here, that developers are not to blame at all. In my experience if developers would read the documentation on i18n [1]in the developer guide, especially the part about "Use comments" "Never split sentences" "Plurals" "Avoid markup wherever possible" and beside this add comments on sentences and words that are clearly ambiguous in English (that they can know even if they don't know any other languages) then we could easily avoid half(ish) the i18n-related bugs, and then other half would seem like less of a burden during freeze. So I don't really see any reason to change anything in the procedures. Regards Kenneth Nielsen [1] http://live.gnome.org/TranslationProject/DevGuidelines ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Approving of string freeze breaks (was: Re: Fwd: String additions to 'gnome-keyring.HEAD')
Hi! OK, from developer point of view: > "Use comments" You know what you mean when you created the string and it is really difficult to estimate if the string is understandable for others. Developers only add comments when it is technical necessary, something like "translate the same as in program xy". > "Never split sentences" > "Avoid markup wherever possible" Thease two are really avoidable, the developers are too blame for that. > "Plurals" On the one side many developers are not yet aware of that feature and on the other side it is simply forgotton. To conclude, it is not about to blame someone, it is about having a rational view on things and to accept that string freeze breaks WILL happen because of various reasons. That's about was Danilo said on GUADEC about string freeze breaks when he briefed the i18n-team, IIRC. Regards, Johannes signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Approving of string freeze breaks (was: Re: Fwd: String additions to 'gnome-keyring.HEAD')
All rigth all rigth, it just sounded like blame when people are talking about that _the problem_ is that nobody translates before string freeze. Anyway, to get back to the subject at hand. There are more than just one question in this. When we get mail on the list about changes in strings the reason for these mails generally fall in four categories. 1) Fixing strings as reported in a bug 2) Marking some strings for translation that had simply been forgotten 3) Erroneous commits because people didn't realize we were in freeze 4) Left over development, forgotten (and possibly important), and therefore a break is requested #1 is absolutely necessary and I certainly don't mind, it is just like you said, that will happen, we find errors, report them and developers fix them, that is all god. And in my opinion the procedure is just fine as it is, so we have the approval process to make sure that it is evaluated what the break is due to, and if it is #1 then it should be approved per default. #2 Even though this is not a string freeze break it generates noise on the mailing list and so it helps in wrongful observation that we have many breaks. What is perhaps even more important is that even though it is not technically a break, it is still annoying to translators who may have already started translating the package, and it does seem sloppy and slightly impolite to translators. #3 is just annoying and nothing else, it might seem weird to translators that we apparently look more on the release schedule than some developers, but generally no damage is done, the commits are just reverted and all is fine, however, it once again help to create this wrongful impression that we have many breaks. #4 is a matter of judgment in the individual case (and of size of the commit). That, I will leave in much more capable hands. So to sum up and address the subject of the mail. I my humble opinion we should keep the strings freeze and the procedure for handling breaks. The #1's should still go through the approval process but should be approved per default, so were taking them through the process only to make sure that they are actually number #1's. Besides that, the fact that we are having this discussion now suggests to me that there are things we could all do better. Translators need to become A LOT better at reporting bugs as early as possible. And for the translation teams that have the resources to accept loss, that could even be before freeze. And developers need to become better at avoiding the #2 and #3, and so when we have no more #2 or #3, then certainly the #1 and possibly even the #4 wont ever be a problem. Regards Kenneth Nielsen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
