Naming strategy for translation strings

[HenrikJannsen]

We will use a similar approach as in Bisq1 for translation strings (property files and Transifex).
It rises the question what is the best naming and organization strategy for translation strings. Currently its quite messy and will require a larger cleanup.

Things to consider:

• We want to avoid duplication of strings if used in multiple places in the UI
• But if we use the same string for different user cases it might introduce problems later when one use case of the string should be changed but the other not. It would require to duplicate the string entry and adjust the code. If there would exist an alias concept this would be a solution for that problem [1].
• We do not want tight coupling with the code so that refactoring in the code would invalidate the keys in the translation strings.
• We want to mirror though the module structure to have some meaningful namespace organization. The module names are unlikely to change.

Suggestion:

• We organize the strings with high level module names. If a string is used in a certain module the key must reflect that.
• Global strings have no namespace, but should be not over-used. E.g. if its domain specific its not global. Example for global are "Yes", "Close",... "Trade" would not be valid for global.
• Dynamically created strings which cannot be located by the IDE (marked as unused in IntelliJ) should be commented so they do not get removed accidentally and in case of code refactorings that they get updated. The display strings should be provided in the class which provides the dynamic input, e.g. a enum where we use the name as part of the key should provide a method for the string, so if the enum gets refactored or entries added its easier to spot the required change in the property file.
• If no alias concept is feasible we should prefer duplicated string over re-use. I guess Transifex provides support so that duplicated strings can be easier translated by copy/paste.

[1] Regarding alias:
I don't think there is any support for that in Java properties.
We could add a mapper in the Res class which maps multiple keys to a single key. But that might be too cumbersome to maintain as well.