Translating Thing’s Property Names

Development
1

Hello,

I think ideally all information, users see in openHAB, should be translated in the preferred for the user language. This applies also to thing property names, thing property values and items’ labels. That is, looking on a property of a thing, instead of serialNumber, users should see “Serial Number”, “Сериен №”, "Seriennummer”.

A discussion at https://github.com/openhab/openhab-docs/pull/2605 demonstrated, that there are different views on this: having everywhere property names in camelCase, allows to create system wide list of firmware versions of all devices.

My suggestion is to translate (internationalize/i18n) thing properties, as well. For example Thing.PROPERTY_SERIAL_NUMBER = "serialNumber" is translated in English to “Serial Number”. Or other means are used, which eventually show to the user translated property names.

On the same note I think for items, which have no explicit label and are bound to one channel, the label of the item should be inherited by the channel, instead of being the item’s name. This allows less typing when defining an item, if the add-on vendor provides good enough labels for the channel.

But it also allows the add-on vendor to offer translations for the labels, based on user preferences (language set in Regional Settings, or in the browser for Accept-Language header). This eventually will allow for the same openHAB setup to show different labels for items on different devices, depending on the preferred language per device.

Greetings // Dilyan

2

I’m not sure that I fully understand. Properties are key/value pairs, some of which can be generated/depend on the exact device the Thing is bound to. So, they can never all be translated.

But, it would be possible to translate known/predictable keys (and perhaps values), but would it be worth it?

Generally on translations in OH I’d say that this is an area that is… quite lacking. I think if effort should be spent on this area, there are loads of other things that should come before this.

When I say that they are lacking, I’m thinking of things like:

  • Lots of hardcoded strings in MainUI that don’t even use translations
  • Quite a few methods I’ve seen in Core that accepts a Locale, but don’t use it (so essentially, ignoring the language requested)
  • The horrible mixture of using the configured language and the preferred browser language in MainUI, which leads to things being translated into two different languages.
  • The structure of the translation “codes” itself, the fact that there are so many redundant codes
  • The whole thing with Thing, Item etc. not being translated, which makes it effectively impossible to translate some phrases

I’ll add that I was originally quite “interested” in improving the state of translation, because I think it is quite value to broaden the use of a system like OH to family members that don’t know English, instead of it effectively being restricted to “the technical guy” that do know English.

I signed up as translator for a lot of things on Crowdin, but the only thing I still maintain is translations for the Android app. Core and add-ons are just too difficult, there is a huge amount of work with many strings that are hard or impossible to translate properly, little or no context, and no way to know if your translation will ever be evaluated or approved.

I’m simply saying that I wouldn’t start with property names, I would focus on the broader issues that prevent translations from “working” in the first place. What is the point of enabling translation for something that nobody will ever translate anyway?

3

It is true that translating strings into a language over Crowdin sometimes does not mean that the tranlation will be reviewed/approved/considered/integrated in four years, while sometimes the process works pretty straightforward. For add-ons, translations are considered only if 100% of the strings are translated, and sometimes it is not clear how a string should be translated, so it is best to leave it untranslated and do the other strings, for which translation is clear. It is also correct that sometimes translation is done based on Regional Settings and sometimes based on Accept-Language header per browser preference. These concerns are not my point here.

About properties: properties are aspects of a device, which do not change or rarely change, and cannot receive commands. To see aspects of a device, which rarely or never change, the user could create an item and link it to a channel, or the user could see a property. Using properties instead of items, can under circumstances, save the time to create an item and link it to a channel. That said, an item named ”Serial Number” can show the same information as a thing property with the same name. There is just no need to create an item to see the serial number.

In fact I think that things should, for some of their aspects, check if an item is linked to a channel and if it is not, put the information in a property. The order in which properties are inserted by the thing should also be preserved, so that more important properties are shown closer to the top.

Items have a name, label and value. The value can be translated by the add-on, or to some extend by the user when writing transformations. The label is set by the user, but as I wrote above, if the user sets no label, it should be inherited by the add-on, and thus the add-on can translate it.

So I think properties should also have a name, label and a value and it should be possible to translate the label. E.g. for a name “serialNumber” the label would be “Serial Number”.

Currently when creating an add-on, it is possible to create translatable property names and property values, as long as the constants from interface Thing are not used. So for properties, related to these string constants, the add-on either uses the constants or provides translated properties. It is up to the add-on vendor to chose the one or the other way. By translating property names to labels within openhab-core this choice will not be necessary.

What is the point of enabling translation for something that nobody will ever translate anyway?

The add-on vendors can publish an add-on, which already includes translation for properties. These might be for properties, available for that particular device only, and for standard properties like Serial number or Firmware version.

4

I know that - the reason I mentioned it, is that I tried to say that there are a lot of issues with localization in OH, and for me, property names are so far down the list that I wouldn’t consider dealing with it until many of the other things, further up the list, are dealt with.

I disagree. Properties are information, either retrieved from the device, or provided by the binding in some other way, that isn’t a configuration option or mapped to a channel. The information can be dynamic, and it can change often. It’s not usually, but there’s nothing that prevents this. I like properties because they are simple, which makes them flexible. It’s just a Map that is displayed to the user.

I agree that some properties, like typically “serial number”, “firmware version” or “MAC address”, could be translated, but you could never translate “everything” that could be put into properties.

Having some translated and some not might not be an improvement, I don’t know.

It doesn’t work like that, it’s a dynamic map. They can be removed or added at any time. That said, I agree that the properties map in ThingImpl should be a LinkedHashMap instead of a HashMap, because a LinkedHashMap is ordered, while a HashMap is not. It wouldn’t mean that the properties were somehow “by priority” (I don’t know how you would do that), but it would mean that they were “stable”. It could also be a TreeMap that was sorted by key.

That would mean fundamentally changing the data structure of what properties are. They are just a Map, there is no place to store such additional information as it is now.

5

About properties: properties are aspects of a device, which do not change or rarely change, and cannot receive commands.

I disagree. Properties are information, either retrieved from the device, or provided by the binding in some other way, that isn’t a configuration option or mapped to a channel.

Based on what criteria should be decided, if a piece of information should be presented as a property or as a channel? As I wrote above, aspects of a device could be added as a property, only if on the openHAB instance a channel is not linked.

For what are properties supposed to be used, apart for presenting to the user information under Settings → Things → … Thing Properties? If they are meant only for presenting data, the property values Thing.PROPERTY_FIRMWARE_VERSION, PROPERTY_HARDWARE_VERSION, PROPERTY_MAC_ADDRESS, PROPERTY_MODEL_ID, PROPERTY_SERIAL_NUMBER, and PROPERTY_VENDOR can be translated by openhab-core and the handlig of the remaining properties (camelCase or translated) can be up to the binding.

So I think properties should also have a name, label and a value and it should be possible to translate the label.

That would mean fundamentally changing the data structure of what properties are.

This is not necessary. For a property with name aBc, openhab-core could check if under OH-INF/i18n/ there is a .property file with key property.aBc= and if it exists, use the translation from the property file to show in MainUI.

6

From a binding developer standpoint I made the rule of thumb (for myself) that informations that can have a value for the admin user of openHAB and that never change (or very infrequently like e.g. a firmware version) are properties.

2 Likes
7

I guess that isn’t clearly defined and as a consequence, some variation will exist between different developers. Personally, I look at the information itself: Is this information that is needed when you “use” the device, or information that is needed only when you configure the device, or that isn’t really needed at all? Only information relevant when using the device is a channel, what doesn’t make sense as a channel, becomes a property.

1 Like