[Feature Request]: Add internationalization architecture

[Cubik65536]

Please choose if applies:

• [ ] I'm currently working on adding this feature.

Describe the solution you'd like

Based on the current situation on our users, I think it's important for us to get started on preparing the internationalization works. So when the feature set comes stable, we can get into the work right away.

This works consists:

1. Create an English(US) internationalization
2. Change all strings that have to be internationalized according to the i18n standard and add their en_US text in the English(US) internationalization file
3. Any feature added later follows the i18n standard if it needs to show texts on GUI
4. Once all the basic features are there (and the list of internationalized strings wouldn't change too much), we start to official translation works.

Describe alternatives you've considered

No response

Anything else?

I suggest to use Crowdin, free plans should work for us, I need your opinion on that though @zly2006 (and also in this plan in general).

I can take this task and organize it if you want and approved the plan.

Please accept these terms

• [X] I have searched the existing issues and this has not been posted before

[Cubik65536]

BTW, this is the plan under the situation that I'm not fully aware of what 38db24bab5ec5e87b83ba7350fa2dfff0cc121e8 got as the progress. We might rearrange the plan according to it.

@wafarm you are the one who did it, can you check that, according to my understanding, the steps 1 and 2 described above are pretty much done?

[wafarm]

1. This has been done. See en_us.yml.
2. • Carpet settings done
   • Malilib settings almost done (all done after #28 merged)
   • Everything else (user feedback message, GitHub login screen, etc) isn't using i18n

[zly2006]

2. • ...
   • Everything else (user feedback message, GitHub login screen, etc) isn't using i18n

Yes, it would be great if we support i18n in messages, and I suppose that is what this issue should focus on.

[Cubik65536]

1. This has been done. See en_us.yml.
2. • Carpet settings done
   • Malilib settings almost done (all done after feat: better runCommand #28 merged)
   • Everything else (user feedback message, GitHub login screen, etc) isn't using i18n

PR #28 is now merged, idk if you want to contribute to complete the step 2?

[wafarm]

Will work on this. Some questions:

• Should debugging features, debugTagBlockPos for example, have i18n support?
• How to deal with message prefix, like [Reden/Undo]?

And a list of files need i18n:

• Rollback.kt
• GithubAuthScreen.kt
• Also adding missing keys for malilib settings

Is there anything missing?

[zly2006]

debug options is not required to i18n i think, also, many features is still in development, maybe we should not provide i18n for unstable features. currently, undo and redo is basically stable but i am going to add a undo history feature and that is unstable.

[Cubik65536]

Will work on this. Some questions:

• Should debugging features, debugTagBlockPos for example, have i18n support?
• How to deal with message prefix, like [Reden/Undo]?

And a list of files need i18n:

• Rollback.kt
• GithubAuthScreen.kt
• Also adding missing keys for malilib settings

Is there anything missing?

debug don’t really need i18n, perhaps translate part of the message prefix @wafarm

[Cubik65536]

debug options is not required to i18n i think, also, many features is still in development, maybe we should not provide i18n for unstable features. currently, undo and redo is basically stable but i am going to add a undo history feature and that is unstable.

The plan is to add every existing feature into i18n file and when adding a new feature, add directly a i18n text, it can be not translated when it’s not stable, but the text should be there in i18n files. Otherwise it will be a pain in the a** migrating every time a new feature is completed, trust me, I’ve done it before. @zly2006