i18n Support: PR 1 - Third and Final Attempt

[StandingPadAnimations]

(This PR is to resolve some issues related to the second PR)

This is a third attempt at the first PR for i18n support, using Python's gettext module instead of a custom JSON protocol. This ended up being easier since the GNU developers have tons of utilities for automatic generation (such as xgettext)

As of making PR 1, a good chunk of the MCprep N panel is translatable, taking advantage of GNU Gettext (which is the standard for translation). Translators may use utilities like Poedit to aid in translation. In the future, we may also look towards Weblate, though that's not a priority right now.

For developers, what changes is that strings should now use text=env._(str) instead of text=str, in order to make it translatable. In addition, for every release, we need to refresh the base POT file. This is simple though:

xgettext -d base -o MCprep_addon/MCprep_resources/Languages/mcprep.pot "MCPREP_FILE" --keyword="env._

(Now here's the copy paste from #458)

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.6. While not explicitly defined as a blocker for the 3.6 release, it will be treated as such unless decided otherwise.

[TheDuckCow]

Just marking myself as a reviewer so I get back to it, unless you think there will be further structural changes. I'll review this and the bpy-build together (I've held off on that as I had some issue sin the past getting things working again, but will be good to get that merged in too ahead of our developer meeting)

[StandingPadAnimations]

@TheDuckCow finished the port from our old system to the new system:

This changes on the fly and falls back to English if the user is using a language we don't support

[TheDuckCow]

Ok thank you for the clarity and making the readme! I understand it quite a bit better, and alleviates my concerns for the most part. Give me a bit of time as I want to play around with it myself to see how a few steps would occur.

One thing I recommend is that we also put into our release preparation script or even the compile script, the command which re-compiles the po files to mo. That way there's no chance they are out of date, and while contributors should build and validate their translations live, in case they didn't check it in we'd know pretty quick.

[StandingPadAnimations]

Would be interesting, but for now I think we can just manually compile it ourselves when merging a PR related to translation.

As an aside, this PR is almost done as far as I'm aware, I just need to add some notes for maintainers and verify that we've gotten the entire N panel (obviously we haven't gotten everything, but the N panel is a good start for MCprep 3.6)

[StandingPadAnimations]

I'd say this is complete now. @TheDuckCow, can you double-check and see if there's anything that's missing?

There's currently the following limitations I hope to address in future PRs:

• Operator names are not translated. This should be addressed in PRs 2 and 3 (roadmap for these is to be decided at a later date, but I think 3.7 for PR2 and 3.8 for PR 3 would make for some good pacing)
• Headers are not updated immediately and require a restart. From what I can tell, bl_label is set at registration, and isn't dynamically updated. From what I've heard, bpy.app.translations could aid in this, but it's also extremely verbose for translators, and would result in a large Python file that would be hard to maintain in the end (hence why I didn't go this route). However, for just operators and panel headers, we could manually (or better yet, automatically it at build time) construct a small dictionary ourselves for just panel and operator labels. EDIT: This has been resolved
• Dynamic menus are not translated. I did say we might do a 4th PR for these, but dynamic menus add enough complication that I think we should just skip these in the end.

[StandingPadAnimations]

Added conversion script to go from PO files to a Python dictionary that is loaded into bpy.app.translations (with a fallback to directly sourcing the PO and MO files themselves). This does add one small dependency at build time (polib, since gettext only uses MO files, not the source PO files), but overall it works surprisingly well. I'm curious if we should however keep it as a default script, or move it to its own action.

Sadly, even with bpy.app.translations, headers don't seem to update automatically. Will have to debug further.

[StandingPadAnimations]

Determined the issue regarding headers; turns out MCprep was silently falling back to "direct i18n" (i.e. using gettext over bpy.app.translations), but I didn't have a dev build enabled so there were no logs.

Once that issue is fixed, everything changes in real time. We should be good to go to merge this.

[StandingPadAnimations]

@TheDuckCow do you think we're good to merge by the end of this week?

[StandingPadAnimations]

Just realized we can also use polib to build MO files at build time, so I've added that to the default case. For organization reasons, I've removed the MO files from the repo.

[StandingPadAnimations]

Looking further, polib is actually a single Python file, so we could just add the file directly in action-scripts and call it a day.

[StandingPadAnimations]

As an aside, I'm thinking about adding some basic i18n features to https://github.com/Moo-Ack-Productions/bpy-build to assist developers (nothing major, perhaps just the script for auto-generating a file to make using bpy.app.translations easier) as Blender's existing tooling for i18n outside translating Blender is quite lacking, but that's beyond the scope of this PR

[TheDuckCow]

I definitely support the idea of some utility or auto-compile options with bpy-addon-build, this PR is already quite large so maybe worth doing in a follow up PR.

[TheDuckCow]

Regarding being PR-ready @StandingPadAnimations, is everything in order..? I just tried the branch out as-is (not commits or re-running any commands), and found that that some of the simplified chinese lines which are defined in Po don't seem to be translated in the application itself. Do we still need to do the dictionary registration step / load via po per bpy docs? I'd say that would be critical for this PR, otherwise the translations system isn't quite useable

Would be good to show some screenshots of what you are seeing from your end

[StandingPadAnimations]

You need to add translate to the list of actions when building (since we rebuild all MO files and generate the translation dictionary, which adds to build times). bab -b dev translate will make a dev build with i18n support. I just forgot to change the developer docs to account for this

[TheDuckCow]

Yup, that has it working for me! Thanks for clarifying that, and updating the docs. Should probably update the push_latest.sh script as well, but I could do that in a follow up PR after this one. Will code review now, let's lock this in and do incremental improvements :+1:

[TheDuckCow]

(You can re-request my review one you have replies, so I don't miss them)

[StandingPadAnimations]

Done

[StandingPadAnimations]

Alright, updated with milestone-3-6-0 and updated the POT file, I'll merge this in now