Localization plugins: Where do we go from here?

[Daniel Beck]

Hi everyone,

I looked at bit into the current state of separate localization plugins (JEP-216[1]) this weekend.

Currently, there is one such plugin, localization-zh-cn[2]. It includes both Simplified Chinese translations, as well as supporting infrastructure to enable their use, IIUC partly/mostly based on how the Translation Assistance Plugin could be used to load local user-provided translations.

The plugin supports two of the three major localization 'types' (views and Stapler resources) and I'm currently looking into adding support for the third[3], localizer/Messages.properties.


AFAIUI, we have two options how to continue from here to support further externalized localizations, and I'm not sure these have been properly evaluated so far (corrections welcome).

Option A:
Rename the plugin from `localization-zh-cn` to `localization` and add other languages to this plugin. Some supporting infra code will need to be adapted to make this work; right now `_zh_CN` is partly hardcoded. Will require some additional governance to support many additional contributors to this one plugin. Might result in many more releases than are needed for a specific user group, or changes not being published in a timely manner.

Option B:
Duplicate all of the support infrastructure from localization-zh-cn into, for example, localization-de, and maintain it twice. I'm not even sure it'd work based on the code in localization-zh-cn that deals with identifying conflicting plugins[4].

Option C:
Move the supporting infrastructure from `localization-zh-cn` into a new `localization-support` plugin and generalize it to work for any locale. Add a dependency from localization-zh-cn to localization-support.
`localization-support` is expected to remain fairly unchanging, while `localization-zh-cn` (and any other specific localization plugin) would be regularly updated to include new translations.
It adds an additional (expected to be fairly stagnant) plugin, plus one plugin per locale, but these individual plugins would only receive updates when there's actually something relevant for their user group.

Options B and C also make more sense for the 'Languages' category in the setup wizard (which would otherwise be exactly one plugin).

IMO, Option C is preferable, but it requires some refactoring to pull out supporting infrastructure from `localization-zh-cn`, but it seems to be most consistent with how this has been set up.

WDYT?

Daniel

1: https://github.com/jenkinsci/jep/tree/master/jep/216 and https://github.com/jenkinsci/jep/pull/191
2: https://github.com/jenkinsci/localization-zh-cn-plugin
3: https://github.com/kohsuke/localizer/pull/16 and https://github.com/jenkinsci/jenkins/pull/3729
4: https://github.com/jenkinsci/localization-zh-cn-plugin/blob/master/src/main/java/jenkins/plugins/localization/LocalizationMonitor.java

[arch]

I prefer option C. I can try to do this.

In order to supplement JPE-216. I hope to get more feedback about the languages separation.

Thank Daniel for your efforts.

[Daniel Beck]

> On 11. Nov 2018, at 11:41, arch <linux...@gmail.com> wrote:
>
> I prefer option C. I can try to do this.

As I wrote in Gitter, I had something in progress locally already, and finished this up to a reasonable prototype state.

It seems to work in local development, but has undergone minimal testing so far. If you have time, would be great if you could look into it and tell me what you think.

https://github.com/kohsuke/localizer/pull/16
https://github.com/jenkinsci/jenkins/pull/3729
https://github.com/daniel-beck/localization-support-plugin
https://github.com/jenkinsci/localization-zh-cn-plugin/pull/31

[arch]

How about adding a method to indicate target language in LocalizationContributor. So we could get a list of all language plugins.

[Jesse Glick]

On Sun, Nov 11, 2018 at 5:23 AM Daniel Beck <m...@beckweb.net> wrote:
> Option A:

> Rename the plugin from `localization-zh-cn` to `localization` and add other languages to this plugin. […] Will require some additional governance to support many additional contributors to this one plugin.

https://help.github.com/articles/about-codeowners/

would help, right?

> Might result in many more releases than are needed for a specific user group, or changes not being published in a timely manner.

I would hope that maintainers under this scenario would err on the
side of more releases. Releasing is cheap.

It depends on whose experience you care to optimize. I would expect
that the Bulgarian translator(s) would find it less of a hassle to
file pull requests against an existing plugin repository than to
create and register a new plugin. Of course you can argue that we do
not want spottily maintained translations to begin with; currently we
have several dozen translations of widely varying completeness (and
perhaps quality).

[Jon Brohauge]

I'd go with option C. I'd love to help in Danish where needed.

[Robert Sandell]

Is the intention to move all translations from core and plugins into these new localisation plugins? Looking at https://github.com/jenkinsci/jenkins/pull/3729 it seems so?

I started the other day to update plugin pom and core versions on one of my older plugins and got some "illegal access compilation errors" because the plugin was using hudson.model.Messages for some of its UI strings. I assume this was added because it can break compatibility in case of refactoring in core and suddenly the key is renamed or something.

But that access guard is now then somewhat void since it will be very cumbersome to change a resource bundle key as you then need to change it in 30 odd localization plugins to not have them break, and changing them will break older versions broken anyway.

So I'm a bit confused as to the practicality of this as the assumption seems to be that keys are not guaranteed to be set in stone?

/B

Den ons 14 nov. 2018 kl 18:00 skrev Jon Brohauge <jonbr...@gmail.com>:

I'd go with option C. I'd love to help in Danish where needed.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/49d4147c-e984-4871-9515-59d5b423d018%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Robert Sandell

Software Engineer

CloudBees, Inc.

E: rsan...@cloudbees.com

Twitter: robert_sandell

[Jesse Glick]

On Fri, Nov 16, 2018 at 6:12 AM Robert Sandell <rsan...@cloudbees.com> wrote:
> Is the intention to move all translations from core and plugins into these new localisation plugins?

That is my understanding.

> got some "illegal access compilation errors" because the plugin was using hudson.model.Messages for some of its UI strings. I assume this was added because it can break compatibility in case of refactoring in core

Yes, your plugin could get a linkage error if messages are rearranged
in a lower layer (not necessarily core).

> it will be very cumbersome to change a resource bundle key as you then need to change it in 30 odd localization plugins

No, I do not think there is any expectation that developers would
rename keys in localization plugins. They would just change the
English key. In particular, `core/move-l10n.groovy` could be deleted.

Translators are responsible for keeping up: introducing translations
for recently added keys, or removing stale translations for keys which
no longer exist. If a given version of the localization plugin for a
given locale fails to supply a translation for a given key, then it
will simply be rendered in English.

[Daniel Beck]

> On 16. Nov 2018, at 20:17, Jesse Glick <jgl...@cloudbees.com> wrote:
>
> Translators are responsible for keeping up: introducing translations
> for recently added keys, or removing stale translations for keys which
> no longer exist. If a given version of the localization plugin for a
> given locale fails to supply a translation for a given key, then it
> will simply be rendered in English.

Note that from a user POV this is no different than what we've been doing for a long time, at least in core: On nontrivial changes to localization strings, we just delete the translations we cannot adapt with minimal/no knowledge of the language. The only difference is that localization plugins will contain have the obsolete translation, and may need to carry it around for a while to remain compatible with slightly older releases of the translated component.