[Localization] Euro contributions Re: More translations needed?

[Clytie Siddall]

On 15/06/2008, at 11:35 AM, s.boutayeb at free.fr wrote:

> Quoting Bastien <bzg at altern.org>:
>
>> As a sidenote - there will be a specific translation problem: if « La
>> main à la pâte » decides it can help OLPC by providing content, how  
>> this
>> content will be translated (e.g. in Kreyol)?  Using something like
>> Pootle or any .po-related solution looks awkward to me...
>>
>> If people have ideas, I'd be glad to hear.
>>
>
> My suggestion here is to adapt the content to the respective  
> situation rather
> than to stick to a litteral translation.
>
> The technical side of the translation issue can be handled via an  
> collaborative
> solution like Pootle, provided the texts are accordingly preformated.
>
> An alternative could be to use a so called "CAT tool" (or computer  
> assisted
> translations tools) such as OmegaT. OmegaT is an open-source  
> translation memory
> software application.
>
> Source "OmegaT, the free translation memory tool": http://www.  
> omegat.org
>
> The main features are ( http://www.omegat.org/en/omegat.html ) :
>
>   1. Fuzzy matching
>   2. Match propagation
>   3. Simultaneous processing of multiple-file projects
>   4. Simultaneous use of multiple translation memories
>   5. External glossaries
>   6. Document file formats: XHTML and HTML, Microsoft Office 2007 XML,
> OpenOffice.org/StarOffice, XLIFF (Okapi), MediaWiki (Wikipedia),  
> Plain text, PO
> files
>   7. Unicode (UTF-8) support: can be used with non-Latin alphabets
>   8. Support for right-to-left languages
>   9. Compatible with other translation memory applications (TMX)


As long as we use a supported translation editor, we get the features  
we need. In particular, we need to be able to:

  • keep track of updates
  • check for errors

For document translation, TM (translation memory) become less useful,  
since the strings are so much longer, and much less likely to match  
previous translations.

I've translated a number of docs, and so far I'm happiest with using a  
package like po4a or the Translate Toolkit [1] to convert the doc to  
and from PO format. Free-software translators are mostly still using  
PO, so this fits our workflow best.

One of the key PO features which will benefit us in docs translation  
is msgid-previous, supported in recent versions of gettext. Editors  
have moved to support this feature, which means that when a string is  
changed, the _previous_ string is displayed as well, allowing you to  
see what has actually changed.

My translation editor [2], for example, also highlights the changed  
words etc. in the string. This is a huge help in docs translation,  
where strings are often long and complex, so you can waste a lot of  
time trying to work out what has changed since last time.

Ideally, projects split up long docs into shorter files, so the task  
is doable in the short spans of time we volunteers have available.  
When you have an hour or so to contribute, you get much more  
satisfaction out of translating a smaller file, than you do of  
completing only a small part of a much larger file. So I'd recommend  
splitting up manuals, etc., into smaller files during the conversion  
process.

Once the files are up on Pootle, translators can choose to download  
them (in whatever format suits), to translate them online, or a  
combination of both.

from Clytie

Vietnamese Free Software Translation Team
http://vnoss.net/dokuwiki/doku.php?id=projects:l10n

[1] http://translate.sourceforge.net/wiki/guide/nonpo

[2] http://www.triplespin.com/en/products/locfactoryeditor.html
Unfortunately, only available for Mac OSX.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://lists.laptop.org/pipermail/localization/attachments/20080615/7db4d75e/attachment.pgp