search

MultiMC / Launcher

A custom launcher for Minecraft that allows you to easily manage multiple installations of Minecraft at once
https://multimc.org/
Other
4.31k stars 885 forks source link

Allow JVM-level locale override by having an option to not appending `-Duser.language=en` at the end of JVM arguments #5010

Open 3TUSK opened 1 year ago

3TUSK commented 1 year ago

Role

I was testing localization for Fabric Loader.

Suggestion

Provide an option to make MultiMC not appending -Duser.language=en at the end of JVM arguments

Benefit

This would allow me testing translations for different languages in the way it should have been

This suggestion is unique

You may use the editor below to elaborate further.

https://github.com/MultiMC/Launcher/blob/7354c578fd5f80502cb1dbc48aa05f65d0bb1c31/launcher/minecraft/MinecraftInstance.cpp#L361

Right now, MultiMC always append a -Duser.language=en at the end of JVM arguments. The rationale behind this can traces back to as early as 2015:

user.language is a workaround for Minecraft localizing log messages making them useless for troubleshooting.

(Quoted from https://github.com/MultiMC/Launcher/issues/837#issuecomment-85596251.)

I just have encountered this niche need where I would like to have -Duser.language=zh in JVM arguments. As I said above, I was testing translations for Fabric Loader. To do this,

  1. I first prepare the translated language file. Fabric Loader has it under the path !/net/fabricmc/loader/Messages.properties, and it is loaded via ResourceBundle. According to spec and convention, I put the translated file under the path !/net/fabricmc/loader/Messages_zh_CN.properties, as I am doing a Simplified Chinese translation.
  2. Next, I construct a brand new jar whose contents are just that translated file and a dummy !/META-INF/MANIFEST.MF.
  3. Then, I uses MultiMC's built-in function to append this translation jar to classpath. Doing this allows ResourceBundle to see that translated file.

Problem is that, to make ResourceBundle.getBundle uses Messages_zh_CN.properties instead of the Messages.properties, I would have to change the default locale for the running JVM. There are two options for me:

  1. Write something that call Locale.setDefault(...) before Fabric Loader begins its work.
  2. Use these JVM arguments: -Duser.language=zh -Duser.country=CN.

Apparently option 2 is easier, and that is where the issue comes from: the behavior of having two -Duser.language is unpredictable.

For now, my workaround is to name the translated file Messages_en_CN.properties and having just -Duser.country=CN in JVM arguments. Doing so would trick JVM to favor the translation over the original. Still, having this weird combination sounds unnatural.

I fully understand the niche nature of this request, so I really won't mind if this finally gets rejected. Even if this gets rejected, other people will perhaps not need to waste time on filling a ticket for this, making this a useful record.

Addendum 1: I forget to mention, such option should be default to opt-in, i.e. the -Duser.language=en should be appended by default.

Jerozgen commented 1 year ago

I'm working on a mod that has a feature of automatic language detection on first game launch which is useful for modpack users. The -Duser.language=en argument disables the way the mod gets user's system language with Locale.getLanguage(). It would be nice to remove insertion of this argument or insert another argument containing the original language so I could use it as a workaround.