Re: Here we go again *SIGH*



Hi!

> If I just "forget" about the procedures I am supposed to adhere to when I use SVN account, developers will have my head on a plate. If I just "forget" about the release schedule for GNOME that just means that my translations doesn't make it in, and the Danish users will suffer.
> 
> I agree and understand that all the break situations listed above are valid and necessary. Where I get a little annoyed is when I get the idea from a string freeze break, that the particular bug could just as easily have been fixed one week earlier, outside of the string freeze period (which is always the case with the "I forgot to mark this for translation"-breaks (even though its not a break)). Please note, that I'm not asking volounteer or paid developers to work more, I'm just asking them to parrallel shift their efforts 1-2 weeks. We have all have hard deadline at release, developers have quite a few extra deadlines during the cycle, but please don't use the string freeze break procedures as a way to make the string freeze deadline elastic at the expence of the translators. That's all I'm saying, as politely as I can.

That's a hen end egg problem! Translators start translating at string
freeze and start to file translation and string related bugs there. So
developers start fixing string/translation issues at string freeze
because they don't notice those before.
This situation has improved recently thanks to some big teams (like es)
that are starting very early and report bugs early but it cannot always
work out especially for bugs that only affect view languages (e.g.
plural issues).

Most developers seem to work in "C" Locale anyway or (like me) simply
cannot see easily if a string is simply not translated to their locale
as they added it recently or if it's not marked.

Anyway, I really don't see a reason to complain about breaks this year
as those were very few and also the forgotten strings were very few.

Regards,
Johannes

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]