[MainUI] [change request] Create Equipment from Thing suggests localised Item name

[hmerk]

The problem

As the title says, create Equipment from thing suggests localised Item Names, like below

AppleWatch4privat_Apple_Watch_Series_4_Ladezustand : Ladezustand instead of batteryStatus

While creating more widgets to be added to the semanticHomeMenu series, I would like users to use the create Equipment from Thing function to achieve a near to zero config effort. Having localised Item names makes this impossible.

Your suggestion

Change the create Equipment fromm Thing and Point from Thing functionality to not suggest localised Item names.

@florian-h05 @ghys WDYT ?

[ghys]

I remember you pitching me this I believe in Koblenz some years ago :) I think most of the time the display names would be more acceptable as a basis to suffix the name items than using for instance channel UIDs which can be quite obscure. The problem is that now that they're more and more localized and therefore you can't rely on them having a stable suffix. Maybe that could be made an option, use the display names (by default) or the UIDs if you prefer.

[hmerk]

Yes, don't remember where and when, but now I finally created an issue for it. I can understand your concerns and am absolutely fine with having this as an option. I am actually designing some nice new stuff and would like to use the naming from our home builder wizard and the create equipment from thing option. This will allow users to create nice UIs with absolutely low effort.

[hmerk]

@ghys reading your comment again, I don't really understand how the displayName would help solve my issue. As i understood, the displayName is the localised name, but I need something not localised, so it would work for anyone.

[ghys]

If the option was available to choose between channel ID (stable) and displayName channel label (potentially translated) to build item names you'd simply tell users to use the ID. I don't remember the specific case that led me to believe it was better to use the label to build the item name in general. But here's another example: https://github.com/openhab/openhab-addons/blob/a6bb5373ea21fabbc55b5319c5c1e45547ead3d5/bundles/org.openhab.binding.nibeheatpump/src/main/resources/OH-INF/thing/f1x45-types.xml#L7-L13

	<channel-type id="f1x45-40004">
		<item-type>Number</item-type>
		<label>BT1 Outdoor Temp</label>
		<description>Outdoor temperature</description>
		<state pattern="%.1f °C" readOnly="true">
		</state>
	</channel-type>

In this case it's better IMHO to use the label (item name suggestion: HeatPump_BT1OutdoorTemp) than the ID (item name suggestion: HeatPump_f1x45_40004), which is technical and doesn't give much indication. But your case is to have stable names so it might make sense also - hence the suggestion to have the option.

[hmerk]

Ok, now understood, but don't like the idea with channelId. What I really was asking was the not localised channel label. This would be stable and more understandable than the id. The siggested item label could still be built based on the localised channel label.

[ghys]

the not localised channel label

Agreed, but that would have to be exposed by the API.

[florian-h05]

@mherwege @andrewfg Your feedback on this issue would be highly appreciated.

[andrewfg]

Change the .. functionality to NOT suggest localised Item names.

Perhaps I misunderstand but I see the word NOT in the issue description. Does this mean the OP want to see English instead of mother tongue? I don't understand the use case..

[hmerk]

@andrewfg That‘s exactly what I want. The usecase is quite simple. We use partly fixed item names in the semanticHomeMenu widgets and ask users to use „create equipment from thing“ to create the expected items. Today, those items are created with mother language names, so users have to change each item name to english.

[andrewfg]

So I suppose one should use the English for the lookup, and finally convert to mother tongue when finished. Or??

[hmerk]

So users should change the language each time they add a new equipment ? Not a very good user experience, don‘t like it.