Under unknown circumstances, the language files can fail to load.
Possibly due to the existence of an empty lang folder at startup?

[19:04:33] [Server thread/INFO]: [Stargate] Enabling Stargate v1.0.0.7-ALPHA
[19:04:33] [Server thread/INFO]: [Stargate] Saving language file from internal path lang\EN-CA\EN-CA.txt
[19:04:33] [Server thread/INFO]: [Stargate] Saving language file from internal path lang\EN-CA\EN.txt
[19:04:33] [Server thread/INFO]: [Stargate] Saving language file from internal path lang\EN\EN-CA.txt
[19:04:33] [Server thread/INFO]: [Stargate] Saving language file from internal path lang\EN\EN.txt
[19:04:33] [Server thread/WARN]: [Stargate] The selected language, "EN-CA", is not supported, and no custom language file exists. Falling back to English.
[19:04:33] [Server thread/INFO]: [Stargate] Checking internal language file 'lang\EN-CA\EN-CA.txt'
[19:04:33] [Server thread/INFO]: [Stargate] Checking internal language file 'lang\EN-CA\EN.txt'
[19:04:33] [Server thread/INFO]: [Stargate] Checking internal language file 'lang\EN\EN-CA.txt'
[19:04:33] [Server thread/INFO]: [Stargate] Checking internal language file 'lang\EN\EN.txt'
[19:04:33] [Server thread/INFO]: [Stargate] Could not load a internal language backup for your specified language
[19:04:33] [Server thread/INFO]: [StargateCommand] Enabling StargateCommand v0.1.0

Additionally, the above message implies that the internal backup language did not exist
Given that sg version prints correctly, it does appear that there is in fact a loaded backup localisation?

[19:06:17] [Server thread/INFO]: [Stargate] Formatted TranslatableMessage 'COMMAND_INFO' to 'Running version %version%. Changelog: https://git.io/JD4Qo'
[19:06:17] [Server thread/INFO]: [Stargate] Running version 1.0.0.7-ALPHA. Changelog: https://git.io/JD4Qo

EN-CA used as the string at configuration.
Instance saved as vault 6.

This is probably due to caps sensitivity, as all internal files follow this format en-CA

We can either say this is a user-error, or try and parse the selected language and fix capitalization.

This is technically user error, but we should really be handling language codes case agnosticly

This is technically user error, but we should really be handling language codes case agnosticly

There is one problem with this approach. The language codes correspond to files. On any file system that cares about case (ex. GNU/Linux-based distributions), The only way to truly be case agnostic is to check any variation of uppercase and lowercase. On GNU/Linux-based distributions, File.exists() will only return true if the case is correct. For a user's custom language file, they can call it something like En-ca, eN-ca or similar. This means we either need to list all files and check if their file names matches the language code (.equalsIgnoreCase()), or try every mix of uppercase and lowercase, We don't know a clean way of finding a list of all the supplied language files, which this solution would also need to cover.

There is the approach of having a set "correct" path, but that doesn't account for custom languages.

For the shortcuts (en, nn, nb, gb) we can definitely add case insensitivity, if it doesn't exist already, as this is just a map telling the real name for the file.

This is technically user error, but we should really be handling language codes case agnosticly

There is one problem with this approach. The language codes correspond to files. On any file system that cares about case (ex. GNU/Linux-based distributions), The only way to truly be case agnostic is to check any variation of uppercase and lowercase. On GNU/Linux-based distributions, File.exists() will only return true if the case is correct. For a user's custom language file, they can call it something like En-ca, eN-ca or similar. This means we either need to list all files and check if their file names matches the language code (.equalsIgnoreCase()), or try every mix of uppercase and lowercase, We don't know a clean way of finding a list of all the supplied language files, which this solution would also need to cover.

There is the approach of having a set "correct" path, but that doesn't account for custom languages.

For the shortcuts (en, nn, nb, gb) we can definitely add case insensitivity, if it doesn't exist already, as this is just a map telling the real name for the file.

We could probably just covert that anything before a - is lowercase and everything after - to uppercase

But what if a user adds a file es-ar.txt as a custom language file? If we force it, this file cannot be loaded.

Good point, in that case I have no idea on how to solve this

Maybe check once like before, then do my suggested check?

One possible to deal with this is to have an enum or something with all supplied languages. If the selected language matches one of those case-insensitively, use the case-sensitive language code to find the language file.

If it does not match a known language, treat it as a custom language, and only check the plugin/Stargate/lang folder for the file case-sensitively (insensitively on Windows of course). If the custom language file cannot be found, show a descriptive error to the user, but treat it as their responisbility to fix the issue.

Sounds like a plan

If we go with this, I think we should change how we use the code that checks for all language file path variations. We should have a set standard for how we name/organize the language files internally.
For known languages we should only consider the correct file path (country/languageCode.txt or language/languageCode.txt for example). Especially, when updating translations we should only consider the path of the internal file when writing to the file in the plugin folder. Any other valid language file found by using a variation of the path of the internal language file would be a custom translation, and should not be altered.

For custom languages we should still check different variations of the path as we cannot assume users do it correctly.

Sounds like a plan