GUI localization

[Zini]

You can't GMSTs. They are hardcoded on engine level.

[akortunov]

They are hardcoded on engine level.

Ok, I can use CSMWorld::DefaultGmsts::Strings and CSMWorld::DefaultGmsts::OptionalStrings arrays then.

I tested this with "Time played" feature. A current implementation:

1) Used "#{sTimePlayed}" variable in savegame window instead of hardcoded value
2) Added string in system openmw.cfg file with fallback value:

Code: Select all

fallback=String_TimePlayed,Time played

3) Modified Gui::replaceTag to read fallback values from openmw.cfg
4) "sTimePlayed" GMST added to DefaultGmsts::Strings and DefaultGmsts::OptionalStrings arrays
5) Created RU.omwaddon with an actual localized value

Result: works fine.

Can anyone suggests a better solution?

[Chris]

I've always imagined using regular po or mo files that normal apps use for localizing strings, then having some way for omwgame/omwaddon files reference them (along with the engine itself, where appropriate). That way you have all the normal tools for creating localized text strings that you would for an app, provide them with the game or mod's data files, then just reference them as appropriate. It's also expandable... for a mod to use new localized strings, they just provide po or mo files containing them and reference it in the omwaddon. No need to fuss about with new GMSTs or fallback settings that mods can't declare (just define a fallback language, and if a text string isn't available for the user's language, use the fallback language instead).

[Zini]

Please do not add GMSTs. I would have to veto that. Sorry, if I did not make that clear enough. But the best option right now is to not do any work on localisation of extra strings. This is a post 1.0 feature.

If you absolutely must you can bypass the GMSTs and just use the fallback values from the cfg file and then distribute custom cfg files. But I would prefer if you didn't. That will only confuse things more once we switch to the proper system.

[psi29a]

@Zini: does this negate my work on adding default values for openmw.cfg?

I'm 80% ready, the hardest work is coming up with your own words for things.

[akortunov]

This is a post 1.0 feature.

Ok. Sorry for bothering you then.

[Zini]

@akortunov: No bother at all.

@psi29a: It does not. Separate issue.

[Okulo]

Agreed. Except that I have done most of the rethinking already. Don't have the time to get into it right now. I will present it as a part of my large post-1.0 brain dump, once we have the 1.0 release out of the way.

I can only imagine the size that this brain dump is going to be. Should we donate for new servers to contain that post alone?

[akortunov]

once we switch to the proper system

What kind of proper system will we use? And why can not we implement it before 1.0?
Can we just store strings in file (XML, for example) and add this file via openmw.cfg?

[Chris]

What kind of proper system will we use? And why can not we implement it before 1.0?
Can we just store strings in file (XML, for example) and add this file via openmw.cfg?

I'd imagine any kind of string localization method would not depend on modifying config files. Games and mods would want to include their own translatable strings, so they should be part of the game/mod data (either in the esm/esp files, or in the data archive as something like po or mo files that the esm/esp can reference) and be automatically used when the mod is enabled.