Separate OdeMessages property files for translation #3141
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, all translation strings except the ones used by the blocks editor and a small set used for the No Projects Dialog are all combined in a single properties file OdeMessages. This file runs in excess of 7700 lines. In contrast, Blockly Messages is 825 lines. The sheer size of this file can intimidate and burn out volunteer translators. Moreover, the file contains a mix of strings used by the designer UI, the components palette, component properties, and component functional blocks, not all of which have the same priority for translators.
This change allows for 4 separate properties files to be used as components in weblate:
These can be prioritized for translators in the order listed to be sure more visible strings are translated sooner and give translators and idea of where their effort has the most impact.
Note that gwt will incorporate properties files matching the named java classes, and it doesn't care what strings appear in which files. Therefore, existing translations don't necessarily need to be broken out into multiple properties files when this change is merged. In-process translations need to be broken out in the translations repository and imported into weblate to make use of the new properties components, but even that doesn't need to be done all at once for the system to work.
I have broken out Spanish to show out the new structure works. All message bundles are currently in the client directory. I spoke with @ewpatton about moving the location of the component properties files. This involves changing the package for the classes generated by ComponentTranslationGenerator in the components project, the location those java classes are copied by the build system, and the location the corresponding properties files exist in the appengine project. I tried several experiments with this, and each one caused a compile error when built (some very strange).