This article focuses on how to use localization as a developer.
If you are an administrator trying to look up, how to translate or change messages, please see the localization section in the "Knowledgebase" category.


Work in progress

While localization already works, an implementation refurbishment is planned.
Please do not use implementation code of this feature in any plugin! Consult our support for help if required.
Note: The API can be used without worries though. No breaking changes will be made.

Localization is split into localization units and contexts. Just like persistence and transport units, localization units can be injected by specifying the @LocaleUnit annotation on an injected field of type ILocalizationUnit.

Localization units

Localization units group localization for generic units of functionality. Very often, a single plugin uses a single localization unit identified by the plugin id. But in general, plugins are not limited to a single localization unit.
The localization unit contains the contexts used for actual localization and provides them via. #getContext.
_We encourage developers to use the #getContext(IUser) method as this will respect the users custom language, if set, instead of just using the TS3 country flag.

The "owner" of the localization unit can additionally provide a resource URI to the injection annotation ILocalizationUnit which will be used to initialize the language file with default messages.

Localization contexts

Localization contexts are always associated to a single localization unit and locale and provide access to the message templates stored in the units configuration file.