SFTtech / openage

Free (as in freedom) open source clone of the Age of Empires II engine 🚀
http://openage.dev
Other
12.74k stars 1.12k forks source link

Translations #107

Open airon90 opened 9 years ago

airon90 commented 9 years ago

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

hackathi commented 9 years ago

It's planned. See tasks.md.

zaxozhu commented 9 years ago

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

zuntrax commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

Count me in on the Spanish one :)

TheJJ commented 9 years ago

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 commented 7 years ago

We should probably use:

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

heinezen commented 6 years ago

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 commented 6 years ago

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 commented 5 years ago

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 commented 4 years ago

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

TheJJ commented 4 years ago

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 commented 4 years ago

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

duanqn commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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.