Config parameter: Change inferred i18n key for add-ons + alternative key

[lolodomo]

Fix openhab/openhab-webui#2641

The i18n key for add-on configuration parameter should now start with addon.config.<param>.
To maintain compatibility with hundreds of existing translations, an alternative key starting with <type>.config.<param> is still accepted for an add-on parameter

Signed-off-by: Laurent Garnier lg.hc@free.fr

[J-N-K]

Why is there a mismatch between the actual scheme name and the required scheme name?

[lolodomo]

IICR, this was introduced when you introduced the addon.xml file with new features. In OH 4.0 I believe

[J-N-K]

But why don't we fix the config description scheme naming if it should be addon instead of binding?

[lolodomo]

But why don't we fix the config description scheme naming if it should be addon instead of binding?

Yes, that looks like a good idea.

It is probably coming from the XML tag named "type" in all addon.xml. To be confirmed.
So you will suggest to replace in all addon.xml the value "binding" by "addon" ?
It should also fix the issue, I believe. It is just more work, around 500 files to change (one file for each binding) !
And in my mind, add-on is a generic word for binding, voice, transformation. Using it for bindings in the addon.xml file is not 100% logic.

[lolodomo]

The other option would be to update the i18n keys to use "binding.config.xxx" instead of *addon config.xxx". But that would be even more work and a disaster as it would require to translate again all bindings parameters.
I would really like to avoid that option.

[lolodomo]

I could also rather fix where the description uri is built, rather than where the i18n key is inferred from it.
I mean we could build addon:netatmo instead of binding:netatmo in the REST addon API. Then the config_description API should return properly translated parameters.

[lolodomo]

I am counting 85 entries in english properties files having "addon.config.xxx". It concerns 21 bindings.
If I include the other languages, I count 182 entries, meaning 97 translations.

So another solution, probably the cleaner, would be to fix manually the 85 wrong entries and then start again their translations in Crowdin.

Note that I found wrong entries also for two persistence services (entries should probably start with "persistence.config.xxx"):

org.openhab.persistence.inmemory/src/main/resources/OH-INF/i18n/inmemory.properties:addon.config.inmemory.maxEntries.label = Maximum Entries
org.openhab.persistence.inmemory/src/main/resources/OH-INF/i18n/inmemory.properties:addon.config.inmemory.maxEntries.description = The maximum number of values stored for each item (0 = infinite).
org.openhab.persistence.mongodb/src/main/resources/OH-INF/i18n/mongodb.properties:addon.config.mongodb.collection.label = Collection
org.openhab.persistence.mongodb/src/main/resources/OH-INF/i18n/mongodb.properties:addon.config.mongodb.database.label = Database Name
org.openhab.persistence.mongodb/src/main/resources/OH-INF/i18n/mongodb.properties:addon.config.mongodb.url.label = MongoDB connection URL

[J-N-K]

IMO addon.config is the correct prefix for all. Why should it be binding or persistence? Can't we rename the keys on Crowdin?

[lolodomo]

IMO addon.config is the correct prefix for all. Why should it be binding or persistence?

If we do that, we have probably less bindings to update, only io/voice/persistence/transform bindings having parameters.

Can't we rename the keys on Crowdin?

We can of course change the keys but then you have to provide a new translation.
There is an option to import the translations but it could override in the case of uncomplete translations.

[lolodomo]

IMO addon.config is the correct prefix for all. Why should it be binding or persistence?

If we do that, we have probably less bindings to update, only io/voice/persistence/transform bindings having parameters.

In fact, it is largely more entries to change:
114 for persistence
262 for voice
...

So it would be easier to fix entries for the 19 standard bindings and 2 persistence bindings.

[lolodomo]

Or we go with my proposed workaround and we don't have to update bindings. Only 2 lines changed in the core framework.

PS: the 2 persistence services should be fixed anyway.

[lolodomo]

I also found one binding using "binding.config.xxx":

org.openhab.binding.mqtt.homeassistant/src/main/resources/OH-INF/i18n/mqtt.properties:binding.config.mqtt.homeassistant-status.label = Publish Online Status
org.openhab.binding.mqtt.homeassistant/src/main/resources/OH-INF/i18n/mqtt.properties:binding.config.mqtt.homeassistant-status.description = Publish <tt>online</tt> to <tt>homeassistant/status</tt> when discovering Home Assistant things in order to trigger devices to publish up-to-date discovery information. If you also run Home Assistant <i>and</i> other services that depend on knowing if Home Assistant is not running, then it's possible for those services to be out-of-sync with the actual status of Home Assistant, and you may want to disable this.

[lolodomo]

If my proposal is accepted, I will have to take a look to failing integration tests.

[lolodomo]

I am going to enhance my proposal to support both keys, that is <type>.config.<param> and addon.config.<param>.

[lolodomo]

@J-N-K : please look at the last version, I believe it is a good compromise supporting both i18n keys. No changes in add-ons should then be required.

[lolodomo]

Close)re-open to trigger a rebuild

[lolodomo]

Go

[lolodomo]

I am going to reverse the logic, making addon.config.xxx the normal key for add-ons and keeping the key <type>.config.xxx as alternative.

[lolodomo]

Ok, finished. I changed the title and the content of the initial message.

[J-N-K]

LGTM.

[lolodomo]

@J-N-K @kaikreuzer : please backport to branch 4.2.x before building 4.2.1.

[kaikreuzer]

@lolodomo Done!

[wborn]

Now it is cherry-picked to the OH repo.