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/