Add i18n-maven-plugin to make internationalization easier #2544

wborn · 2021-10-28T17:41:57Z

This plugin simplifies generating the default translation .properties files from the add-on XML information files.

It reuses the same XStream parsing classes that are used by openhab-core for parsing the binding/config/thing XML files.
It will also keep any existing default translations already present in property files for translations using @text/.
Furthermore it will nicely group and sort the translations.

After building this Maven plugin you can use it on add-ons using:

mvn org.openhab.core.tools:i18n-maven-plugin:3.2.0-SNAPSHOT:generate-default-translations

This commit shows what it generates when run on all add-ons.

openhab-bot · 2021-10-28T18:07:49Z

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/language-support-question-regional-settings-language-vs-browser-language/128010/2

lolodomo · 2021-11-01T16:42:31Z

Trying with the vigicrues binding, I got these channels types:

channel-type.vigicrues.alert-icon.label = Pictogram
channel-type.vigicrues.alert-icon.description = Official pictogram associated to alert level.
channel-type.vigicrues.alert-level.label = Alert
channel-type.vigicrues.alert-level.state.option.0 = Green
channel-type.vigicrues.alert-level.state.option.1 = Yellow
channel-type.vigicrues.alert-level.state.option.2 = Orange
channel-type.vigicrues.alert-level.state.option.3 = Red
channel-type.vigicrues.comment.label = Comment
channel-type.vigicrues.flow.label = Current Flow
channel-type.vigicrues.gauge.label = Relative Measure
channel-type.vigicrues.height.label = Height
channel-type.vigicrues.height.description = Water level in the river
channel-type.vigicrues.observation-time.label = Observation Time
channel-type.vigicrues.observation-time.description = Observation date and time

But in the original french properties file created by @clinique, I have other entries like

channel-type.vigicrues.relative-flow.label = DÃ©bit relatif
channel-type.vigicrues.relative-flow.description = DÃ©bit relatif par rapport aux crues historiques.
channel-type.vigicrues.relative-height.label = Hauteur relative
channel-type.vigicrues.relative-height.description = Hauteur relative par rapport aux crues historiques.
channel-type.vigicrues.short-comment.label = Situation
channel-type.vigicrues.short-comment.description = Bref descriptif de la situation.

Here is how are defined these channel in the thing file:

		<channels>
			<channel id="height" typeId="height"/>
			<channel id="relative-height" typeId="gauge">
				<label>Relative Height</label>
				<description>Current height toward historical floods.</description>
			</channel>
			<channel id="flow" typeId="flow"/>
			<channel id="relative-flow" typeId="gauge">
				<label>Relative Flow</label>
				<description>Current flow toward historic floods.</description>
			</channel>
			<channel id="alert" typeId="alert-level"/>
			<channel id="alert-icon" typeId="alert-icon"/>
			<channel id="short-comment" typeId="comment">
				<label>Short description</label>
			</channel>
			<channel id="comment" typeId="comment"/>
			<channel id="observation-time" typeId="observation-time"/>
		</channels>

I am asking myself if there is not a bug in your tool which should create an entry for each channel, not only for each channel type (except if the channel type is a system channel type) ?
In case the bug is confirmed, we will have to check again all bindings for which we use the tool to build the default properties file.

lolodomo · 2021-11-01T19:24:13Z

Finally, I am not sure there is a bug. This looks more like a missing feature or maybe I don't know what path to use for example to translate the label of the short-comment channel. channel-type.vigicrues.short-comment.label is not working. channel.vigicrues.short-comment.label is not working. @cweitkamp : do you know what path should be used in this case (label or description defined on the channel itself) ?
If this is not implemented, the solution would be to use @text.

lolodomo · 2021-11-01T22:33:03Z

I finally found the right key to use for channels. For example: thing-type.vigicrues.station.channel.short-comment.label and thing-type.vigicrues.station.channel.short-comment.description

Ideally it should be considered by your i18n maven plugin.

wborn · 2021-11-01T22:36:37Z

I think it should be possible. I remember I had a look at the astro binding where labels/descriptions are overriden for certain channel group types. But I probably forgot to add something similar for channel types. 😊

wborn · 2021-11-01T22:41:35Z

I think this is the logic that takes care of it for channel group types with overriden labels/descriptions:

https://github.com/openhab/openhab-core/pull/2544/files#diff-b7101042a9b1b8825f910f519872ac389701fb78eaf34c86116933f2b9d30f83R206-R220

lolodomo · 2021-11-01T23:21:11Z

I checked the recent default properties file generated and I think we have to fix those for the following bindings: openuv, weathercompany, kodi and probably awmfritz. So you can test an update of your tool on one of these bindings.

wborn · 2021-11-07T17:42:44Z

It should now also generate default translations for overridden channels in thing types @lolodomo.

Furthermore it now also generates translations for bundles that only have config descriptions, like automation/io/persistence/transform/voice or core bundles. 🙂

lolodomo · 2021-11-07T18:26:09Z

It should now also generate default translations for overridden channels in thing types

Just tested it with the openuv bidnign and it works.
I am going to fix few bindings.

lolodomo · 2021-11-07T19:19:11Z

One option would be to run your tool on all bindings without any properties file. This will open these bindings to translations in Crowdin. This will not be a full internationalisation of these bindings but probably an internationalisation at around 90% or even 95%. What could be missing (because it requires specific code) is thing status message, discovery result label or hardcoded English string value for channel state. Another risk is to get not optimized properties files with duplicated strings.

For bindings having already properties files, we have to take care and do it manually with precaution.

WDYT @wborn ?

wborn · 2021-11-07T21:00:52Z

This will not be a full internationalisation of these bindings but probably an internationalisation at around 90% or even 95%.

Yes I also think the generated properties files will be a good start and it allows users to start translating while devs add the last remaining %. Add-ons that no longer have a maintainer would also greatly benefit from this.

My idea was to first get a feeling on how well it works and iron out the bugs before mass generating them all. I think it already works pretty well.

But even with all bugs ironed out it will not remove any duplicate strings. However being able to translate something multiple times is better than not being able to translate strings at all. 😉

ghys · 2021-11-07T21:56:13Z

This will not be a full internationalisation of these bindings but probably an internationalisation at around 90% or even 95%.

If it is any incentive, I believe it could also trigger the i18n of the admin part of the UI as well; currently while all the user areas are translatable (and translated), most the admin pages still aren't because I figured a significant part of those are parameter sheets that would still appear in English, so IMO it is not worth the effort at this time (I mean the effort of replacing all these hardcoded strings, a tedious and thankless job... translating strings is another matter but past translation campaign experiences with Crowdin gives much confidence the community will step up).
If the admin needs to understand English to figure out the parameters, then the other parts of the admin UI should be no problem either so there's little point in translating it. But if we can achieve a good i18n "coverage" in most key languages across the most popular bindings then it becomes more appealing to go all the way.

cweitkamp · 2021-11-11T19:40:22Z

I added a missing feature to translate CommandOptions in wborn#4.

jimtng · 2021-11-17T09:46:22Z

mvn org.openhab.core.tools:i18n-maven-plugin:3.2.0-SNAPSHOT:generate-default-translations

I used this handy tool recently. Is there a way to make this command a lot simpler, e.g. mvn tools:generate-translations or something similar?

wborn · 2021-11-17T10:46:52Z

I think when it is merged and added as plugin dependency you should also be able to use it with:

mvn i18n:generate-default-translations

See also:

cweitkamp

Your contribution is in a good shape @wborn . Do you consider to change this PRs type from draft to ready to be merged soon?

cweitkamp · 2021-11-21T13:11:51Z

...i18n-plugin/src/main/java/org/openhab/core/tools/i18n/plugin/XmlToTranslationsConverter.java

+
+                if (stateDescription.getPattern() != null) {
+                    String pattern = stateDescription.getPattern();
+                    if (pattern != null && pattern.contains("%1$t")) {


Did you add this check (pattern.contains("%1$t")) by intention to filter every other pattern except date time related ones? I was looking into this because I am missing pattern for channel types from feed binding for translation. It uses "%tc" as pattern. I personally would be fine with this and change it for feed binding to something else. Or should we extend it here?

See openhab/openhab-addons#11618

I added the filter because when it is not applied it will also start adding the patterns for the following states to .properties files:

<state pattern="%s">

<state pattern="%.2f" readOnly="true"/>

<state pattern="%.1f %unit%"/>

I doubt these would often result in other translations.

Although later I realised that any string that has a space in it, is also a potential translation candidate for any language that is right-to-left instead of left-to-right. 🙂

wborn · 2021-11-21T13:51:46Z

Do you consider to change this PRs type from draft to ready to be merged soon?

Adding some unit tests for this plugin is still on my todo list. Also I want to add a plugin config option to skip generating default translations when the .properties file already exists. That would simplify creating a PR that adds default translations to all add-ons that do not have these already.

This plugin simplifies generating the default translation .properties files from the add-on XML information files. It reuses the same XStream parsing classes that are used by openhab-core for parsing the binding/config/thing XML files. It will also keep any existing default translations already present in property files for translations using `@text/`. Furthermore it will nicely group and sort the translations. After building this Maven plugin you can use it on add-ons using: `mvn org.openhab.core.tools:i18n-maven-plugin:3.2.0-SNAPSHOT:generate-default-translations` Signed-off-by: Wouter Born <[email protected]>

Signed-off-by: Wouter Born <[email protected]>

Signed-off-by: Christoph Weitkamp <[email protected]>

Signed-off-by: Wouter Born <[email protected]>

To only create missing default translations files execute: mvn org.openhab.core.tools:i18n-maven-plugin:3.2.0-SNAPSHOT:generate-default-translations -Di18n.generation.mode=ADD_MISSING_FILES Or to replace any existing content and only use the generated content use: mvn org.openhab.core.tools:i18n-maven-plugin:3.2.0-SNAPSHOT:generate-default-translations -Di18n.generation.mode=REGENERATE_FILES Signed-off-by: Wouter Born <[email protected]>

Signed-off-by: Wouter Born <[email protected]>

See: openhab/openhab-addons#11646 Signed-off-by: Wouter Born <[email protected]>

cweitkamp

LGTM. Thank you very much

This will help developers a lot and safes much time regarding creation of translation properties. I bet you will submit a bunch of documentation later 😉 .

Let's go!

cweitkamp · 2021-12-01T16:27:23Z

Am I allowed to merge this as I submitted code - not much, but I did - for it?

//CC @openhab/core-maintainers

kaikreuzer · 2021-12-01T16:52:30Z

Am I allowed to merge this as I submitted code - not much, but I did - for it?

Fine with me, go ahead!

When the plugin dependency is managed you can also use the plugin without adding GAV parameters to commands. E.g. it allows for using it with: ``` mvn i18n:generate-default-translations ``` Related to openhab#2544 Signed-off-by: Wouter Born <[email protected]>

When the plugin dependency is managed you can also use the plugin without adding GAV parameters to commands. E.g. it allows for using it with: ``` mvn i18n:generate-default-translations ``` Related to #2544 Signed-off-by: Wouter Born <[email protected]>

* Add i18n-maven-plugin to make internationalization easier This plugin simplifies generating the default translation .properties files from the add-on XML information files. It reuses the same XStream parsing classes that are used by openhab-core for parsing the binding/config/thing XML files. It will also keep any existing default translations already present in property files for translations using `@text/`. Furthermore it will nicely group and sort the translations. After building this Maven plugin you can use it on add-ons using: `mvn org.openhab.core.tools:i18n-maven-plugin:3.2.0-SNAPSHOT:generate-default-translations` Signed-off-by: Wouter Born <[email protected]> GitOrigin-RevId: bb3224a

openhab-bot · 2023-08-04T10:45:21Z

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/openhab-4-translation-fallback-in-main-ui/148331/2

openhab-bot · 2023-12-22T16:01:22Z

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/is-there-a-translation-i18n-util-for-general-use/152229/5

wborn added the i18n/l10n Internationalization/Localization label Oct 28, 2021

lolodomo mentioned this pull request Nov 1, 2021

Bindings translation in French openhab/openhab-addons#11490

Closed

19 tasks

wborn mentioned this pull request Nov 1, 2021

[WIP][i18n] Added XSLT transformation to create properties files from XML definitions openhab/openhab-addons#10636

Closed

wborn force-pushed the i18n-plugin branch from 68ab349 to 399a152 Compare November 7, 2021 17:40

cweitkamp mentioned this pull request Nov 8, 2021

[openhabcloud] Added default i18n properties file openhab/openhab-addons#11547

Merged

cweitkamp added rebuild Triggers the Jenkins PR build and removed rebuild Triggers the Jenkins PR build labels Nov 12, 2021

wborn mentioned this pull request Nov 14, 2021

[jrubyscripting] JRuby scripting initial contribution openhab/openhab-addons#11538

Merged

cweitkamp reviewed Nov 21, 2021

View reviewed changes

wborn added 4 commits November 27, 2021 09:59

Cleanup and some rework

dc7b45e

Signed-off-by: Wouter Born <[email protected]>

Fix missing properties for overridden channels in thing types

4ab2d3e

Signed-off-by: Wouter Born <[email protected]>

Add support for generating default translations for non-binding bundles

3d4c586

Signed-off-by: Wouter Born <[email protected]>

cweitkamp and others added 5 commits November 27, 2021 09:59

Added missing feature to translate CommandOptions (#4)

a5e9726

Signed-off-by: Christoph Weitkamp <[email protected]>

Cleanup

0764ef9

Signed-off-by: Wouter Born <[email protected]>

Add JavaDocs and some improvements

1b948c1

Signed-off-by: Wouter Born <[email protected]>

Add unit tests

ec9b1d8

Signed-off-by: Wouter Born <[email protected]>

wborn force-pushed the i18n-plugin branch from 8aff638 to ec9b1d8 Compare November 27, 2021 20:02

wborn marked this pull request as ready for review November 27, 2021 20:03

wborn requested a review from a team as a code owner November 27, 2021 20:03

wborn mentioned this pull request Nov 28, 2021

Add i18n-maven-plugin dependency openhab/openhab-addons#11648

Merged

Improve generic bundle translation generation

67b5090

See: openhab/openhab-addons#11646 Signed-off-by: Wouter Born <[email protected]>

cweitkamp approved these changes Dec 1, 2021

View reviewed changes

cweitkamp merged commit bb3224a into openhab:main Dec 1, 2021

cweitkamp added this to the 3.2 milestone Dec 1, 2021

wborn deleted the i18n-plugin branch December 1, 2021 18:46

wborn mentioned this pull request Dec 1, 2021

Add i18n-maven-plugin dependency #2584

Merged

wborn mentioned this pull request Dec 12, 2021

Add default translations for binding add-ons openhab/openhab-addons#11760

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add i18n-maven-plugin to make internationalization easier #2544

Add i18n-maven-plugin to make internationalization easier #2544

wborn commented Oct 28, 2021

openhab-bot commented Oct 28, 2021

lolodomo commented Nov 1, 2021 •

edited

Loading

lolodomo commented Nov 1, 2021

lolodomo commented Nov 1, 2021 •

edited

Loading

wborn commented Nov 1, 2021 •

edited

Loading

wborn commented Nov 1, 2021

lolodomo commented Nov 1, 2021

wborn commented Nov 7, 2021

lolodomo commented Nov 7, 2021

lolodomo commented Nov 7, 2021 •

edited

Loading

wborn commented Nov 7, 2021

ghys commented Nov 7, 2021

cweitkamp commented Nov 11, 2021

jimtng commented Nov 17, 2021

wborn commented Nov 17, 2021

cweitkamp left a comment

cweitkamp Nov 21, 2021

cweitkamp Nov 21, 2021

wborn Nov 21, 2021 •

edited

Loading

wborn commented Nov 21, 2021

cweitkamp left a comment

cweitkamp commented Dec 1, 2021

kaikreuzer commented Dec 1, 2021

openhab-bot commented Aug 4, 2023

openhab-bot commented Dec 22, 2023

Add i18n-maven-plugin to make internationalization easier #2544

Add i18n-maven-plugin to make internationalization easier #2544

Conversation

wborn commented Oct 28, 2021

openhab-bot commented Oct 28, 2021

lolodomo commented Nov 1, 2021 • edited Loading

lolodomo commented Nov 1, 2021

lolodomo commented Nov 1, 2021 • edited Loading

wborn commented Nov 1, 2021 • edited Loading

wborn commented Nov 1, 2021

lolodomo commented Nov 1, 2021

wborn commented Nov 7, 2021

lolodomo commented Nov 7, 2021

lolodomo commented Nov 7, 2021 • edited Loading

wborn commented Nov 7, 2021

ghys commented Nov 7, 2021

cweitkamp commented Nov 11, 2021

jimtng commented Nov 17, 2021

wborn commented Nov 17, 2021

cweitkamp left a comment

Choose a reason for hiding this comment

cweitkamp Nov 21, 2021

Choose a reason for hiding this comment

cweitkamp Nov 21, 2021

Choose a reason for hiding this comment

wborn Nov 21, 2021 • edited Loading

Choose a reason for hiding this comment

wborn commented Nov 21, 2021

cweitkamp left a comment

Choose a reason for hiding this comment

cweitkamp commented Dec 1, 2021

kaikreuzer commented Dec 1, 2021

openhab-bot commented Aug 4, 2023

openhab-bot commented Dec 22, 2023

lolodomo commented Nov 1, 2021 •

edited

Loading

lolodomo commented Nov 1, 2021 •

edited

Loading

wborn commented Nov 1, 2021 •

edited

Loading

lolodomo commented Nov 7, 2021 •

edited

Loading

wborn Nov 21, 2021 •

edited

Loading