Change 883684 had a related patch set uploaded (by Pppery; author: Pppery):

[mediawiki/extensions/Babel@master] Fix handling of babel template parameters

https://gerrit.wikimedia.org/r/883684

Expected behavior is that all named parameters do the same thing regardless of where they are in the call, and the first parameter is not ignored.

Definitely not. Different templates have different parameters; some might conflict, some might be necessary in one template but do unwanted things in the other. Consider the following templates:

{{Userbox |icon={{{a|A}}} |text={{{text|Text}}} }}

{{Userbox |icon={{#if:{{{a|}}}|A|B}} |text={{{text|Text}}} }}

and the following Babel call:

{{#babel|a=B|text=Foo text|foo|text=Bar text|bar}}

This results currently in two template calls:

{{User foo|a=B|text=Foo text}}
{{User bar|text=Bar text}}

With what you propose, neither displaying different texts in the two userboxes nor displaying B in the icon cell of both would be possible.

I'm not sure that we need to support single template parameters, That's something scary. For personal design, you can always use TemplateStyles.

Well, that's what I expected, to be consistent with the way all other uses of template arguments worked. Apparently people can disagree.

In T327847#8568917, @Iniquity wrote:

I'm not sure that we need to support single template parameters, That's something scary. For personal design, you can always use TemplateStyles.

How would you change the content using TemplateStyles? It’s for styles. (Let alone you can’t even have TemplateStyles pages in userspace, since .css subpages there are considered to be user stylesheets.)

In T327847#8572851, @Pppery wrote:

Well, that's what I expected, to be consistent with the way all other uses of template arguments worked.

What other uses of template arguments? I don’t know of any other extension or core code that creates template calls based on template/parser function parameters.

On the other hand, recognizing the parameters after, and only after, the template name, i.e.

{{#babel|foo|a=B|text=Foo text|bar|text=Bar text}}

would be usable and easier to understand; however, it would be a breaking change, needing a careful deprecation and migration process.

In T327847#8573523, @Tacsipacsi wrote:

In T327847#8568917, @Iniquity wrote:

I'm not sure that we need to support single template parameters, That's something scary. For personal design, you can always use TemplateStyles.

How would you change the content using TemplateStyles? It’s for styles.

By the way, I'm not very sure that you need to change something in the content of the babel userboxes. Do you have examples?

(Let alone you can’t even have TemplateStyles pages in userspace, since .css subpages there are considered to be user stylesheets.)

You can create a TS in templates and then use it on a user page.

In T327847#8573880, @Iniquity wrote:

By the way, I'm not very sure that you need to change something in the content of the babel userboxes. Do you have examples?

Sure. {{User Facebook}}, {{User contrib}} etc. (I didn’t check if they’re actually used within {{#babel:}} boxes or only using legacy babel templates, but they could well be.)

You can create a TS in templates and then use it on a user page.

The template namespace is for reusable templates, not for personal designs used on single pages. The syntax Babel uses is messy, but putting personal design templates in the template namespace is a lot messier.

In T327847#8575823, @Tacsipacsi wrote:

In T327847#8573880, @Iniquity wrote:

By the way, I'm not very sure that you need to change something in the content of the babel userboxes. Do you have examples?

Sure. {{User Facebook}}, {{User contrib}} etc. (I didn’t check if they’re actually used within {{#babel:}} boxes or only using legacy babel templates, but they could well be.)

These are not babylon templates, babylon templates only support language and pseudo-language templates. Everything else is regular userboxes that should not be inserted into the Babel.

You can create a TS in templates and then use it on a user page.

The template namespace is for reusable templates, not for personal designs used on single pages. The syntax Babel uses is messy, but putting personal design templates in the template namespace is a lot messier.

In fact, no, a separate template is created, in the subpages of which their css are published. Or can ask the admins to change the content model.

In T327847#8576107, @Iniquity wrote:

Everything else is regular userboxes that should not be inserted into the Babel.

The extension page takes User from London as an example. Should that not be inserted into the Babel? Then why is it an example?

In fact, no, a separate template is created, in the subpages of which their css are published. Or can ask the admins to change the content model.

Yes, exactly creating a ton of separate templates is what results in a mess. And not admins, but interface admins, since user CSS subpages cannot be modified by regular admins. If a wiki has no active interface admins – tough luck.

In T327847#8573523, @Tacsipacsi wrote:

In T327847#8572851, @Pppery wrote:

Well, that's what I expected, to be consistent with the way all other uses of template arguments worked.

What other uses of template arguments? I don’t know of any other extension or core code that creates template calls based on template/parser function parameters.

What I meant is that the way passing arguments to an actual template works (in that order does not matter, and the template in fact cannot determine parameter order). Lots of wikis, such as the English Wikipedia, use(d) a {{babel}} template, which would by necessity have ignored named argument order as all templates do, and I was expecting the extension to behave the same way. In hindsight, I can kind of see the argument for doing things a different way here.

Whatever ordering behavior we agree on, the current one, in which the first template parameter is ignored, is clearly a bug.

Also, does everyone agree that parameters such as |plain= (and |nocat= and |float= if they are added) that the extension itself handles should be recognized anywhere?

In T327847#8576541, @Tacsipacsi wrote:

In T327847#8576107, @Iniquity wrote:

Everything else is regular userboxes that should not be inserted into the Babel.

The extension page takes User from London as an example. Should that not be inserted into the Babel? Then why is it an example?

Wow, yes, of course it should be removed. Because these extensions are clearly not meant to be a regular userbox. I don't know why it was added, to be honest.

In fact, no, a separate template is created, in the subpages of which their css are published. Or can ask the admins to change the content model.

Yes, exactly creating a ton of separate templates is what results in a mess.

No, I'm not talking about that. You create one template, and create CSS on its substation. For example: https://test.wikipedia.org/wiki/Template:Userbox/iniquity.css

And not admins, but interface admins, since user CSS subpages cannot be modified by regular admins. If a wiki has no active interface admins – tough luck.

̶A̶d̶m̶i̶n̶s̶ ̶c̶a̶n̶ ̶c̶h̶a̶n̶g̶e̶ ̶c̶o̶n̶t̶e̶n̶t̶ ̶m̶o̶d̶e̶l̶:̶ ̶h̶t̶t̶p̶s̶:̶/̶/̶t̶e̶s̶t̶.̶w̶i̶k̶i̶p̶e̶d̶i̶a̶.̶o̶r̶g̶/̶w̶/̶i̶n̶d̶e̶x̶.̶p̶h̶p̶?̶t̶i̶t̶l̶e̶=̶U̶s̶e̶r̶:̶I̶n̶i̶q̶u̶i̶t̶y̶/̶c̶o̶m̶m̶o̶n̶.̶c̶s̶s̶&̶a̶c̶t̶i̶o̶n̶=̶h̶i̶s̶t̶o̶r̶y̶ Oh, sorry, I see.

In T327847#8576648, @Iniquity wrote:

Wow, yes, of course it should be removed. Because these extensions are clearly not meant to be a regular userbox. I don't know why it was added, to be honest.

I understood why it was added there - to explain the mechanics of adding pseudo-language templates that are not in ISO. For example: hangul, ipa, css, cyr etc. Not all userboxes are pseudo-languages and therefore not all of them should be included in the main block.

Change 893583 had a related patch set uploaded (by Pppery; author: Pppery):

[mediawiki/extensions/Babel@master] Add tracking category to babel usages with template parameters

https://gerrit.wikimedia.org/r/893583

In T327847#8573523, @Tacsipacsi wrote:

On the other hand, recognizing the parameters after, and only after, the template name, i.e.

{{#babel|foo|a=B|text=Foo text|bar|text=Bar text}}

would be usable and easier to understand; however, it would be a breaking change, needing a careful deprecation and migration process.

I'm actually starting to like this idea more, after a month. The first step of "a careful deprecation and migration process" seems to be to understand the scale of the situation, hence the above patch. Given that AFAIK nobody's reported the bug that the first named parameter is always ignored, I wouldn't be surprised if there are very few uses.

I think there are quite a few uses, although probably not the first boxes in the Babel columns – first come the language boxes, which take no parameters, and after them the ones that do take parameters. But let’s see.

Change #883684 abandoned by Pppery:

[mediawiki/extensions/Babel@master] Fix handling of babel template parameters

Reason:

https://gerrit.wikimedia.org/r/883684

Change #893583 merged by jenkins-bot:

[mediawiki/extensions/Babel@master] Add tracking category to babel usages with template parameters

https://gerrit.wikimedia.org/r/893583

So, on enwiki I nulledited MediaWiki:babel-category-override to force all pages using Babel to be reparsed, and there are two entries in https://en.wikipedia.org/wiki/Category:Pages_using_babel_with_named_parameters

• https://en.wikipedia.org/w/index.php?title=User:Mamushir is an obvious typo ({{#babel:en-5|fr=1}} when {{#babel:en-5|fr-1}} was intended)
• https://en.wikipedia.org/wiki/User:Ncysea is an attempt to do nocat before that worked {{#babel: plain=1|la-1|nocat=true}} and ditto for other languages)

The category also seems to have been populated on Wikidata:

• https://www.wikidata.org/wiki/User:Fl.schmitt passes the parameter mw=m to babel and I have no idea what it is supposed to di
• https://www.wikidata.org/wiki/User:Qugebert is the same
• https://www.wikidata.org/wiki/User:Tohaomg passes the parameter gender=male. This is useless since babel boxes read the gender from preferences instead.

I don't have any real way of checking other wikis, but from those two it seems like there's no intentional and meaningful uses of this feature and we have free reign to do whatever we want.

I care a lot less about this now than I did 17 months ago, though.

Can we add this functionality with a setting to enable this functionality for a transition period? I think in 90% of cases this functionality will be enabled.

I really need plain and nocat to work together :(

New users:

• https://en.wikipedia.org/wiki/User:Fixer88/Userboxes is broken now and would do what it was intended to do after the proposed change
• https://en.wikipedia.org/w/index.php?title=User:PeelitePowellite passes header=Languages. This does nothing now (it's not a supported parameter) and will continue to do nothing of consequence if the handling is changed

I checked a few random other wikis

• Spanish Wikipedia has a few userpages passing align=left after the last language. This does nothing, and will continue to do nothing. It also has a few that pass the result of expanding a template, which is broken and will continue to be broken

In T327847#9873932, @Pppery wrote:

New users:

• https://en.wikipedia.org/wiki/User:Fixer88/Userboxes is broken now and would do what it was intended to do after the proposed change
• https://en.wikipedia.org/w/index.php?title=User:PeelitePowellite passes header=Languages. This does nothing now (it's not a supported parameter) and will continue to do nothing of consequence if the handling is changed

I checked a few random other wikis

• Spanish Wikipedia has a few userpages passing align=left after the last language. This does nothing, and will continue to do nothing. It also has a few that pass the result of expanding a template, which is broken and will continue to be broken

I also jumped around different wikis and found nothing but errors in the code.

Sorry, I've been so busy with other things that I don't think I'll get around to doing more with this task any time soon. Anyone else is welcome to submit a patch (and thus have to face the broken code review situation) themselves.