Best strategy for multi-lingual MainUI in OH3

[Dirk_Albrecht]

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.

[hmerk (Hans-Jörg Merk)]

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.

[Dirk_Albrecht]

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.

[hmerk (Hans-Jörg Merk)]

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.

[Dirk_Albrecht]

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

[hmerk (Hans-Jörg Merk)]

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.

[Dirk_Albrecht]

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?

[hmerk (Hans-Jörg Merk)]

@Dirk_Albrecht

The different language page approach doesn’t help with widgets, or am I missing something?

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

@Dirk_Albrecht

Is there a way to do something similar to ‘.setLabel()’ in javascript rules?

No.

[Dirk_Albrecht]

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.

@Dirk_Albrecht

Is there a way to do something similar to ‘.setLabel()’ in javascript rules?

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

[hmerk (Hans-Jörg Merk)]

@Dirk_Albrecht

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

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.

[Dirk_Albrecht]

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?

[hmerk (Hans-Jörg Merk)]

@Dirk_Albrecht

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.

[hmerk (Hans-Jörg Merk)]

@Dirk_Albrecht

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"
}

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.

[Dirk_Albrecht]

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…

[hmerk (Hans-Jörg Merk)]

Please read this for jython

String to Item and than change the label of the Item

You are getting the rror because bmitem is not an Item but a String. setLabel is a method of GenericItem. You first need to get the Item (see may second post ). This is another example of how scripted automation with Jython is easier to use than the DSL… from core.rules import rule from core.triggers import when @rule("Raumtemperatur ändert sich") @when("Member of gTTermostate changed") def example_rule(event): bmitem = event.itemName.replace("_T_","_BM_") sendLogNotification("m…

or this for JSR223

Experimental Next-Gen Rules Engine Documentation 4 of : Writing Scripts

This tutorial post is very out of date and ultimately did not make it into the official docs. Do not use this except for historic purposes. See the Getting Started Tutorial sections on rules for how to get started with rules. Rules - Introduction | openHAB Writing Scripts As you can see a lot can be accomplished in the NGRE without writing scripts at all. Much more than is possible with just Items. However at some point writing a script will be required. We know that the scripts entered into …

[Dirk_Albrecht]

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.

[hmerk (Hans-Jörg Merk)]

@Dirk_Albrecht

possible to access metadata in JS, but impossible to the the label.

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

[Dirk_Albrecht]

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.

[hmerk (Hans-Jörg Merk)]

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”…