i18n Support: PR 1

[StandingPadAnimations]

Let no Minecraft animator be confused by MCprep's UI simply because of the language they speak.
- Goal defined in #439

This is the first of a series of PRs to add support for translating the MCprep UI. The current roadmap is the following:

• PR 1 - Basic infastructure and MCprep N panel
• PR 2 - First half of all MCprep operators
• PR 3 - Second half of all MCprep operators
• PR 4 (To be decided) - Dynamic menus such as rigs and assets

PR 1 will be merged for MCprep 3.5.1. While not explicitly defined as a blocker for the 3.5.1 release, it will be treated as such unless decided otherwise.

As of making PR 1, a good chunk of the MCprep N panel is translatable, with a Simplified Chinese translation on the way (#445). Since I have to juggle between this and https://github.com/Moo-Ack-Productions/bpy-build, a second developer would be appreciated.

Internally, every string is represented by an ID. At runtime, MCprep calls MCprepEnv.translate_str(ID), which takes an enum value defined in MCprep_addon/translate_enum.py and maps it to the string defined in JSON. If no such string exists, English is used as a fallback.

[StandingPadAnimations]

As per #481, I'll be moving this to MCprep 3.6. Also gives us more time to refine the initial architecture

[TheDuckCow]

Was otherwise about to approve, but could we rename env.translate_str() calls to be env.tr()? Something I love from godot is how succinct this translate string function is, since it'll be basically everywhere. That's the only reason for my request for changes here.

With my demo over here, I can see it working well and I see no reason to push the first languages through, even if incomplete. I made a comment below about some missing keys, but we could also do this in a future branch.

[TheDuckCow]

See comment here for additional keys we'd want to have, not quite exhaustive but gets a number of them

#445 (comment)

[StandingPadAnimations]

env.tr() is a bit too short, I think env.tr_str() or env.tr_s() would be fine. However, at the moment, I'm not working on this PR, so someone else would need to do that final push to the end.

[StandingPadAnimations]

Also, this PR focuses on the N panel and basic infrastructure, so I'm not too concerned about operators rigth now

[TheDuckCow]

I'm fine to take over for you, thanks for getting it this far! And sure - I can settle on tr_s.

Understood it focussed on the N panel, I was seeing the operator names poke through. I might expand on it a bit more.

[StandingPadAnimations]

I do have one concern with the current JSON format, that being split lines.

At the moment, we have separate keys for split lines, based on how many lines it requires in English to fit a long sentence into the MCprep UI, such as the following:

MCprep/MCprep_addon/MCprep_resources/Languages/en_US.json

Lines 26 to 27 in 606084f

	"world_add_world_1" : "No time controller,",
	"world_add_world_2" : "add dynamic MC world.",

However, other languages may require more or less, so I think we should change it to something like this:

	"world_add_world" : [
		"No time controller,",
		"add dynamic MC world."
	]

And use a for loop in the UI for IDs like these. It's more work, but should help with preventing the UI from looking bad with languages other than or similar to English.

[StandingPadAnimations]

I'm fine to take over for you, thanks for getting it this far!

Thanks, I'll move this back into the goals for MCprep 3.5.1 then

[StandingPadAnimations]

Ok, I just discovered that the Python standard library has a module for i18n that allows the use of standard POT files (10 times easier to work with in this case)

• https://docs.python.org/3/library/gettext.html
• https://lokalise.com/blog/beginners-guide-to-python-i18n/

In other words, the past 13 commits are no longer needed, and we should probably redo the entire PR to use standard convention

sigh

[StandingPadAnimations]

Moving this to MCprep 3.6. This will give some extra time to work on this

[StandingPadAnimations]

^ How I feel now

The way I see it, we have 2 options:

1. Discard this branch and PR, and make a new branch using gettext from Python's standard library
   • Would be time consuming (especially as I enter spring semester 🥲), but looking at this comment, we can try to salvage what we have, so it's not all for nothing
   • In the end, this route would make it easier for translators, and we could use something like Weblate too (though that's a problem for future us to work out)
2. Continue with what we have and move on

[StandingPadAnimations]

I'll opt with option one, closing this PR and starting a new one