[Mailman-i18n] I'm trying to make translating mailman easier

[Clytie Siddall]

On 16/06/2006, at 7:37 AM, Barry Warsaw wrote:

> On Jun 15, 2006, at 5:41 PM, emf wrote:
>
>> I would like to make your life translating mailman easier, as I am
>> redoing all the web templates for my Summer of Code project.
>>
>> I want to get a feel for what *you* have to do to be a translator for
>> Mailman and/or other software projects.
>
>> If you have a cheat-sheet/script/something I'd be happy to see it. If
>> you could send me any wishlists/complaints/etc, or urls I should  
>> read,
>> send them my way, please.
>
> It might also be useful to update the wiki with anything that other
> translators might find helpful.

Yes indeed. :)

emf, there are two different issues here: (1) being a free-software  
translator (it might be best not to get into professional  
translation, since there are a lot of differences) and (2)  
translating a specific project, in this case, Mailman.

In my experience, the main barriers to translation are linguistic vs.  
temporal, and procedural.

LINGUISTIC VS. TEMPORAL

Problem:
You need a very thorough understanding of both languages and  
computing, the more thorough, the better. You will be required to  
understand a staggering array of specialist vocabularies, which vary  
wildly from one project to another. Yet you are not a professional  
translator, and you're doing this voluntarily in bits and pieces of  
snatched free time.

How you can help:
1. Each project can assemble a glossary, including all specialist  
terms. Translators can specify which terms need explanation. Each  
glossary item should include at least one real-life example from the  
software, preferably in screenshot. This glossary should be in wiki  
form, so it can be edited, updated and improved.
2. Context!! The project needs to supply as much context as possible,  
especially for complex and unusual strings. As soon as gettext-0.15  
is out (currently available in CVS), the project can start using it.  
This new version of gettext supports the new msgstxt feature:

> As of today, it is addressed in the GNU gettext CVS.
> http://savannah.gnu.org/cgi-bin/viewcvs/gettext/gettext/
> The NEWS file will state in a few days:
>
> * GUI program support:
>   - PO files can now contain messages constrained to a certain  
> context.
>     Most often such a context is a menu, dialog or panel  
> identification.
>     The syntax in the PO file is
>       msgctxt "context"
>       msgid "original"
>       msgstr "translation"
>   - The xgettext program can be told through the --keyword flag which
>     function/macro argument has the role of a context.
>   - The (non-public) include file gettext.h defines macros  
> pgettext, dpgettext
>     etc. that take a context argument.
>   For more information, see the node "Contexts" in the manual.

The project can expect context for each string, even something as  
brief as "menu item" or "verb" can help avoid incorrect translations.
3. Encourage developers and translators to work together and help  
each other. Create and maintain a positive community spirit, where  
effort is rewarded and difficulty is surmounted through cooperation.  
Encourage the creation of resources like glossaries, review  
procedures and processes for feedback from users. Allot plenty of  
time for translation and updates. Use the pre-release and release- 
candidate structures to allow for revision of translations.

PROCEDURAL

Problem:
Each project has created its own procedure, often for historical  
reasons. They use different ways of controlling source, of managing  
translations, of communication and of handling information. Any new  
translator has to invest a lot of time in learning all the  
procedures, and in monitoring mailing lists, IRC channels etc. (I  
have to read and respond to 45 mailing lists at last count).

How you can help:
Minimize procedure and allow choice. For example:
1. Use one of the existing major translation projects (the  
Translation Project, Gnome, KDE, Debian) which translates many  
software packages and which already has many translators working in  
effective language teams. This gains you more access to translators,  
and higher translation quality, since these language teams support  
and enforce quality, and the established translation projects are  
expert at what they do. They combine and refine what a single  
translator can do, into a cooperative model.
2. Use a translation interface like Pootle [1] to facilitate access  
for translators. Debian is currently implementing Pootle in this way.  
Single-application projects like BitTorrent [2] also use Pootle.  
Pootle is an option, not the only way to translate, but an interface  
that allows the translator to choose the method that suits him or her  
best. It has effective access control and quality assurance  
processes, and is free software.
3. Make sure your procedures are documented in a user-friendly way  
and easily available in wiki form for editing and update. Layering  
your own procedures on top of one of the main translation projects,  
or implementing Pootle, will simplify this enormously. Let  
translators put their time into translation, not into project procedure.

I can give you more details on any of these. Mailman already does  
some of them. If you're working on the web templates, revising the  
language used to make it as simple and clear as possible, creating a  
glossary to explain the terms used, creating screenshots with  
tooltips or other means to show how translatable strings are used,  
and wrapping the whole thing up in a glossary would be extremely  
useful to Mailman translators. What Bruno mentions, prioritizing  
strings, would also be very useful, as the Mailman interface file is  
very large, which alone puts off translators. Its size and complexity  
are its biggest problems.

I hope this answers some of your questions. :)

from Clytie (vi-VN, Vietnamese free-software translation team / nhóm  
Việt hóa phần mềm tự do)
http://groups-beta.google.com/group/vi-VN

[1] http://translate.sourceforge.net/wiki/pootle
http://pootle.wordforge.org/

[2] http://translate.bittorrent.com/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-i18n/attachments/20060618/2ab71445/attachment.pgp