The backup strings read from the default language of en-US is not read from the en-US.txt file inside the compiled .jar file, but instead read from disk. This means that when new translate-able strings are added, the server will be missing strings until the server owner manually deletes en-US.txt from the lang folder. Instead of displaying the correct string, the identifier of the string is shown, and a useless warning is displayed in the log.

There are two ways to fix this, which are not exclusive:

1. The backup strings should always be read from the internal file (should be done even if implementing 2.)
2. If an internal file contains translatable messages missing from the equivalent file on disk, add the missing translatable messages to the file on disk (this was done in legacy, but legacy also required all files to contain all translatable messages, which was silly)

Should we close this, or do option 2 as well?

Should we close this, or do option 2 as well?

Without option 2, if a user starts using a language (nn-NO) with an incomplete translation, even if we finish the translation, the user will still have an incomplete translation file. The only way to get the full translation is to manually delete the translation file and restart. As there is no way for a user to know if their translation file is incomplete, or if it's the supplied translation that is incomplete, this makes it really inconvenient.

It's not a problem only for those who want to mess with the translation file. It's a problem for anyone using anything except the default translation (as default == backup).

Okay, good point

Okay, good point

You can look at my fork for an example of how to do it.