Jump to content


Recommended Posts

I want to push these thread. The deveoping of 0ad goes very fast and I think the the right direction, except the translation support. Please implement this for max gaming experience. I would also like to translate 0ad to German.

Edited by raymond
Link to comment
Share on other sites

Currently engine only supports Latin characters. I checked arabic, hebrew and georgian with no success. They all turn into "????" in the game and in the cache files. We must do something for this.

The engine supports those characters as well, it's just that there needs to be a font with them included added to the game :)

Link to comment
Share on other sites

Arabic and Hebrew can't work properly since our GUI engine doesn't support RTL/bidi text (and support would probably be quite hard to add; I expect we'd have to redesign and rewrite all the GUI text layout code, probably using something like Pango), and also I believe Arabic needs complex font shaping support (our text renderer assumes each Unicode codepoint corresponds to a single independent glyph bitmap; I expect we'd have to change to using Pango/HarfBuzz to render runs of text at run-time to handle that properly, which should be less hard than bidi but still quite hard). Georgian (at least modern Mkhedruli, apparently) looks like it has neither of those problems, so it ought to mostly work fine if it's added to the bitmap fonts (need to add to the character list and rerun the fontbuilder script; but the current serif font (TeX Gyre Pagella) doesn't include those glyphs, so we'd need to find a decent free font and update the script to use that for the relevant Unicode blocks).

Link to comment
Share on other sites

SDL isn't relevant (we don't use it for anything except setting up the initial window and handling input) - I think we'd primarily just need a way to render a paragraph into a bitmap at runtime, which should be fairly easy with Pango + Cairo, then we can convert it to an OpenGL texture and render it. (Plus some caching to maintain decent performance, and some extra integration with the GUI layout code, etc.)

Link to comment
Share on other sites

  • 2 months later...
  • 4 weeks later...
  • 2 months later...

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:




Link to comment
Share on other sites

  • 2 months later...

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.


[1] http://www.tuxamito.com/joomla/index.php/en/component/content/article/60-gettext-tutorial

[2] http://www.w3.org/TR/2007/REC-its-20070403/

[3] http://itstool.org/

[4] https://github.com/tetzank/its_gettext_pango_opengl

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

  • 1 month later...
  • 1 month later...

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/

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...