Translations

[airon90]

Hi, is there a plan to translate openage? I could localize it in Italian and Esperanto

[hackathi]

It's planned. See tasks.md.

[zaxozhu]

I could translate to Ukrainian and Russian. But for that we need good localization system

[zuntrax]

A basic amount of localization can be done by using strings from the language dlls. The convert module supports exporting these. Is gettext suitable as a localization backend later on? Edit: gettext is recommended in tasks.md.

[andrekupka]

I am currently writing down the concepts and documentation for the nyan language. Probably the translations can be simply done by nyan modification files (they will be explained in the documentation in detail). The basic idea is, that defined objects can be modified by a modification file. If for example the villager's default display name is "Villager", it can be updated by a modification file to "Dorfbewohner" (which is the german translation of villager). Thus each translation to a language can be represent as a separate modification file.

[franciscod]

Count me in on the Spanish one :)

[TheJJ]

The translations are only required for openage-created things like the game editor, the lobby, the dedicated server etc.

The in-game names are provided by the original media. Once we have free replacement media files, they need to have translations, of course. But the translation will also reside in the openage-data repository then, as it is specific for the free media files and not the game engine itself.

Translating the engine is probably not worth the effort, all of the internet can understand english I hope.

[TheJJ]

We should probably use:

https://doc.qt.io/qt-5/qtlinguist-index.html https://doc.qt.io/qt-5/qtquick-internationalization.html

[heinezen]

Best Practices for localization from the IGDA:

https://cdn.ymaws.com/www.igda.org/resource/collection/2DA60D94-0F74-46B1-A9E2-F2CE8B72EA4D/Best-Practices-for-Game-Localization-v22.pdf

https://cdn.ymaws.com/www.igda.org/resource/collection/2DA60D94-0F74-46B1-A9E2-F2CE8B72EA4D/Localization-ready-2.1.pdf

[TakesTheBiscuit]

Worth having a quick think over the implications from the UI -- this is after all a game; and i've found i the past in certain Steam games (Team Fortress 2 used to suffer for example) that when someone uses a different language set in their name it explodes the visuals on screen and breaks the game.

I would imagine that certain Russian words and German words will be rather long and presents annoying truncation or worse strings exploding out of where they should be and end up overlaying or obscuring maps/units/actual gameplay.

Anyway

[simonsan]

We should probably use:

https://doc.qt.io/qt-5/qtlinguist-index.html https://doc.qt.io/qt-5/qtquick-internationalization.html

Just some thoughts: I know about tr(); in Qt and QtLinguist, just wanted to let Mozillas localisation system "Project Fluent" here - it also has full bidirectionality support, based on clear text files and with this is clearly addressing non-developers. Although it might be easier to implement basic translations with tr() and external Software like QtLinguist, it could make sense to use something where the community can easily help with the translations without the hurdle of another software and just by using a texteditor. But in the end I don't have any experiences with Fluent, but wanted to let it here as an "alternative".

https://github.com/projectfluent/python-fluent

Syntax-Guide https://projectfluent.org/fluent/guide/

On the other side, there are tools to use the Google API to help translate Qt Linguist TS files, so in the end, it might really be the easiest way for everyone to stay with Qt own functions.

EDIT: Some article about Fluent: https://www.heise.de/newsticker/meldung/Fluent-Mozilla-veroeffentlicht-Tool-fuer-Software-Lokalisierung-4400513.html

[duanqn]

I can sign up for translation from English to Chinese (simplified & traditional).

[TheJJ]

As we have zero localisation infrastructure in place, it would be awesome if you could come up with an approach in our codebase. Ideally using the common Qt approach, so we have a dedicated subsystem in libopenage/translation/. Once we have the implementation, we can start doing the actual translations step by step.

[simonsan]

As far as I see it one year after my post we would have options like this (to add: from my limited understanding XD)

• use the Qt own system, which is more integrated but would consolidate dependency on Qt (QTranslator is in QCore though, but we should probably create an Interface class there to have our own abstraction instead of using all that Qt stuff all over our codebase)

• use sth. like Project Fluent and integrate the FTL (Fluent translation list, localization file format used for describing translation resources) into our ecosystem. Would make us more independent from Qt and would just make us dependant on a file format that we could create a parser for

• we could probably also do both eventually if we use that interface class for QTranslator we could use the Qt ecosystem for translating stuff but parse translation data from FTL files

[duanqn]

I had a look at Project Fluent but I don't like its idea. The cost is too high to get all those grammar details right across all languages. I think this is exactly what we should avoid. e.g. Instead of "this villager has 2 melee attack" we should just write "Melee attack: 2" on the UI It would be beneficial to look at the text used in AoE II.

[simonsan]

I had a look at Project Fluent but I don't like its idea. The cost is too high to get all those grammar details right across all languages. I think this is exactly what we should avoid. e.g. Instead of "this villager has 2 melee attack" we should just write "Melee attack: 2" on the UI It would be beneficial to look at the text used in AoE II.

Hmm, I know what you mean. We shouldn't forget here, that for sure we wouldn't need to deal with much complicated grammar inside your unit stats example, but what about campaign conversation translations for example. What about translations in the Help texts. Tooltips, Campaign descriptions, History tab. We will definitely need a good framework for translations.

[duanqn]

@simonsan Well I just don't know what will happen when we support Japanese where the sentence can depend on the gender of the speaker and how modest the speaker is... But maybe Qt has the same problem. Meanwhile, Qt supports RTL languanges but I don't see this mentioned in Project Fluent. Neither of them supports top-down languages like Mongolian or Manchu, but we probably won't have those translations.

[simonsan]

@simonsan Well I just don't know what will happen when we support Japanese where the sentence can depend on the gender of the speaker and how modest the speaker is... But maybe Qt has the same problem.

Sorry, can you elaborate where you see a problem? Imho that totally depends on how we do it, no? PF is made by Mozilla and used for big projects like Firefox, they also have Japanese localisation and I've didn't heard of any problems, you?

"Fluent aims to eventually replace all legacy localization formats used in Firefox today." https://firefox-source-docs.mozilla.org/l10n/index.html

Meanwhile, Qt supports RTL languanges but I don't see this mentioned in Project Fluent. Neither of them supports top-down languages like Mongolian or Manchu, but we probably won't have those translations.

Project fluent has strong bidirectional support indeed:
https://projectfluent.org/ (3rd point from the top: "Fully-featured") https://firefox-source-docs.mozilla.org/l10n/overview.html#content-vs-ui also here: https://unicode.org/reports/tr9/

[duanqn]

I just looked at the examples on their home page. It seems like if something can vary in one languages, then it has to be a variable in all languages. For example, the "-sync-brand-name" doesn't need to vary in English but it's created because Polish and Italian might change it. Therefore I think if Japanese requires variable for "I", "We" and so on, they have to be variables in other languages as well. But when I think about it, PF might be the right way to tackle with these problems because if you have m and n varieties for two components in a sentence, you only need to write O(m+n) branches, instead of O(mn) in the classical way.