Gallaecio

Would it be possible to somehow get a list of the effects that I would need to apply to, say, a simple “0 A.D.” text in black color, to get it to look like in the logo? (same for “Empires Ascendant”) Hopefully GIMP instructions? Translators could follow those instructions to make a localized version of the logo. Even better, we could try to create a GIMP script, so that translators only need to write the logotype text in the right places with a color specified by us, and by running the script they could get the right effects automatically applied.

leper is right. Also, I can reassure you that the repo builds on Linux. What I cannot assure you is whether or not it builds in any other platform, although it should ICU is a must have, but I’m wondering what to do with tinygettext. The library has changes, so it’s actually a fork, and the main project does not seem to be maintained. I believe SuperTuxKart developers also forked it, which being it that small is not much of an issue. So maybe we could integrate it more into our build system somehow and get rid of the scons build dependency. Anyway, I guess all these things will pop up as soon as the patch gets reviewed.

Can we somehow simply check whether the features that 0 A.D. requires are supported or not? New drivers may appear, old drivers my start supporting the features we require, and checking the features instead of the drivers, if possible, sounds like a safer and more flexible approach.

It is. You can always leave the placeholder string untranslated or construct it in some way differently from the other strings so that, even if player might not notice the different because it still makes sense in your language, you do know that it is different. Anyway, there should not be surprises here in the short term.

Done, you can now translate three combinarions of wall and gate. I’ve kept the placeholder-based string around, so if a new combination appears, this string will be used instead. If you detect such a new combinarion, just let me know and we can add it to the list of translations that we can fine-tune.

I will look into it this afternoon, thanks for reporting!

What changes I make in English strings I make them on the game. (Then I have those strings extracted into a POT file that is uploaded to Transifex.) I will have that Spartan string fixed in a couple of minutes, thanks again!

Fixed the unnecessarily-different strings as well. If you build the game from sources using the internationalization branch, feel free to report space issues in the interface as well. I for one need to make the Team column wider both in the game setup dialog and the Diplomacy dialog.

OK, the “None” issue is solved now. You have three different translation context: ai (no ai engine), team (no team), or victory (no victory condition).

I would personally favor using the actual Ancient Greek alphabet. Same for other languages where possible.

Regarding where to provide feedback, it’s up to you. Right now, possible places are: • Here, in the forums, in this thread or a new thread. It’s not that bad a place. • In Transifex. One of you two reported the None issue there and I got that report as well. • In my Github’s Issue tracker. As soon as the internationalization implementation is up, though, we should use 0 A.D.’s Trac. By the way, feel free to report size issues as well. The current GUI implementation is not the best, and I don’t think it would be easy to make things adapt to text size, but we can always simply make things bigger

Regarding % f, that is a known limitation of Transifex. You can download the French translation for offline translation as a PO file, edit the translation in an editor such as PoEdit or Localize, and then upload the translation. This will allow you to bypass this limitation. I’ve noted the rest of the feedback.

I had forgotten to "follow" this thread. I already took note of the None thing, I will also look into the rest. Thanks a lot for the feedback.

Right, better to deal with it when we run into the issues

I’ve added context support to the internationalization branch (to solve another issue I had). It is certainly necessary for this feature, but it is not the issue I was referring to. The problem here is that, as far as the game goes, there is no logical distinction between a male entity, and female entity or a gender-neutral entity (e.g. a tree). I guess this could be added, though, with a Gender property in the templates — Lucky us, units of the same type are always of the same gender so far.

The game uses its own engine, specifically build for this type of game. I don’t think moving to a different engine would be such a good idea, it would take a lot of time, and might not be the best performance wise. Regarding the tools to create artwork and souds, as far as I know contributors are free to use those, and I believe at least some of the artists are doing so already.

In fact, someone has started working on the French translation: https://www.transifex.com/projects/p/0-ad-unofficial/language/fr/ Please, let me know if you have any doubt after reading the content pointed by the links that fabio provided.

Ups, right. No icons then.

What about using icons for classes? (with localizable tooltips)

There does not seem to be a concept of Gender in the entity XML files but, if added, it should be doable. I will look into it on my internationalization branch.

That's acceptable to me, as long as we are constant across the board. That would come from the <Attack/Bonuses> element of the template. That is acceptable to me as well, provided that we do not rely on the actual data for the display name. That is, "Infantry Spear" is a logical statement, "Entity with the Infantry and Spear classes", and we would need to have display strings for each possible combination of classes; in the case of English, for "Infantry Spear", "Spearmen" could be the display string, for example. I’ve not seen the current implementation yet, but if XML files are loaded all at once and not on demand, we could do this adding a second phase to the XML loading that adds this information in memory only, keeping the XML files as they are. I’m OK with that, provided again that we do not rely on the actual data for the display name. In the case of classes, we can show them as a comma-separated list and translate each class on its own.

Currently, unit template files have a translatable field called Tooltip. This field, as far as I’ve seen, may contain the following information: • Unit classes (recently prefixed by ‘Classes:’). • Units that this unit counters (prefixed by ‘Counters:’). • Units that counter this unit (prefixed by ‘Countered by:’). • Unit description. In the XML, these are differenciated by line breaks. What would you think about providing separated fields for each one of these? • DisplayClasses (as opposed to the class names used in the game logic) • Counters • CounteredBy • Description Pros would be: • Easier to keep consistency between tooltips. • Ability to use a different font or text style on different elements. • Ability to reorder the elements in the interface easily, without changing all XML files, nor affecting translations. • Ability to show a different combination of these bits of information in different contexts. • Easier for translator, as they would only need to translate the "Prefix: <data>" strings once, and the rest of the strings will have a decreased size. And I honestly cannot think of cons here. Also, if you agree, should I let you do this yourselves in master, or should I do this myself in my i18n branch? Or should I maybe write a patch against master only for this?

All that would be great once the implementation is in place. That is, it does not make much sense to document the internationalization and localization process does not apply to master but to an external Git repository. For instance, the Transifex project will be different once/if using Transifex is approved by the development team. Also, I don't think the forums are the right place to write documentation, the right place for that would be the wiki, and I'm not sure if it's OK to write documentation about this just yet (although I should probably ask). Translation is a different story. Anything you translate now in the current Transifex project you can keep latter. Now some answers: - How to add a language: Request a translation team in the Trasifex 0 A.D. (unofficial) project. - How to translate, including links to tools: Transifex documentation. - How to proofread: General translation documentation. - How to test: Check out my github repository, i18n-gallaecio branch, and follow the 0 A.D. documentation to build and run the game. - How to submit translations (Can translations be grabbed automatically from Transifex?) - They can, using Transifex's command-line client: http://support.transifex.com/customer/portal/topics/440187-transifex-client/articles (however, this is more interesting for developer once everything is in place, translators can just place the files for their language in the right folders manually).

I decided to start working on image internationalization and localization. This is mostly important for those languages that translate game names, however, any image might need to be somehow modified for a certain locale. The approach I plan to follow is that of The Battle for Wesnoth. In The Battle for Wesnoth, any image can be translated. When the game loads an image, it first checks if within the folder where the image is there is a localization folder with a localized version of that image for the current locale. For example, if the current locale is "gl", and you have a file in "folder/image.png" and a localized version in "folder/localization/gl/image.png", when the game is required to load "folder/image.png" it first checks if "folder/localization/gl/image.png" exists, and since it does exist, it loads "folder/localization/gl/image.png" instead of "folder/image.png". Simple To help translators to keep images up to date, they have a system which basically generates checksums of translated and original images, and if developers update an original image, translators can check in a file that the original image was modified after they localized it the last time, so they know they might need to update the localized image. Another important part of the image localization is explaining to translators how to localize specific types of images. It is important to supply translator with either source versions (for example, in Gimp format) of images, or with detailed steps to generate certain images from scratch. Here is where there is not much I can do, and I need your help. Can anyone point me to an editable version of "public/art/textures/ui/pregame/shell/logo/0ad_logo.png", "public/art/textures/ui/pregame/shell/logo/fundraiserlogo.png" and "public/art/textures/ui/pregame/shell/logo/product.dds" if there is one? What font are we using for "A.D." in "0 A.D." or for "Empires Ascendant"? How are DDS images compressed? (if I save a version modified with Gimp uncompressed it takes 3 times as much space as the original one).

Great, keep them coming