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

Re: [i18n]Source packages and translation templates q.



Quoting Neil Williams (codehelp@debian.org):

(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.


Attachment: signature.asc
Description: Digital signature


Reply to: