> The problem I have with this is the assumption that translators will > always be available to do this on so short notice. That is just not > realistic. You are virtually demanding that 11 people give priority to > this rather minor issue, even though they may have other activities > planned (even other translations). > > So what if only 8 translators respond? Should the other 3 languages and > all users there be punished because their translators were unable to > react within so short a time period? Yeah, I was considering this and I understand that very short delays may be a problem for these translators. In that specific case, the changes are *very* minor (Developer's Reference writing style compliance) and, for instance for French, I just unfuzzied one string and compelted the other one with "and previous versions". > IMO translators do have a right to consider their work done during a > freeze. At some point the burden _has_ to shift from the translators to > the maintainer. You cannot keep on asking them to update the same package > again and again. > Unless of course a string change fixes an important issue. As I understand > it, this is not the case here though. The changes are merely cosmetic and > could easily be postponed until post-etch. Yes. Hence my proposal: -handle the changes in unstable with regular l10n updates and an upload in a short time -update the package through t-p-u *without* the debconf changes > An possible strategy would be to request translation updates and to keep > the package frozen until updates for _all_ currently up-to-date > translations have been received. Theretically, yes. But experience whows that this is nearly impossible to achieve unless we set up incredibly long delays, because some translators are sometimes fairly slow to react (or use crappy ISP who use crappy RBL lists that make the mail contact really difficult, etc. > > IMHO the role of i18n coordinator also involves looking after the > interests of translations/translators and saying "sorry, no, these > changes are not acceptable at this point in time". So what you propose is reverting the changes or maybe still ask the maintainers to do an update throught t-p-u?
Attachment:
signature.asc
Description: Digital signature