Plugin Translations

[roflmuffin]

• Adds an instance of IStringLocalizer to the base plugin, as well as adding this to the DI Container
  • This string localizer is an opinionated implementation that reads from a subdirectory in the plugin folder called lang for any valid locale json files, such as en.json, en-AU.json, fr.json etc.
  • These json files are simple key values of translations in a C# Format string, i.e. "Hello {0}, your ID is {1}"
  • The json files are parent locale compatible, so a user with locale en-GB will try to read from an en-GB locale file first, and then en if missing. They always fall back to en if a key cannot be found.
• Adds a new "ServerLanguage" property to the core config, defaulted to en. This will change all localized strings into that language, unless there is another language context present (like a user command will return information in a users language).
• Adds a new css_lang or !lang command which will print your current language, as well as accept an argument to change your language, i.e. !lang de will change to German, !lang en-AU will change to English Australia etc.
  • This is done through a singleton IPlayerLanguageManager which simply maps a SteamID to a culture info, or defaults to server language if not found. There is no cleanup process for this list at the moment so it would slowly leak memory if every single player sets their language and you have thousands of unique users (not really a concern yet).
• Adds a new extension method on CCSPlayerController called GetLanguage which returns the users configured language or a default language if they have not set one.
• Adds a new TemporaryCulture disposable which is used to set the current thread language until disposed, this is currently used in command handlers from the plugin side.
• This also means that CounterStrikeSharp can no longer be run in invariant mode, and libicu is required.
• This also handles color coded translations, e.g. {orange}This{default} text has {green}green{default} text

[KillStr3aK]

Good stuff in general, here are my thoughts:

• Wouldn't it be possible to have other structure for the files? instead of splitting everything for each language/file it might be better to have a file that contains the phrase key as an object index, then it will have the language codes inside that, for e.g.:

  "testPlugin.maxPlayersAnnouncement": {
     "en": "...",
     "en-GB": "..."
  }

• ServerLang is missing from the unmanaged code currently. (and docs)

[KillStr3aK]

Good stuff in general, here are my thoughts:

• Wouldn't it be possible to have other structure for the files? instead of splitting everything for each language/file it might be better to have a file that contains the phrase key as an object index, then it will have the language codes inside that, for e.g.:

  "testPlugin.maxPlayersAnnouncement": {
     "en": "...",
     "en-GB": "..."
  }

• ServerLang is missing from the unmanaged code currently.

so we could have a lets say, common.json translation file and there would be others aswell, just if a plugin can be translated into many languages ppl would have to edit every language file one by one and add/update the new keys for each file which is pretty time consuming

[mificot]

Good stuff in general, here are my thoughts:

• Wouldn't it be possible to have other structure for the files? instead of splitting everything for each language/file it might be better to have a file that contains the phrase key as an object index, then it will have the language codes inside that, for e.g.:

  "testPlugin.maxPlayersAnnouncement": {
     "en": "...",
     "en-GB": "..."
  }

• ServerLang is missing from the unmanaged code currently.

so we could have a lets say, common.json translation file and there would be others aswell, just if a plugin can be translated into many languages ppl would have to edit every language file one by one and add/update the new keys for each file which is pretty time consuming

That a good point! I don't think that it's necessary to split locales into different files as it is done in web apps, for example.

[roflmuffin]

I would like to use the same localizer for core, and the idea of a giant file with all locales does not seem fun to edit for me personally. Especially if someone wants to add an entire language they can just add a new file and the diff is easier to read. We could probably allow a nested json file option but I'd want to support both

[KillStr3aK]

I would like to use the same localizer for core, and the idea of a giant file with all locales does not seem fun to edit for me personally. Especially if someone wants to add an entire language they can just add a new file and the diff is easier to read. We could probably allow a nested json file option but I'd want to support both

I'm not talking about one giant file, different files but not for language codes.
Look at SourceMod Translations for reference. (ignore the folders)

I don't mean the whole implementation, just how the files are separated and we could have a loader so the core could load its own translations, and plugins could do the same

[roflmuffin]

I'm just not sure I see the value in having multiple translation files (except for locale) per plugin; I can't see the scope of a plugin being so large that they need more than 1 language file for english for instance