We had the same kind of problems in many places (translations for tools, widgets, resources, ...), and the best solution we found is to store the translation key directly in the entity (not in a separate table) and to make the actual translation on the fly when it's needed. This way we can easily use a set of predefined translations coming from usual resource files (often with a specific translation domain). Obviously, if new objects are created after the platform installation, their name won't be translated that way. Instead they'll keep the name that users had chosen to give them, which is not a problem IMO, as the platform language isn't supposed to change after the initial configuration.