cvsl10n CVSROOT

[Dimitris Glezos]

O/H Mike McGrath έγραψε:
> Dimitris Glezos wrote:
>> O/H Karsten Wade έγραψε:
>>  
>>> For Paul, Dimitris, and others ...
>>>
>>> Mike and I were discussing CVS structure for cvsl10n.  These are
>>> configuration choices for e.g. CVSROOT, and etc.
>>>
>>> Goals:
>>>
>>> * R/W for the po/ directory in documentation modules (/cvs/docs/.../po)
>>> * Same for po/ under any merged packages (< Extras), although for the
>>> most part those are projects that should have translation upstream
>>> * Pull in sample content from elvis.rh.c:/usr/local/CVS
>>>   - part of planning to be able to copy all content and switch
>>>
>>> Here is a *test* import of the existing L10N CVS -- note that this
>>> content may get removed at any time, and people in the cvsl10n have
>>> write access to it:
>>>
>>> http://cvs.fedoraproject.org/viewcvs/?root=l10n
>>>     
>>
>> Sounds OK to me. What's the next plan?
>>
>> Some more ideas/food for thought:
>>
>> We could have "virtual folders" like we do on i18n.r.c: a translator
>> does a `cvs
>> co translate` there (`cvs co l10n` in our system) and receives
>> something like:
>>
>>  anaconda/
>>    af.po
>>    am.po
>>    anaconda.pot
>>    ...
>>  apacheconf/
>>    af.po
>>    ...
>>
>> Also, our TODO should somewhere include automerge: each time a new POT
>> file is
>> committed the PO files could be automatically updated (currently not
>> supported
>> at i18n.r.c but is in the TODO list there too).
>>
>> Finally, since we're at it, we should probably start making plans for
>> http://l10n.fedoraproject.org/. A *great* example is
>> http://l10n.gnome.org/.
>> This is probably the only tool the L10N community needs (although the
>> job can be
>> done locally too). Any help from the TurboGears experienced folks in
>> Infrastructure would be greatly appreciated. :)
>>   
> You know more about the translations needs then I do.  Paul had also
> mentioned "http://translate.sourceforge.net/" as an option.  On the one
> hand I'd be fine if we wrote our own app in turbogears.  On the other
> hand, I'd love to use something already out there.  Let me see what I
> can do about the modules and the po files.

See below, after the short explanations.

> And just for the education
> of myself and those on the list.  Can you tell us the difference between
> l10n and i18n is, and how you guys do what you do, what the heck a po or
> pot file is.  Just educate us in general about your needs and how
> cvs.fedoraproject.org will help you accomplish them.

In short:

  * i18n: Making something *able* to be localized, ie develop baring in mind
that it should be localizable. That might mean, for example, to use gettext to
print stuff, not assume everybody uses "am/pm" for time etc.

  * l10n: Making a product local. Translating strings, make sure encodings work,
have proper fonts, keyboard layouts, adopt cultural values, local customs etc.
It is the complementary process of i18n: it takes place after it. Basically, the
distinction is subtle but we can simply talk about L10N to keep things clear.

  * POT: A specially-formatted file that contains every string the software has
that should be localized (translated). Example: 'anaconda/anaconda.pot'. Example
2: Docs project uses xml2po to grab XML strings and produce POT files.

  * PO: A one-to-one translation for every string in the POT file. Example:
'anaconda/de.po' holds the german translations of anaconda. A translator
initially copies the POT file to 'de.po' and uses tools like kbabel and gtranslator.


## i18n & l10n process

  * The maintainer creates his product with i18n in mind. She freezes the
strings, exports strings in the POT file and tells L10N folks to go on and
translate. When the translation freeze comes, he grabs the PO files back and
produces localized versions of the application. For software, that means she
compiles them into binary MO files and packages the app. For Docs, we just
create HTML versions with the translated strings/images in them.

  * The translators use the POT file to create or update their PO file (using
`cp` for the first and `msgmerge` for the second). They then commit the PO file
back to the maintainer (either with email or with the project's SCM). Because of
the many PO files and their frequent updates, a project usually helps
translators by having a web-based statistics page that shows the percentage of
translation for each PO file (application, component) for each language.

An answer for the question "Why move?" can be found on [1].

  [1]: http://fedoraproject.org/wiki/L10N/Projects/CVSInfrastructure#WhyMigrate


## L10N statistics

You can see the existing Fedora (Red Hat) translation statistics page at [2]
(yes, it should be called l10n-status). The GNOME L10n portal can be found at
[3] and the KDE one at [4].

  [2]: http://i18n.redhat.com/cgi-bin/i18n-status
  [3]: http://l10n.gnome.org/
  [4]: http://l10n.kde.org/

We want (and need) to create something similar to the above. It is not really
urgent though, since translators can see their translation stats locally from
their command line.


## The translate toolkit

It is basically a set of tools that help managing PO/POT files. It also includes
an *online* web-based translation tool (called pootle) that some projects use.

Our translators have made it clear they want to use a SCM for the translations
and said an *additional* web-based tool would be nice. So, let's first create
our SCM and we'll see about whether we should use pootle.

It would probably be useful to have pootle installed somewhere (it really helps
when we need *fast* translations from *many* contributors). But whether we'll
have it by default accessing all files OR leave it up to the language maintainer
to choose which PO files will be available through Pootle is another discussion.


Hope these helped having a clearer picture.

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