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
