Split messages properties

[SurfaceS]

I think it will be a good things to split the messages.properties, as it is mixed of goal for now.

1 : it serve the GUI's (java and react) :
This is it's main purpose.

2 : it is use to construct the store objects :
example : dynamicPls = new DynamicPlaylist(renderer, Messages.getString("DynamicPlaylist")
This should be localized like the LocalizedStoreContainer is (on the fly).

3 : it is use to construct some default server settings (nothing about GUI's) to adapt server to country/language :
example : Messages.getString("AudioLanguages")
This should not share the same properties file or settings field.
A user may want to have the GUI in English and the server set to serve in it's language.

BAD USAGES :

4 : it serve some logged sentences and exceptions :
example : LOGGER.error(Messages.getString("ErrorOccurredTryingLaunchBrowser"));
example : wrapException(Messages.getString("UnableToRunUpdate"), e);
I think the log should be English only. Exceptions as well.
It is already hard to find things in the log without to have to know the translated sentence.
If we want to advertise the user for something in his language, another way should be find.

5 : it is use to save server settings :
example : return getString(KEY_FFMPEG_GPU_DECODING_ACCELERATION_METHOD, Messages.getString("None_lowercase"));
This will save the "none" for English, and another string for others (eg : "无" for Chinese).
This is not compliant. Changing language will kill the settings.
It should save "none" for all and other languages should translate on GUI's part.

6 : it is use to send NextcpApi response :
example : response.setResponse(Messages.getString("SongAddedToPlaylist"));
Here, a computer is talking to another computer (that may be in another language). It should not be translated on this side.

[SubJunk]

These are all good points and should be fixed.
If they can be fixed without splitting the file that would be good, because that could break the way we integrate with Crowdin