Quoting Neil Williams (email@example.com): (of course, I mostly disagree with the initial comment as most, if not nearly all, Debian developers are now very i18n-friendly and most of the time do what's needed to make translators' work easier) > Translators don't want their work discarded, upstream don't want to > waste time putting in PO files which are already out of date. > Therefore, putting a POT file in the source package can be precisely > the WRONG thing to do. > > What needs to be done is a call for translations *before* the release, > giving time for all updated translations to be received and then the > package released and uploaded with as many translations updated as > possible. When the POT file changes, another string freeze, another > call and the package gets uploaded with updated strings already in > place. Well, here I feel the need to comment. This is quite theoretical assumption. If this reasoning is pushed, then nearly no localization works happens during the release cycle and everybody waits for the freeze. The, when the freeze comes, translators are squashed with gazillion of call for l10n updates. So, by far, regular updates (and therefore regular calls for l10n updates) are really needed. For instance, look at dpkg or apt translation work: only those who kept the pace can now follow the huge numnber of needed updates (I'm still fighting with dpkg manpages French translations just because I gave up on updates for a few months). So, anything helping this to happen is welcomed....which includes providing up-to-date POT files (and keep them in the various VCS which is something I always fought for. > Therefore, I think you should think this through more carefully. > Blindly enforcing that all source packages which support l10n also > include the POT file is counter-productive. Encouraging *some* to > include POT files once the package is in a state that the strings don't > change that much any more is good. Encouraging maintainers to allow time > for a genuine string freeze and make a call for translations, including > the updated translations in the actual release, is a FAR BETTER idea. That works well with developers that have a strict developing agenda with planned released, development plan, etc. You're one of these, Neil, and that's much appreciated. However, other development styles may better fit with constant providing of localization material.
Description: Digital signature