Page MenuHomePhabricator

Babel named parameter handling is inconsistent and order-dependent
Open, Needs TriagePublic

Description

{{#babel:plain=true|language}}

Renders a plain babel box for the given language.

{{#babel:language|plain=true}}

Renders a non-plain babel box for the given language (|plain=true is ignored because it doesn't come first.)

{{#babel:plain=true|template}}

Renders a plain invocation of the given template, passing it no arguments (|plain=true is not given as an argument because the first parameter to a template appears to be always ignored due to a bug)

{{#babel:plain=true|baz=true|template}}

Renders a plain invocation of the given template, passing it the argument baz=true (|plain=true is not given as an argument the first parameter to a template appears to be always ignored due to a bug)

{{#babel:template|plain=true}}

Renders a non-plain babel box for the given template, passing it no arguments (|plain=true is ignored since it comes after the template)

{{#babel:plain=true|template|baz=true|template2}}

Renders a plain babel box for the given templates, passing baz=true to the first one but not the second one (and plain=true to neither because of the same bug as above)

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.

Event Timeline

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:

Template:User foo
{{Userbox |icon={{{a|A}}} |text={{{text|Text}}} }}
Template:User bar
{{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.

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.)

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.

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.

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.

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.

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.

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?

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.

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.