Return-To-The-Roots
Expose / Move Roman Campaign and World Campaign localized texts to Launchpad TextDB
Currently most of the game text are located in Launchpad PO/MO TextDB, though the Roman Campaign descriptions and messages as well as World Campaign description text are being read directly from LUA files.
Moving campaign text to Launchpad would make it easier to manage and translate.
The campaigns use a different translation system independent of the gettext/po files to stay extensible and for campaign authors to provide translations. I'm not really sure if we should move those texts.
Maybe we can use some kind of fallback if the campaign file doesn't provide a translation to use the one from the game. Might cause strange results if a wrong string is found though.
Can't we use a system like you can provide the string constant for the text, if it is in the files, the text is used, if it's not found, that string constant is used?
I'm not sure I follow. Where is which string constant and where is text and in which files?
Currently we have:
- English strings in sources (cpp files) -> automatically put on launchpad
- Translated strings from launchpad in po/mo files, shown instead of the above when available
- english strings in lua files
- optionally translations in the lua files
Well, I'm trying to say, can't we call that gettext function in LUA code, to get a text, add the campaign texts as string in the cpp (english variant), then we can translate it and get a localized version in the LUA code?
Just to be clear: We still need to have the current system so custom campaigns work. We can only use that for our own campaigns we ship.
Besides that yes: We use the same syntax in Lua as in C to get translations _('World'). So we can likely feed those directly to gettext files without repeating them in Cpp files where they can get out of date and hard to attribute to specific campaign files.
So the logic would be for Lua: Lookup in registered translation, fallback to gettext, fallback to return the original (English) string. But that could theoretically yield strange translations if the actual translation was done in a specific context for e.g. a log message or window title and used in another context in Lua. Should be rare enough though.
So those 2 combined (run translation string extraction on our lua files & fallback to gettext for non-registered Lua string) would basically be similar enough to what you propose, wouldn't it?
IIRC I proposed including strings to translate in effectively dead C++ code just for translation purposes . But can't neither find it nor remember the context now.