Usdx: Language selection should not be translated into the current language

[RattleSN4K3]

Currently, the language selection shows every single language in the currently selected language.

This makes it for the language English the following list:

• English
• Euskara
• Finnish
• French
• Galician
• German
• Greek
• ...

Having it acidentally switch to Russian for instance would make the following list:

• Английский
• Баскский
• Финский
• Французский
• Galician (missing translation in this case)
• Немецкий
• Греческий
• ...

I don't think anyone would know his language in other languages. Switching back requires using the INI. Instead of the current setting, it should use name of that langauge in its original own language.

This makes it the following list (the same across all languages):

• English
• Euskara (N/A; english)
• Suomi
• Français
• Galego
• Deutsch
• Greek (N/A; english)
• ...

[basisbit]

I planned on restoring the behaviour from usdx 1.1 on that, but didn't have enough free time yet. Best solution would most likely be having simply only the local language names as your third list mentions them.

[RattleSN4K3]

From the versions I checked, none of them had it. USDX 1.0.1a, 1.1 (and the current dev version). Yep, the third list with a fallback to english (as normal). And pre-select the language on first start detected from the system:
http://wiki.freepascal.org/Everything_else_about_translations#Cross-platform_method_to_determine_system_language

This does require to have a property in the ini language files (or filename itself) for a proper mapping to match to Language code or LCID to the filename/translation.

[gunchleoc]

Actually, UltraStar may be available in the future for languages that don't have an operating system translated into them. IMO the easiest way to implement this is to have an "English" entry in the translation file that translators will replace with the name of their own language. Also LCID is a Windows thing and I expect that it would some extra coding fu for Linux and Mac.

Alternatively, have a separate ini file for language settings like native name, sortable name (so non-Latin names won't end up bunched up on the bottom), if it is an rtl language, if they need a special font set... then put that on Transifex as well, so translators won't need to bother with git.

[RattleSN4K3]

Ideally, a language selection should first run if the system language cannot be found and no language file is pre-configured. Otherwise, the system language should be used instead, fallback to english. And the installer could write it to ini.

IMO the easiest way to implement this is to have an "English" entry in the translation file that translators will replace with the name of their own language.

That's how it is setup currently. Every language name is translated into the specific language. English will be displayed as "Английский" if you've selected russian.

It's a big mess and does require every language name to be translated. Having every language display in its original name makes anyone being able to read their language to select it, irrelevant to what language is current set.

have a separate ini file for language settings like native name, sortable name (so non-Latin names won't end up bunched up on the bottom), if it is an rtl language, if they need a special font set...

Definitely. It has to be designed.

[basisbit]

have a separate ini file for language settings like native name, sortable name (so non-Latin names won't end up bunched up on the bottom), if it is an rtl language, if they need a special font set...

Definitely. It has to be designed.

nope, definitely not an additional .ini file. The language setting in the config.ini will be used. If it equals to the language name that is set in one of the translation files, then that language will be loaded. Otherwise, get system language, check if that is one of the supported languages. If yes, load that and set it as new language in the config.ini. If system language is not supported, load english as fallback.
In the future once these changes are done, the translation files will each only contain the name of the language of that translation file in the local language. At startup, usdx will generate a list of supported languages from these.
The special font-set will be an additional flag in that translation-file.

[gunchleoc]

That's how it is setup currently.

No, that's not what I meant. We currently have

OPTION_VALUE_CATALAN=Catalan
OPTION_VALUE_CHINESE=Chinese

etc - I mean replacing all those with just 1 entry

OPTION_VALUE_LANGUAGE_NAME=English

where "English" would be replaced by language's native names in each translation, so it would be translated to "Català", "简体中文" etc.

The plan that basisbit outlined looks good to me though :)

[RattleSN4K3]

@basisbit
I didn't mean an additional, just the seperate language file which does exist for each file, similar to how you proposed in your previous reply. The language file itself should also be able to control how the specific translations are used or displayed and can contain various fields which USDX can use to determine the "best" language for an initial startup, display the language in the native form, additional to country flags specified or stored alongside the ini file (ini format isn't well suited to store binary content, even if base64-ed) ... or could contain whatever might be relevant for a langauge selection/detection or displaying purposes.

Like:
Yiddish.ini

[General]
Name=Yiddish
LanguageCode=yi
RightToLeft=true
;...

[Native]
Names=יידיש
Names=ייִדיש
Names=אידיש
;...

[Text]
;...

That's what I meant, _it_ has to be designed:
What values should exist, where should it be stored, where can additional content be stored, does INI still suit multi-language purposes, ...

@gunchleoc
Yep. Got confused.

This is actually what this issue is all about. Altough the translations of each language in the specific different language can be helpful. A "language selection" screen can show both values or whatever suits best.

"French - Français"

[gunchleoc]

I think just having "Français" displayed in the UI rather than "French - Français" will be enough - anybody who selects the option should understand the word "Français", otherwise they wouldn't be selecting it. If we want both, we should put the native language name first - "Français (French)" for 2 reasons:

1. The name for my language "Gàidhlig (Scottish Gaelic)" is quite long, so I don't want to run into truncation issues with the native name.
2. This menu is there to serve the speakers or the languages first, not to server the English-speakers first.

I agree with all your other points. Some code examples from other projects - no need to reinvent the wheel here:

• Widelands - JSON files for translators are available on Transifex, then parsed into Lua
• Battle for Wesnoth - config file
• Neverball - config file

[basisbit]

I agree, KISS principle would be best here. Just have the local language name. No need for any english/... specific translation, only need one name per language.

[RattleSN4K3]

Was talking about a possible language selection screen. The language selection slider isn't suited for that purpose to display more than the specific language (in any form) and maybe even a country flag (where the language originates from or is most spoken).

Such language selection can be similar to the song selection with the "song" being the country flag, and the names will be display where title and artist generally is. Such selection screen could also allow searching for or jumping to specific language by entering a combination of characters. A single line slider isn't really suited for a huge list of languages. Such language selection screen similar to the song selection could work well where you also wouldn't accidentally skip over your language as at least 1 next/previous language is also shown, resulting into being shown for at least 3 steps.

It's still KISS.

[gunchleoc]

Actually, a scrollable dropdown combobox would be best for long lists of things - if you have one in your toolkit.

[HermannDppes]

As the “Own name (English name)” is current behaviour, I guess this can be closed.