Separate OdeMessages property files for translation

[SusanRatiLane]

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:

• web ui
• component names and help strings, visible in the component palette
• component properties with descriptions, visible in the component properties sidebar
• component method/events with descriptions, visible in the blocks editor

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).

[SusanRatiLane]

@AppInventorWorkerBee OK to test

[SusanRatiLane]

@AppInventorWorkerBee retest this please

[ewpatton]

@SusanRatiLane it looks like the build is failing due to not enough memory in the YaClientApp build step. You'll probably need to bump the -Xmx flag by another GB.