Rigs-of-rods: Localization is done wrong.

[only-a-ptr]

Our localization works in the following manner:

1. A developer writes English phrases into the source, for example _L("Loader")
2. The _L() macro detects user's language and if it's non-english, it looks up the translation for the english phrase and displays that, instead.

This is plain wrong because languages don't work this way. The fact that single english phrase/word suits multiple places doesn't mean the same will be true for any other language. The phrase "Loader" above was not chosen randomly - when I first started 0.38, it used my native language (czech) and the loader UI window was titled "Nakladač" (= "Cargo loader"). I immediately knew where's the problem.

Our options:

• [UPDATE Dec 2018] Use gettext contexts: seems to be exactly what we need to resolve the ambiguities: https://www.gnu.org/software/gettext/manual/html_node/Contexts.html
  
  
  
  • use ID labels like MAINMENU_BUTTON_OPTIONS. Feature: if a translation is missing, this label will be displayed directly. This will make everyone notice it's wrong, which is both good and bad thing depending on context. Advantage: If someone needs to rephrase the English text, (s)he only needs to edit the translation, not the ID-label. Advantage2: Since the ID-label is not intended for display, programmer is free to give it any name, hence no clash needs to occur.
  
  
• Use english text + some kind of text-group ID. Both groupID+text would be used to look up the translation. Advantage: If the translation is missing, the english text is used. Disadvantage: If the text needs to be rephrased, ALL translations need to be updted because the text is the key, literally. Disadvantage2: If you get 2 equal english words close to each other, for example on the same UI panel, you'll probably have single groupID reserved for the panel. In that case, you either violate the uniqueness principle (backward!), create more groups (hack!) or somehow phrase the english to become unique (silly).

I favor the former option (MAINMENU_BUTTON_OPTIONS).

Opinions?

[only-a-ptr]

Re-making of the GUI has begun: https://github.com/RigsOfRods/rigs-of-rods/pull/1333 - so it's time to start re-making the localization, too.

UPDATE Dec 2018: This is outdated, I suggest to use https://www.gnu.org/software/gettext/manual/html_node/Contexts.html instead

We need a syntax for the message ID strings. Here's my draft:

// Syntax: AREA]/WINDOW[/CONTAINER]/[TextPreview]
// Areas:
//  m = main menu
//  s = simulation
//  x = (multiple areas)
//  r = rig editor     (near future)
//  t = terrain editor (future)

// Examples:

m/menu/SinglePlayer         // Main menu
m/menu/MultiPlayer
m/menu/Settings
m/menu/About
m/menu/ExitGame

m/about/AboutRigsOfRods     // Main menu - about dialog
m/about/OK

x/mpusers/Name              // The multiplayer userlist (both menu and sim)
x/mpusers/Ping

s/top/Simulation            //  Simulation top menubar
s/top/Vehicles
s/top/Tools

s/top/sim/GetNewVehicle     // ... and it's menus: Simulation
s/top/sim/ReloadCurrVehicle
s/top/sim/RemoveCurrVehicle

s/top/veh/UserName          // ... vehicles menu

s/top/tools/FrictionSettings                // ... tools menu
s/top/tools/ShowNodeNumbers

[vido89]

I would gladly translate it to Serbian when I suppose .po files are avalible

[Hiradur]

IIRC RoR makes use of gettext for localization. I think gettext takes into account the location of the source string in the source code (source file + line) to prevent what you described. See here for an example: https://en.wikipedia.org/wiki/Gettext

I think on Transifex the location of the source string is mentioned when doing translations. It's possible that the translation in your example is based on a misunderstanding.

[only-a-ptr]

@Hiradur Thanks for the input, but I didn't find any evidence of it on the wikipage. Further, such arrangement would be a very bad idea because both file name and line number of the source may change (the line number is quite certain to change IMO).

It's likely that I'm not using gettext the way it was intended, but I don't care. TBH I think gettext is a living fossil and the surrounding toolchain can only appeal to die-hard UNIX commandline programmers.

[Hiradur]

Maybe the README.md located at https://github.com/RigsOfRods/rigs-of-rods/tree/master/tools/linux/l10n can help you understand it a bit better. I can't say I fully know how it works but to keep up with changing line numbers you have to extract a new template shortly before the next release and merge it with existing translations. Usually the merging process can transfer all existing translations to their new correct location.

Your solution has the disadvantage that it would be a homebrewed solution unique to RoR which means it would lack support from translation platforms like Transifex and knowledge from contributors.

[only-a-ptr]

@Hiradur Ugh... WHAT?!! 🤢 😡 How are people still willing to put up with this?

Thanks for bringing this into my attention. Seriously I'm disgusted right now. I imagine l10n as simply matter of loading a string table from an INI file and then looking up texts there via some sensible hash table. I completely fail to understand why are all internet resources directly or indirectly pushing me to use the gettext suite which is famously unportable beyond unix, forcing you to hack around and use other libs, and it's all pointlessly complicated.

Umm... I need to do more research on the state of affairs with l10n these days. Nothing makes sense to me.

[Hiradur]

Well, it looks complicated but on the other hand it works and can be automated so that you can forget about it after you set up some scripts and run them from time to time.

[AnotherFoxGuy]

I've added support for looking up strings with contexts to MofileReader: http://anotherfoxguy.com/MofileReader/classmo_file_reader.html#a9459d21908db8ba4e40693b4332777ce

[only-a-ptr]

@AnotherFoxGuy Awesome

[ulteq]

@only-a-ptr Can we close this?

[only-a-ptr]

Closing as localization is now done absolutely right.