Translations: String freezes, CVS converging, Packaging

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

 



Hi all.

The L10n project has been discussing for a while now (also at FOSDEM with
mspevack) about ways to improve our translation processes. We estimate that more
than 1 out of 3 users uses a non-English desktop.

First of all, let's clarify here that for the time being, we are referring only
to applications that Fedora is upstream (anaconda, system-config-*, and
basically most of the non-deprecated stuff that appears on [1]).

[1]:http://i18n.redhat.com/cgi-bin/i18n-status?page=status&locale=es&branch=HEAD&essential=0

The plan in mind includes three actions.


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

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.


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

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.


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

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

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.


Comments, suggestions?



-- 
Dimitris Glezos
Jabber ID: glezos@xxxxxxxxxx, GPG: 0xA5A04C3B
http://dimitris.glezos.com/

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

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux