Request permission for plugins

[Rick]

Hi there,

We will do localization work for some Jenkins core and plugins, more detail is here https://groups.google.com/forum/#!topic/jenkinsci-dev/QJQ_fzfILcI

In order to do localization better, it will be more convenient if we get the permission to merge PR request. 

[Slide]

I think this should all be done via PR's so they can go through the normal review process. 

--
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/96895823-3596-4774-9a1a-65ee815d6bed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[arch]

I understand the process. The question is we lack Chinese reviewer. And I want to be volunteer. Thanks.

[Slide]

You don't need access to merge prs to review them. Just have people cc you in the PR for review.

On Sat, Aug 18, 2018, 08:28 arch <linux...@gmail.com> wrote:

I understand the process. The question is we lack Chinese reviewer. And I want to be volunteer. Thanks.

--

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/CAMM7nTF_kV%2B06pL3o71YyFEhPayoktmpCUUJvhtnFMfN2imzmw%40mail.gmail.com.

[Daniel Beck]

> On 18. Aug 2018, at 17:55, Slide <slide...@gmail.com> wrote:
>
> You don't need access to merge prs to review them. Just have people cc you in the PR for review.

It looks to me like this is an attempt to get translation contributions unblocked. Rick's previously filed numerous translation PRs in the past that got ignored for weeks or months (unsurprising if the maintainers cannot even evaluate the PR).

That said, I expect more problems from granting commit access to plugin repos to merge localization changes, no matter how well intentioned and executed, while we consider plugins as largely independent subprojects. So the approach here would be to get the permissions from individual plugin maintainers, which seems to defeat the purpose of streamlining the process. Given the list of plugins in the other thread though, it might be feasible for maintainers of the Pipeline plugin suite to grant access -- ultimately up to them though.


I wonder what it would take to implement something similar to what Jesse wrote in the Chinese Localization SIG thread -- something like a "Chinese Translations" plugin that contains translations for other plugins.

[arch]

Yes, we will discuss about how to separate the localization files. But maybe not so fast.

I will continue to do this work no matter I wether have commit permission. I just hope I can push the work faster. One of the plugins maintainers already contact me and wish we can help him to do localization work. I mean the work is meaningful.

--
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/9A0135FE-FF06-43F6-AC0A-E5F2F7277DA5%40beckweb.net.

[Jesse Glick]

On Sat, Aug 18, 2018 at 12:43 PM Daniel Beck <m...@beckweb.net> wrote:
> something like a "Chinese Translations" plugin that contains translations for other plugins.

This would certainly be the physically simplest option, if it works.
Depends on whether code looking for locale variants checks the
`UberClassLoader`, or the defining loader of some plugin.

[Daniel Beck]

> On 20. Aug 2018, at 15:13, Jesse Glick <jgl...@cloudbees.com> wrote:
>
> if it works

Neither Messages nor Jelly view resources work. Only 'help files' work.

[Jesse Glick]

On Mon, Aug 20, 2018 at 9:24 AM Daniel Beck <m...@beckweb.net> wrote:
> Neither Messages nor Jelly view resources work. Only 'help files' work.

OK. Probably relatively easy to fix.

[Oleg Nenashev]

This would certainly be the physically simplest option, if it works.
Depends on whether code looking for locale variants checks the
`UberClassLoader`, or the defining loader of some plugin.

In the worst case, it is possible to use localization overrides via an engine similar to the Translation Assistance plugin.

https://github.com/jenkinsci/translation-plugin/blob/master/src/main/java/hudson/plugins/translation/L10nDecorator.java

 

That said, I expect more problems from granting commit access to plugin repos to merge localization changes, no matter how well intentioned and executed, while we consider plugins as largely independent subprojects.

+1,

[arch]

Commit access is just for convenience. But I think that separate localization resources are not so good for users experience, maybe it's pretty simple. When I first install Jenkins on my computer, I wish I can get a localization page instead of choosing languages plugin.

--

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/b5fad2ae-d600-439a-b502-56663a4fcf60%40googlegroups.com.

[Daniel Beck]

> On 27. Aug 2018, at 04:25, arch <linux...@gmail.com> wrote:
>
> When I first install Jenkins on my computer, I wish I can get a localization page instead of choosing languages plugin.

We can always make the (possible) 'Localizations Plugin' a recommended-by-default plugin in the Wizard, so once you've gone past that, it will be present unless you actively choose to not install it. If we go this route, we could in theory remove all localizations from core except for the Setup Wizard.

[arch]

Sounds good to me. One more question is about the plugins. We could create a Chinese Localization plugin for Jenkins core. But we can't create every localization for other plugins. Right? Because there are lots of them.

--
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/E25B2590-7479-47E4-9151-F24B695253A7%40beckweb.net.

[Jesse Glick]

On Mon, Aug 27, 2018 at 5:33 AM arch <linux...@gmail.com> wrote:
> We could create a Chinese Localization plugin for Jenkins core. But we can't create every localization for other plugins. Right? Because there are lots of them.

I do not see a problem here. If you are working on the Chinese
localization, or Albanian or whatever, you get to decide how much you
wish to localize. If you have time to localize every plugin listed in
the Setup wizard and then some others, great. If you can only manage
some of the most commonly seen screens (and maybe only part of core),
so be it. You need to balance the desire for completeness with
available resources, and keep in mind that as code is changed and
refactored over time there will be some new message keys and some
obsolete ones, so there is an ongoing cost proportional to the size of
the localization.

[arch]

For example, I want to localize five plugins(A, B, C, D, E). You mean I need to create five repos, A-zh, B-zh, C-zh, D-zh, E-zh?

--
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/CANfRfr3DoWyNdO%2BoacHxNx7vO%3DqpUV-xj8XjbFZM6fuTKCvj_g%40mail.gmail.com.

[Slide]

I would hope that you would be able to localize in a single "Chinese Localization" plugin. I am not sure how that would work myself, but I think that would be better than plugin-a-zh, plugin-b-zh, etc.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTHZ4MX5eK4%3DY2yzHHhMQerpHVgudE28bThHsM54VVxbFg%40mail.gmail.com.

[arch]

OK, I can try to do it as we discuss.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVcAOoAUZJ19obMx-zO6YD7KdgiQ6zEB-oqKo3UCXu7iew%40mail.gmail.com.

[Jesse Glick]

On Mon, Aug 27, 2018 at 10:01 AM Slide <slide...@gmail.com> wrote:
> I would hope that you would be able to localize in a single "Chinese Localization" plugin.

Or, perhaps, a single plugin for _all_ localizations. For example,
something like

jenkinsci/l10n-plugin/src/main/resources/org/jenkinsci/plugins/workflow/cps/CpsFlowDefinition/config_zh_CN.properties

but maybe there needs to be one top-level subdirectory per locale¹, or
some directory structure indicating plugin name, etc. etc.

> I am not sure how that would work myself

So far I and other Jenkins core developers have just been throwing out
ideas. Acc. to things Daniel said, there probably need to be some
minor changes to core to make it work.


¹Would be useful to use
https://help.github.com/articles/about-codeowners/#codeowners-syntax
to associate each localization with a set of usernames.

[arch]

Agree with this solution. And I give a prototype plugin. https://github.com/LinuxSuRen/localization-plugin

Do I need to create a ticket on JIRA or just everyone take a look at this project?

--
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/CANfRfr0pN9PyqzhjG03oKWNPtOCDRR7CkM6xUQ61g51cPCJDMQ%40mail.gmail.com.

[Oleg Nenashev]

I would rather prefer separate plugins for each localization.

It would allow to properly form reviewer teams and to manage release cycles independently.

You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/jeKVskUwE8M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTH4fazLwqaxPWrdiwDPJwa72dGoo_o%2BP6N9qVRwfvWSgg%40mail.gmail.com.

[Jesse Glick]

On Tue, Aug 28, 2018 at 2:34 AM arch <linux...@gmail.com> wrote:
> Agree with this solution. And I give a prototype plugin. https://github.com/LinuxSuRen/localization-plugin

Nice, did you get this to work already? There are a few things to check:

· core vs. plugin localization
· `Messages_zh_CN.properties` (so `Messages.some_key()` Java calls)
· `*_zh_CN.properties` (localization from Jelly views like `index`)
· `help*_zh_CN.html` if these are even supported (I cannot remember offhand)
· `mvn hpi:run` incl. live reloading after saving a resource in the source tree
· effectiveness in a `$JENKINS_HOME/plugins/*.jpi` (this is a
different class loading mode)

> Do I need to create a ticket on JIRA or just everyone take a look at this project?

I think this would make a good JEP describing what you propose to do
and making sure other localizers are ready to coöperate, since this
clearly goes beyond a usual plugin HOSTING request: it would involve
_removing_ localization resources from lots of existing repositories,
adjusting the default plugin list in the Setup wizard, and maybe some
infrastructure tasks. And there are some details that need to be
settled such as the plugin code names (which cannot be changed after
publishing): rather than, say, `chinese-localization` I might suggest
something more regular like `localization-zh_CN`.

[Daniel Beck]

> On 28. Aug 2018, at 08:44, Oleg Nenashev <o.v.ne...@gmail.com> wrote:
>
> I would rather prefer separate plugins for each localization.
> It would allow to properly form reviewer teams and to manage release cycles independently.

Only with an aggregator plugin. Otherwise the benefits of managing separate per-language translation plugins are outweighed by the downsides on the user side: In language diverse communities or organizations, having to install (or request installation) of a new translation plugin every month, because now a French/German/Italian/Russian/Portuguese/Spanish/Chinese/Turkish/Polish/Czech/… speaking person wants their Jenkins localized in their own language seems cumbersome.

Right now, it seems the best we can do is:
(Aggregator) -- depends on all --> (individual language plugins) -- each depends on the --> (translation enablement plugin)

Or just put everything in one plugin because otherwise it becomes an unmanageable mess. We can always split them like this if the one plugin becomes unmanageable.

[arch]

Thanks for your checklist and suggestion. That's really great.

--
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/CANfRfr1YJ0BuDZ6mXAKO%2BUFkG0tFiun6W-9GpWSfxVyUr5%2BZPw%40mail.gmail.com.

[Oleg Nenashev]

In language diverse communities or organizations, having to install (or request installation) of a new translation plugin every month, because now a French/German/Italian/Russian/Portuguese/Spanish/Chinese/Turkish/Polish/Czech/… speaking person wants their Jenkins localized in their own language seems cumbersome.

I do not know any organization which actually does that. Usually Jenkins is managed via various shared services teams if it gets to such scale, and having different localizations makes the system generally unsupportable. Imagine you get a support tickets with screenshots in Russian.. oh wait, it happens in JIRA sometimes.

Usually Jenkins admins end up enforcing a single locale using the Locale Plugin. I do not anticipate large-scale instances to require many localization plugins, and I do not see a particular need in an aggregator plugin, especially taking our experience with maintaining them. For example, the current version of Pipeline aggregator just contains obsolete plugins with known incompatibilities like JEP-200.

BR, Oleg

You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/jeKVskUwE8M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTFX5My%3D1ADt_tb0ySVVO254cF%3DhE0SfKOxXMLfvHYytNg%40mail.gmail.com.

[Daniel Beck]

> On 28. Aug 2018, at 14:54, Oleg Nenashev <o.v.ne...@gmail.com> wrote:
>
> I do not know any organization which actually does that. Usually Jenkins is managed via various shared services teams if it gets to such scale, and having different localizations makes the system generally unsupportable. Imagine you get a support tickets with screenshots in Russian.. oh wait, it happens in JIRA sometimes.

So they would simply not install any localization plugin. Great, so they're completely irrelevant as far as considering their preferences goes (beyond removing translations from everywhere else).

> I do not see a particular need in an aggregator plugin, especially taking our experience with maintaining them. For example, the current version of Pipeline aggregator just contains obsolete plugins with known incompatibilities like JEP-200.

Aggregator plugins do not 'contain' anything, they just list a bunch of plugins. If you install them, you get the newest releases of dependencies anyway, unless you do something unsupported with the metadata.

[Oleg Nenashev]

So they would simply not install any localization plugin. Great, so they're completely irrelevant as far as considering their preferences goes (beyond removing translations from everywhere else).

I can imagine a local company which installs a single localization plugin

That's why I lean towards having separate plugins for each locale.

If you install them, you get the newest releases of dependencies anyway, unless you do something unsupported with the metadata.

Depends on the installation logic implementation, but generally "yes".

Anyway, I would expect Incremental Tools to eventually simplify managing of aggregator plugins.

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/jeKVskUwE8M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/F5F32EE4-66F0-4892-B7CA-50CB386D8318%40beckweb.net.

[Jesse Glick]

On Tue, Aug 28, 2018 at 9:10 AM Oleg Nenashev <o.v.ne...@gmail.com> wrote:
> I would expect Incremental Tools to eventually simplify managing of aggregator plugins.

How…? `incrementals-tools` does not seem related to me.

I tend to agree that a single localization plugin would be simpler to
manage in most respects. The release cycle could be weekly, monthly,
on demand, whatever; and as I noted, GitHub has features that make it
easy enough to request particular people review PRs touching
particular subdirectories or other filename patterns. A single
repository also provides the natural home for related tooling, such as
scripts to check for missing or stale localizations.

[arch]

I wonder how many people plan to separate their localization resource files. If there is not so much, I suggest that keep other languages files in current place.

--

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/CANfRfr1PUoC2Jk3H0zntkAtHCLruHUHUS%3DT-55uDOF_Z-p7nUw%40mail.gmail.com.

[Daniel Beck]

> On 28. Aug 2018, at 15:10, Oleg Nenashev <o.v.ne...@gmail.com> wrote:
>
> I can imagine a local company which installs a single localization plugin
> That's why I lean towards having separate plugins for each locale.

… and an aggregator. It's free. Only needs updates whenever a locale plugin is added or removed. I really don't understand the resistance here.

> Depends on the installation logic implementation, but generally "yes".

Which installation logic would you consider to be supported (i.e. we wouldn't close a related Jira issue immediately) and does not install whatever is available on your chosen update site? CLI command, UI, even install-plugins.sh and configuration-as-code plugin install the newest available release of dependencies.

[Liam Newman]

I've made this JEP-216 Draft so that it can be referenced in discussions and form the prototype, but as noted it needs quite a bit of work.  

[arch]

Got it. I will add more details to it. And Thank for Liam Newman and all people's efforts.

--

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/8a4cc4fa-0eb6-43d3-8571-77b4dac2805c%40googlegroups.com.