i18n support for contributed modes

[processing-bot]

Created by: codeanticode

Currently, multiple language support is provided for the main Processing app, but this support does not extend to the contributed modes. Each mode could (optionally) provide localized properties files that translate the elements of the mode's UI into different languages.

[processing-bot]

Created by: codeanticode

A simple implementation of this support is provided with these changes:

• New addModeStrings() method in Language: the mode's base and localized properties in the current language are read into the LanguageBundle.
• Load mode strings when initializing the mode. The method addModeStrings() is called right after creating the instance of the mode.

However, an problem with this simple implementation is potential resource collisions, where a mode could overwrite existing strings from the PDE or those used by other modes. Possible ways of handling this problem are adding the name of the mode as a prefix on all the strings, or the full mode package string.

Another possibility could be that modes have their own separate language bundle to avoid collisions without needed to add extra prefixes, but fallback to the bundle if a string from the base PDE is requested.

[processing-bot]

Created by: codeanticode

@benfry I implemented a way to support multiple bundles per mode:

https://github.com/codeanticode/processing4/tree/mode-lang-support-with-mult-bundles

The functions text(), interpolate(), etc. are overloaded to accept the calling mode, while keeping the original definitions to be used from the main app, see for example here.

The idea is that the get() function when called from the mode will first try to get the string from the mode's bundle (if it exists) and then from the base bundle if the key is not present. I think this is one possible solution that solves the problem of colliding keys (priority is given to the mode's strings without overwriting existing keys) and the changes to the API are minor (calling the language methods from the moded only need to add the mode object to the call). BTW, the Language instance uses the hash of the mode object as the key in the map of modes to bundles. Let me know what you think of this approach

[processing-bot]

Created by: benfry

Ok, added one comment; maybe put this in as a PR so I can review?

[processing-bot]

Created by: codeanticode

Here: #237

[processing-bot]

Created by: benfry

Incorporated a subset of that PR based on the feedback there for 4.0 beta 5. See ddd4b10

[processing-bot]

Created by: github-actions[bot]

This issue has been automatically locked. To avoid confusion with reports that have already been resolved, closed issues are automatically locked 30 days after the last comment. Please open a new issue for related bugs.