Translations: String freezes, CVS converging, Packaging

[Dimitris Glezos]

O/H Jeremy Katz έγραψε:
> 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.

Sounds good.

>> ## CVS convergence
>>
>> [...]
>> 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 :(

Discussion on '#fedora-admin' gave us a lot of insight. Thanks for the explanations.

For those who weren't there, hosting the PO files on a different SCM from the
source is not a no-brainer and both Jeremy and Jesse don't recommend it. So
instead of moving the PO files off elvis, it's better to move everything. We can
do it right after F7 is out; give people the time they'd like to settle on
'cvs.fedoraproject.org'.

Actually, our Docs code is currently hosted there and does requires
translations, so we can go ahead and start translations; settle the ground for
the rest of the apps. We've created a 'cvsl10n' CVS group which will be given
permissions on the 'po/' dir and see how things roll.

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

As said yesterday, ideally, the Fedora L10n community could act as "upstream"
for the PO files of any application, even externally hosted ones. The L10n
project would like, for example, to have easy-access to applications, either
they are technically hosted on 'cvs.fp.org', or on 'hosted.fp.org' or on remote
repositories.

The above, of course, needs further discussion to find a nice technical way to
establish it that does not require translators working with 5 different tools
(cvs, hg, web UI etc).

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

OK, I see we'll be having big problems with this and it's pretty obvious it is
not feasible.

Basically, the L10n problem is that of requesting a package update/repackaging
(of an app that Fedora is upstream) because of important new translations. The
drill is almost always the same: we want repackaging for *all* packages which
have new translations:

 1. Before *every* release
 2. Some time after a release (say, 1 and 3 months)

The first point should always happen, even for only few new translations.
Language coordinators could control the second point by judging if enough new
(or important) translations were made on a package between the latest update and
$now.

-d



-- 
Dimitris Glezos
Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B
http://dimitris.glezos.com/

"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--