Is there a translation (I18N) util for general use

[polychronov (Konstantin Polychronov)]

Hi all,
Is there anywhere in the framework a translation util that can be used to translate a specific channel states? I couldn’t find one…

The use case is - I have an ENUM representing states of a certain channel and I want to translate the states in the properties file.
What I noticed is that most handlers which have something like that are using the @reference to the translation provider where they retrieve the bundle using frameworkutil and do the translation like this.

I was wondering if there is anywhere a static method that can be used for this by passing the required parameters only and receive the translated value as a response?

P.S. Obviously the bundle will have to be retrieved and passed to the util, but I’m not sure if this reference stuff is really needed as it complicates the creation of the handlers and the factory.

Cheers,
Konstantin

[splatch (Łukasz Dywicki)]

Do you rely on static or dynamic enum options? If they are static and are defined through config descriptor you can re-use these definitions as well as i18n maven plugin to generate resource stubs.
I know that invocation of TranslationProvider is quite strange, but doable.

Long, long time ago I made an attempt to decouple TranslationProvider from resource bundles, but I didn’t complete it. My main goal back then was possibility to define new translation sources which could be provisioned through other ways than static files. Sadly, the way in which current translation interface is defined imposes till great extent use of bundles are resource coordinates.

[polychronov (Konstantin Polychronov)]

Thanks for the hint!

While I was trying to implement the option with reference to the provider from the OSGI framework, I noticed that I don’t know where to get the locale actually.
Any hints?
The bundles I use as a reference most use the default, English locale which is not really what you want to have when you’re doing translations.

[polychronov (Konstantin Polychronov)]

Ops… sorry. This one is documented. I see it now.
Who would have guessed… we need to use the LocaleProvider.

#Locale Provider
To programmatically fetch the locale used by the openHAB system an OSGi service LocaleProvider is offered. The service contains a getLocale() method that can be used to choose a configurable locale.

[splatch (Łukasz Dywicki)]

i18n plugin was introduced some time ago: Add i18n-maven-plugin to make internationalization easier by wborn · Pull Request #2544 · openhab/openhab-core · GitHub.

I’ve done some work with handlebars where I embedded translation provider in following way:

@Component
public class HandlebarsTranslateHelper implements TranslateHelper {
@Activate
  public HandlebarsTranslateHelper(@Reference TranslationProvider translationProvider,
    @Reference LocaleProvider localeProvider) {
    this.translationProvider = translationProvider;
    this.localeProvider = localeProvider;
  }

  @Override
  public Object apply(Object context, Options options) throws IOException {
    String scope = options.hash("scope", null);
    String key = options.hash("key", null);
    if (scope == null || key == null) {
      return null;
    }

    String fallback = options.hash("fallback", null);
    String lookupKey = scope + "." + key;
    return translationProvider.getText(null, lookupKey, fallback == null ? null : "" + fallback, localeProvider.getLocale());
  }
}

My calls were going like this: {{translate scope="item" key=name fallback=label}} from YAML templates used to generate main ui widgets and pages.

In your case you can use also BundleResolver which will mask use of FrameworkUtil and simplify testing of the code and feed first argument of getText call. The lookup key will come out of i18n plugin execution which assumes reasonable defaults for keys. You might need to tweak resources manually to avoid duplicate definitions of same text label.

[polychronov (Konstantin Polychronov)]

Thanks a lot for the help.
For now I think it’s clear.
I’ll try to do some tests and if any issues will get back here. (because last time I used the @Activate and @Reference annotations to get something from the framework I had issues with the activation of my bundle but maybe it was some metadata related issue)

[splatch (Łukasz Dywicki)]

If your component ever get stuck try using scr:list and scr:info commands. First should print all detected components and second prints out which of its references is not resolved.

[polychronov (Konstantin Polychronov)]

This time it worked from the first attempt. Everything runs smooth and nice. I have a locale, translations provider and time zone provider from the OSGI framework.
Thanks for the support!