Leaderboard

We don't need to rewrite any functions, we just create a thin wrapper in each context, which then calls the original function. That sounds like an RMS feature request, more than a trigger feature request. And what if someone else picked the same namespace? Also, namespacing does not prevent the type of error modes that may arise when two different scripts unknowingly manipulates the same globals: http://en.wikipedia....mputer_science) It's not about trust, it's just bad design. Honestly, it's a bit like wanting to run everything as root just for the sense of power it grants

For the last time, it is a Hindu symbol we are using, not a Nazi symbol. The symbol was used for thousands of years before the Nazis and will likely be used in non-Nazi contexts well after both you and I are both dead. But beyond all that, we have already said many times that we are perfectly 'ok' with a Germany-only version of the game where the symbols are removed. I am aware of at least a few commercial games that have done this. You continually ignore this, claiming we are Nazi propagandists instead. Your behavior rises well-beyond simple emotion to the level of fanaticism. We can't spend any more time addressing this issue with you if you will not listen to our compromises and instead claim we are propagandists. Thread locked.

Nothing new, but an interesting sighting nonetheless:

only i was read Pinned topic

If you haven't already voted, please vote for 0 A.D. Only 1 day left until voting ends

Maurya, Magadha(The core of the Mauryan empire and many others)

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.

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.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