Best strategy for multi-lingual MainUI in OH3

Hello,
I’m wondering whether you have any recommendations for creating multi-lingual version of the MainUI user interface.
I’m aware, I can change the openhab installation Locale and that will take of certain translations of automatically generated labels etc.

Question: can I set that locale differently per user? How?

I’m also aware on how to use transformations/mapping on how to translate item states into various languages.

Question here is essentially the same: how to choose a different map per user?

My main concern is on having multi-language labels, actually.

Is there the possibility to have several versions of the Item’s Label, maybe through metadata? But I would obviously like the standard cards (like oh-location-card etc.) to be able to use the appropriate language label, depending on the user’s setting.

So in general, I think it would be great to have a standard language/locale defined per user. The other option would be to store a language choice in an Item, but then I struggle, on where to store the various language labels and make the cards choose the correct one.

The use case is a rented-out holiday home, where the guests should be able to see their user interface in the resepctive language.

1 Like

I am afraid this is not going work.
First of all, not all bindings do support translations, so different locale would still show English strings. Furthermore, this would need to have the UI been translated completely, which ist still work in progress.

But you can help with translations in crowdin.

Thanks HM,

First, I’m happy to help out on the UI translation if that is at all still useful for English, German, French, Spanish, Dutch, … I’ll take a look to crowdin.

But if I’m not mistaken, this relates to the general UI strings (my first question), e.g. the fact that the words “Equipment” and “Property” are correctly translated … and so many more.

What I’m more struggling with, is how to achieve the translation of installation specific Labels.

The docs https://www.openhab.org/docs/configuration/transformations.html say:

Usage of Transformations in the label parameter of Sitemap elements works the same way.

… same way as in ‘item states’. But that seems to be an OH2.5 statement. Anyway the link doesn’t lead anywhere.

Usage of Transformations in the label parameter of Sitemap elements works the same way.

Sitemap elements are used in BasicUI only, not in MainUI.

For what you want, each and any widget, even custom ones, would need localization support, which is not existing AFAIK.

So is it possible to create any dynamic labels? … change the label depending on the sate of some other (Language) item?

You could try to use an expression for the label, but depending on the number of languages you want to support, those expressions will become not maintainable.
In my opinion, you‘d better create one page for every language you would like to support and make it visible to just that language user.

The different language page approach doesn’t help with widgets, or am I missing something?
Is there a way to do something similar to ‘.setLabel()’ in javascript rules?

Every widget has some individual Configs for labels etc. So you can set the label different in fpr every page.

No.

Every widget has some individual Configs for labels etc. So you can set the label different in fpr every page.

Well, I’m particularly interested in the oh-location-tab (and related property, equipment) widgets. The only way I can see there, is to set the the item label to a new text, depending on a language “item”. I appreciate that this won’t show different language versions to different users at different times, but it’s already better than nothing to be able to switch over to another language for all users…

As I have decided, to try to move to the JS based rules, for new additions, I was wondering, whether this was possible, somehow.

y widget has some individual Configs for labels etc. So you can set the label different in fpr every page.

No.

This seems to suggest, that it isn’t. But is there really no way to programmatically access and set an item label through JS?

I could of course just use DSL rule for that one purpose. The flipside of that is that I would have to hard code the translated item labels in the rule itself. The most appropriate location for that would be the item’s metadata, though (e.g. the synonyms or a custom namespace). However, I’m stuck with not being able to access the item metadata from DSL rules.

Do you have any further suggestions, at all? Multi-language households or rental property setups are a challenge for Google Assistant, Alexa and similar voice-based automations already, I just thought, on a UI, it shouldn’t be that hard to do :wink:

It might be possible to extend the UI to change the used local for every user, based on an additional laguage config option.
But …
As said before, not all bindings support translations, which in fact would not really help. If I understood you correct, you would need item labels in different language. This is not possible, as you define the labels on your own. Even your suggested map usage would be very difficult to maintain. You would need to have a map for every single item with the translations.

What you could try, with some effort, is to create rules for each language.
Within the rule you could try to set the item labels via REST API calls.
Before a new user arrives, just trigger the according language rule.

As said before, not all bindings support translations, which in fact would not really help. If I understood you correct, you would need item labels in different language. This is not possible, as you define the labels on your own.

Thanks for that, I’m not looking for a binding based translation, just for a way to store item label versions (defined indeed by omy own) in various languages (at item level). followed by a possibility to modify the label displayed by the widget for every item to one of these versions.

Even your suggested map usage would be very difficult to maintain. You would need to have a map for every single item with the translations.

Well, I was thinking of storing the translation “maps” in the item’s metadata. Basically, have the item store its label, not in one, but in various languages. Since item labels (Kitchen, Living Room, Light Sofa, Temperature Bedroom, …) in contrast to item states are unique most of the time anyways… so yes, there is maintenance with this, but I think the maintenance is best done at item level, rather than rule level.

What you could try, with some effort, is to create rules for each language.
Within the rule you could try to set the item labels via REST API calls.
Before a new user arrives, just trigger the according language rule.

Thanks for that. I am not very comfortable with the REST API from within rules. I have played around with the API explorer and PUT a payload of

{ 
  "label": "Translation"
}

to an existing item test through

http://openhabian:8080/rest/items/test

But that doesn’t work to modify the item label. Can you give me a hint on how I would, in a JS rule, formulate the sendHTTPPutRequest payload string?

Unfortunately not, as I don’t use JS rules actually.

You need to provide some more information. I tried with a String item called NewTet Item and original label “New Test Item”. Then used the REST API to change the name to “Renamed Label”

{
  "type": "String",
  "name": "NewTestItem",
  "label": "Renamed Label"
}

getting this response :

Code 200 - Response Body
{
  "link": "http://192.168.0.112:8080/rest/items/NewTestItem",
  "state": "NULL",
  "type": "String",
  "name": "NewTestItem",
  "label": "Renamed Label",
  "tags": [],
  "groupNames": []
}

So this actually works.

Hey thanks for helping !

I have tried that as well, but the problem is that the PUT request essentially completely resets the item with all its properties. So those I don’t mention (like Tags, group associations, …) all get overwritten with an empty array (fortunately not the metadata).

So I would have to GET the whole payload first, fumble around with the JSON object and then PUT it back with all of its current property values, safe for “label” which woudl get the translated version, retrieved from the metadata. … quite a journey for something that setLabel('translation')
would actually be able to achieve in DSL…

Please read this for jython

or this for JSR223

That’s what says in the JSR223 post…

setLabel Sets the label for the Item // not tested
toString Prints out all the important parameters of the Item as a String

Some of these will not be useful or functional (e.g. I don’t think it works to setLabel from Rules).

and indeed, it doesn’t work. I’m a bit stuck …

  • not possible to access metadata in DSL, but possible to set the label,
  • possible to access metadata in JS, but impossible to the the label.

I have never touched Jython … but I’ll look into it now.

If you read a bit further, setLabel should work too…

I’m so really, sorry, I have read through the very long (and very good) post on the ngre post … I have searched for “label” and “setLabel” … there are 8 matches … maybe, I’m just plain blind or stupid, but I don’t see anywhere, items.getItem("test").setLabel("translation") is supposed to work in JS223.

:neutral_face:

Actually, this works for a GUI created rule (don’t care of the trigger…)

configuration: {}
triggers:
  - id: "1"
    configuration:
      startlevel: 20
    type: core.SystemStartlevelTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      type: application/javascript
      script: >
        var logger =
        Java.type('org.slf4j.LoggerFactory').getLogger('org.openhab.rule.' +
        ctx.ruleUID);
        var label = ir.getItem("NewTestItem").getLabel();
        logger.info(label);
        ir.getItem("NewTestItem").setLabel("Neues Label 2");
        var label2 = ir.getItem("NewTestItem").getLabel();
        logger.info(label2);
    type: script.ScriptAction

The key is “ir (itemRegistry)” instead of “items”…

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.