[Fwd: Translations: String freezes, CVS converging, Packaging]

[Jeremy Katz]

(For the reply I sent to fedora-devel...)

On Tue, 2007-03-06 at 22:02 +0000, Dimitris Glezos wrote:
> ## String freezes
> 
> For F7, the RelEng team has introduced string freezes in the schedule [2]. This
> means that application strings for F7 should be complete *by 19/3*. Translations
> made after this date (and before the freeze) should be guaranteed to be included
> in the release.
> 
>   [2]: http://fedoraproject.org/wiki/Core/Schedule

Yep -- this should hopefully help a lot, although I expect it will take
a release or two to fully institutionalize itself.  We should probably
have a procedure to be followed for cases where strings need to be
changed.  Here's a shot in the dark:

String Freeze Policy.  As of the string freeze date, translatable
strings should not change to help ensure high quality translations for
the Fedora 7 release.  If you have a case where you need to change a
string after this date, please send notification to fedora-trans-list.

Alternately, we could make it a "get approval from the release team and
then send notification", but I'm not sure if we want to go to that level
for the first time through.  Another important part is that if
translators notice string changes after the string freeze, mail should
be sent to the maintainer of the package and probably fedora-devel-list
as well make sure they realize the problem.  

> To do this we need to try not to add new strings after the freeze and let the
> L10n folks know if they need to do so. Also, maintainers should repackage before
> each release (and after the translation freeze) without a bug needing to be
> opened.

Yep

> ## CVS convergence
> 
> Right now translations are done on `i18n.redhat.com`. This requires contributors
> to have one account on the Fedora Account System (FAS) and a different
> one for translations. With the merge of Core and Extras, now is a good
> point to get rid of this distinction.
> 
> The plan is to move all PO files on Fedora infrastructure under a new
> CVS group (cvsl10n) [3]. An email will be sent to all translators to create a
> FAS account if they don't have one and join the cvs group. Members of the L10n
> team and ambassadors will help with this process.
> 
>   [3]: http://fedoraproject.org/wiki/L10N/Projects/CVSInfrastructure

Does this also include moving the actual source that's hosted on
elvis/i18n?  If not, then I have very strong concerns...  separating the
source code from the translations has a lot of downsides as it requires
a manual sync between the two.  And these never work well :(

> At this point we could discuss the idea for Fedora to act as upstream for
> the translations of outside-hosted projects such as yum, smolt, and
> pungi. The proposal is to host and maintain those project's
> translations with the existing Fedora L10n community.

See above :-)  Although there's definitely a need for some problem
solving here, as there is plenty of desire to have projects hosted in
non-CVS SCMs as well.

> ## Packaging translations
> 
> One final plan (and probably the one that needs most discussion) is about
> changing the way we package translations. Right now PO files live inside the
> application and are packaged there (GNOME-style). The plan is to move the PO
> files in to their own directory and distinct package [4] (KDE-style langpacks).
> 
>   [4]: http://fedoraproject.org/wiki/L10N/Projects/TranslationsPackage

I'm very very very very strongly opposed to doing this.  It's a nitemare
from an installation point of view and also from a space point of view.
The packages which do translations like this require absolutely horrible
hacks within our software management stack to even have a *chance* of
people getting the translations installed for their apps.  Contrast to
the apps which include the translations in the package... install the
package and voila!, you have the translations for it.

> Cons: L10n team should maintain a package (or many) and packages should be
> altered to accomodate the different locations of PO files.

Con: makes the source COMPLETELY divorced from the translations.  So if
I update an app and you don't update the translation package, all new
strings aren't translated.  Unless you push a new (massive) translation
package.  This does not scale.  

> Pros (many): increased modularity and maintenance (L10n repackages at
> will). App packages will be smaller in size -- we could provide
> one langpack or different ones per language.
		
The size difference for most of the app packages are going to be
negligible.  But now, to push a new pirut with new strings, I also have
to coordinate the pushing of n langpack packages.  Which are each
significantly larger than the amount you save on the app packages.  

Jeremy