Proposals for changes in Locale & Language Manager

[HSGamer]

First way

1. Load the locale defined in config.yml from the cloud as a Properties. If the locale is not found, load the default locale (English)
2. Put the key-value pairs of the Properties to language.yml
3. The plugin will use language.yml to get & set messages

The users have full control of the language, and if there is a change in the messages, we can just update it in language.yml.
The drawback is that they must remove language.yml and let the plugin refresh it if they want to get the updated translated messages or change the locale.

Second way

1. Load the locale defined in config.yml from the cloud as a Properties. If the locale is not found, load the default locale (English).
2. Store the Properties in a temporary location.
3. language.yml is empty & only contains overridden strings for the Properties.
4. When getting a message, the plugin first check if there is a path in language.yml. If it's found, load it; otherwise, get the message in the Properties.

language.yml is smaller in file size as it only contains the replacement of the messages in the locale file. If there is a change in the messages, we can simply update the locale file.
The drawback is that the users have to find the correct path to set in language.yml if they want to replace a line.

[Tigerpanzer02]

Current way

1. Loads the language_default.yml
2. Loads the (user editable) language.yml
3. Loads the 'locale.yml' from web with translated locales from poeditor
4. Getting a message will compare the value in 1, 2 and 3. (default 3; 1 different to 2 loads 2)

Issues with it

• User would need to look into 3 to change 2 as user would need to know the path to message

Looking for?

• A solution that removes the time needed to compare files / paths manually

[Tigerpanzer02]

Third way

1. Loads the language_default.yml
2. Loads the (user editable) language.yml
3. Loads the 'locale.yml' from web with translated locales from poeditor
4. Create a 'language_combined.yml' which contains 2 and loads 3 over it without changing edited values 2 vs 1
5. Getting a message will use 4

Requires a automatic compare method on plugin start up to produce 4 but 4 shouldn't be updated after a user edited 4 which makes it hard to maintain as nearly impossible

Users would be able to directly change on 4 and don't need to mess with paths

[Tigerpanzer02]

Compare ways (in short)

• Third way is not efficient enough in my opinion and produces also another language file which could be for the user also not helpful as having more and more files for the same thing could iretate.
• Second way see no reason to have empty strings than current way is better
• First way would kinda need a recognition such as Third way to know changed values on language.yml

For me the current system seems to be good enough with the issue that looking up a path cost a bit of time, but over all it seems to be the easiest and understandablest way for the user itself

[HSGamer]

One other issue with the current way is the weird ERROR messages if there is an update in the language messages.

For me, I want a system that I can just override messages I want (Scoreboards, Server IP, etc), so I would choose the second way.

[Tigerpanzer02]

One other issue with the current way is the weird ERROR messages if there is an update in the language messages.

For me, I want a system that I can just override messages I want (Scoreboards, Server IP, etc), so I would choose the second way.

That's exactly what is currently possible with the current way. Idk what you mean with the weird ERROR message but that only happens if paths are missing that would occur in any case of way how it is handled. May there is another issue with the check of getting paths. I currently test it with vd as vd has the core inside development branch and it doesn't happen for me?

[HSGamer]

I guess the only problem with the current way is that if the path in language.yml is not found, it is always default to an ERROR message, which is, as you said, different from the value from language_default.yml, and it'll throw the ERROR message as a result. This could happen when you add new lines in language_default.yml.
I think a small refactor of the order that fixes the problem is enough.