[Suggestion] Better way of handling locales

[Zbizu]

Hi everyone,

I want to suggest a more clear way of handling language strings in the client, something that would make translations / language edits easier to create.

Problem:

• current way of translating strings use actual text so minor changes in it ruin all language sheets
• English is hardcoded instead of being an independent language sheet

Solution I propose:

• something that would be more consistent, for example: tr("staminaTimeLeft", hours, minutes) instead of tr("You have %s hours and %s minutes left", hours, minutes)

English language sheet would be the template with translations filled like other languages, this way:

  translation = {
    ["staminaTimeLeft"] = "You have %s hours and %s minutes left",
  }

and translation priority would be:

• selected language (eg. PL, "EquipmentWidgetTitle" -> "Ekwipunek")
• English if selected language has no string for that value (eg. "EquipmentWidgetTitle" -> "Inventory")
• key if English has no translation of that string (eg. "EquipmentWidgetTitle")

Pros:

• easier client localization
• keys indicating exact place where the text appears (eg. "staminaTimeLeft" makes it clear that this text is responsible for stamina display)
• more professional approach (that's how they translate Android apps: https://developer.android.com/studio/write/translations-editor, we could learn from them)

Cons:

• no backwards compability(?)

[lolima]

It's the same concept used by Babel for Angular/React. Each language has a .json file and there's an additional software that helps translating them simultaneously.

[slawkens]

The problem with this concept is, that it's impossible to constantly invent new keys for specific texts, because it has limited length.

Laravel (PHP Framework) has good documentation on this: https://laravel.com/docs/8.x/localization#using-translation-strings-as-keys

I will quote it here:

For applications with a large number of translatable strings, defining every string with a "short key" can become confusing when referencing the keys in your views and it is cumbersome to continually invent keys for every translation string supported by your application.

So saying short: if application has large number of translatable strings (like OTClient has), it will be painful to define every translation as key.

I understand your solution to the problem, but I am against making it as a standard way of handling localisation in OTClient.

Edit

I actually looked at translation strings and they don't seem to be big. The OtClient itself is big app, but the strings itself not.

So your idea seems reasonable. You have convinced me.