[Mailman-i18n] I'm trying to make translating mailman easier
clytie at riverland.net.au
Sun Jun 18 12:53:11 CEST 2006
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
>> 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
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.
> The NEWS file will state in a few days:
> * GUI program support:
> - PO files can now contain messages constrained to a certain
> Most often such a context is a menu, dialog or panel
> 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.
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  to facilitate access
for translators. Debian is currently implementing Pootle in this way.
Single-application projects like BitTorrent  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)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-i18n/attachments/20060618/2ab71445/attachment.pgp
More information about the Mailman-i18n