68 replies to this topic

[ArcSin]

I can translate to russian.

[GunChleoc]

I'd be happy to add this game to my localisation queue for Scottish Gaelic once it has reached the stage that it can be translated.

As a translation system, I warmly recomment gettext po files. This will make your localisers happy!

Online platforms are also a good idea to keep the efforts coordinated, you might even be able to automatise adding online translations into nightly builds. I know that SuperTuxKart do that. Some also automatically inform the translators when changes have been made to the source language file.

Here's the platforms I'm familiar with:

https://www.transifex.com/

http://pootle.locamotion.org/

https://translations.launchpad.net/

[raymond]

I'm also familiar with launchpad and pootle and hoping to help translating into German.

Edited by raymond, 02 October 2012 - 10:33 AM.

[Yggdrasil]

Let's see if we can get this rolling.

I was investigating how to improve translation for GlestAE when stumbling across this thread. There's one big similarity in both projects: Most data is stored in XML files. This includes strings which one has to extract for translation. So, i thought i might share my findings with you here.

First of all, as i'm working on linux, using gnu gettext as i18n framework is more or less a given. There's good tool support and many translators are also familiar with it. You don't have to use the gnu implementation, e.g. boost::locale is a bit more flexible when searching for the message catalog and can support virtual filesystems like physfs.

When using gettext the source and data files are written in english. The strings are then extracted out of these files (preferable done by the build system). For source files this is very easily done with xgettext, see this quick tutorial[1].

Obviously xgettext can't support arbitrary XML structures. Turns out there's a W3C-standard named ITS[2]. With this, one can define rules which text in the XML file should be translated. I recently found itstool[3] which executes these rules and gives us a nice POT-file like xgettext. Only minor problem here: It might get "out-of-sync" what you fed through gettext and what you mark as translatable.

So, as i wrecked my previous test program while trying to get the opengl backend of cairo working, i made a simplier new one[4]. This time using an XML file from 0 A.D. (which doesn't sound ridiculous in german, btw). It shows how to extract string(s) from XML, translate them and render them with pango. It includes a very rough and incomplete german translation (LANG=de_DE.utf8). Look at the Makefile first to see what you need (sorry, no nice build system and linux-only, should be easy to port through).

It would be nice if someone could provide a translation in a more complex script, like arabic or so. Just for testing. Use po/hoplite.pot as template.

Cheers.


[1] http://www.tuxamito....ettext-tutorial
[2] http://www.w3.org/TR...C-its-20070403/
[3] http://itstool.org/
[4] https://github.com/t...xt_pango_opengl

[quantumstate]

Thanks for looking into the technical side of this. With translation part of the reason we have been holding back is because the game is still changing rapidly so translations will go stale rapidly. We were planning to wait a while before starting the translation work.

[Yggdrasil]

I don't think that's a big problem. Any translator should be well aware that it's a moving target and there are string changes every now and then.

gettext can help here a bit. The english strings get extracted from the source files, be it data or code, and get merged with existing translations. It even does fuzzy matching: If the string change is small enough, it still uses the old translation but marks it as fuzzy, so the translator should have a look at it. Old and obsolete translations get removed/commented out. That should be all done by the build system and commited by the one making the string change. There's probably more stuff depending on the translation editor used.

Your english texts probably evolve in the same way like everything else: Step by step. So, why not let translators do the same continuously in parallel? Of course some translations will get obsolete but that's just normal.

Many open source projects integrate their translation system with their version control system. So, translators get every change directly after it was made. Other projects update their language files only when they are near a release and make a "Call for translation" to notify the translators. If you're that much concerned about "wasted" effort by translators choose the latter approach. I think 0ad is stable enough to get at least started.

[Yggdrasil]

Let's keep pushing the ball.

I had another look at your data files and noticed some other formats you use: JSON and javascript embedded in xml.

I already noticed your json files some days ago and json2po, converter from translate-toolkit[1], looks like it suits the job. Use the filter option to pick the leaves you want to extract, e.g.:

json2po --filter=History,Description -o hele.pot hele.json

This only works with current git master[2] of translate-toolkit as i had to patch it and it got already merged upstream. You can only filter for key-names and not their position in the tree, but i guess that's not a problem for you.

Javascript seems to be a bit trickier. The easiest solution i found: Extract the javascript parts with XSLT and let xgettext do the rest. xgettext doesn't support javascript (yet, there's an unmerged patch for it[3]), but you can get away with Python or Perl set as language.

You have to mark strings with some kind of function like _(), otherwise it's not extractable (just how you would do in C++). Best you link the gettext function to it as well (don't know how you call C++ from js).

xml sel -T -t -v '//action' -n mainmenu.xml |\
xgettext --language=perl -k_ -o js.pot -

This will extract all _("strings") from javascript in an action-tag. You need xmlstarlet[4] for the XSLT part.

This has some limitations, e.g. you can't use string concatenations like this one:

_("Open "+url+"\n in default web browser.")

The string needs to be constant. Format strings seem to be the alternative which can be easily added[5]. The translator can then move the special characters of the format string where they need to be in the translated string (that's why it's a bad idea to break it up in multiple strings).

As you can see it gets complex quite easily. Still, it shouldn't be too hard to add it to your build system (i'm not familiar with premake, i might be wrong).

[1] http://docs.translat...lkit/en/latest/
[2] https://github.com/translate/translate
[3] http://lists.gnu.org...2/msg00012.html
[4] http://xmlstar.sourceforge.net/
[5] http://stackoverflow...f-string-format

[arcan]

Hi everybody.
First great work with the game. I've just downloaded it and I'm having fun with it.
I'm french and i can help you with french localization when time comes (done that for other games already)

[Yggdrasil]

As you're planning for 1.0 may i bump this thread. Translation is an important feature you shouldn't forget about. Let's summarize what was "discussed" in this thread.

Ykkrosh suggested to use pango[1] to get bidi and font shaping support (uses harfbuzz internally). Some other nice features of pango: It searches for the right font based on the needed glyphs and some attributes you specified (uses fontconfig). Pango markup can be used to get some basic text effects. It also provides some basic layout features like word wrapping. You basically just throw text at it and you're done. You don't have to worry about the details. The negative things: It pulls in many dependencies and as it replaces all the text rendering and font handling, it probably takes quite some time to integrate.

I suggested to use gettext[2] as i18n framework and pointed out some ways to extract strings from source and data files (see some posts above).

Some people mentioned different online translation systems which make it very easy for translators to get started and to collaberate. To make use of these you have to provide your strings in a compatible format like gettext does. If you want to run it on your own server, pootle[3] is a good project. Other public translation systems are transifex[4] and rosetta[5] (part of launchpad).

[1] http://www.pango.org/
[2] http://www.gnu.org/software/gettext/
[3] http://docs.translat...otle/en/latest/
[4] https://www.transifex.com/
[5] https://translations.launchpad.net/