[Translator] Improvements to internationalization when using the integrated API about tock HOT 3 CLOSED

I agree with the remarks:

• Label versioning should be available
• We should have a simple option to setup all the messages in the code (and keep the ability to override the labels in the interface) - may be ressource bundle ?

from tock.

I am not too sure about ResourceBundle, since - as far as I know - we have no good way of listing defined locales. We would need that feature to write the default values to the database for use in TOCK Studio.

from tock.

After further consideration, Java's ResourceBundle API is technically usable, as we have the full list of locales supported by each bot. However, it has the following limitations:

• Since TOCK would have to query the bundle for each locale, it would need to also take the bundle key as parameter (so 2 parameters, bundle key and resource key)
• Locales cannot naturally express interface types (text, voice and text, voice) or connectors (web, slack, etc.). We could however work around that by defining a new convention for an "interface" and a "connector" language subtags.
• Property resource bundles can only yield strings, not lists of strings as would be required to support the "alternatives" feature
• ResourceBundle forces the creation of a new file for each locale, which may not be practical for developers that wish to modularize their localization (e.g. grouping translations per-story)

Since TOCK will have to extract something like a Map<(Locale, UserInterfaceType, Connector), List<String>> at some point regardless, I believe we should make it possible for programs to supply such data directly. We can then provide a ResourceBundle-based helper on top for applications that benefit from its use.

from tock.