TemplateData has a boolean type that supports values that can only be true or false (with an optional "unknown" state).

I don't know if VisualEditor uses this at the moment. According to T55613, a checkbox is shown for boolean parameters. Perhaps that is not working as expected?

Alternatively, it could be that the template in question doesn't yet use this parameter type in its template data. Or perhaps it can't because it specifically expects yes or (nothing) instead of 1 or 0. In that case we should consider updating the template to support these values.

If there is a large demand for an empty-or-something variant of boolean (where empty means false, instead of unknown, and any non-empty value means true), that could also be considered.

In T144155#2631526, @Krinkle wrote:

TemplateData has a boolean type that supports values that can only be true or false (with an optional "unknown" state).

I don't know if VisualEditor uses this at the moment. According to T55613, a checkbox is shown for boolean parameters. Perhaps that is not working as expected?

I'll try to create an example, to see how it works. I have no idea of the boolean value output though.

Alternatively, it could be that the template in question doesn't yet use this parameter type in its template data. Or perhaps it can't because it specifically expects yes or (nothing) instead of 1 or 0. In that case we should consider updating the template to support these values.

Is adding supported values to a template the best solution? I would say no, because some people may not want to review all templates.

If there is a large demand for an empty-or-something variant of boolean (where empty means false, instead of unknown, and any non-empty value means true), that could also be considered.

Based on my experience as an editor, I've seen both methods: empty/full parameter and precise input. Any documented option may be considered as the way to follow.

Is there any documentation somewhere?

I would also like to see yes/no supported, see: T175247

In T144155#2633095, @Trizek-WMF wrote:

Is there any documentation somewhere?

There's the spec here: https://github.com/wikimedia/mediawiki-extensions-TemplateData/blob/master/Specification.md

Not sure if that's what you were after.

In T144155#3587780, @Mvolz wrote:

In T144155#2633095, @Trizek-WMF wrote:

Is there any documentation somewhere?

There's the spec here: https://github.com/wikimedia/mediawiki-extensions-TemplateData/blob/master/Specification.md

Not sure if that's what you were after.

I see the boolean option on 3.4 Type section, but the implementation is not really easy to use. I imagine it as a Yes/No option displayed to the user instead of just a field.

In T144155#3588368, @Trizek-WMF wrote:

In T144155#3587780, @Mvolz wrote:

In T144155#2633095, @Trizek-WMF wrote:

Is there any documentation somewhere?

There's the spec here: https://github.com/wikimedia/mediawiki-extensions-TemplateData/blob/master/Specification.md

Not sure if that's what you were after.

I see the boolean option on 3.4 Type section, but the implementation is not really easy to use. I imagine it as a Yes/No option displayed to the user instead of just a field.

Yes, the wider issue is that what is recognised to TD as a "boolean" is only '0' or '1'. But in reality it may be 'yes' 'no' 'true' 'false' and then if we do other languages it gets to be a mess, do we support "vrai" "faux" "oui" "non" etc?

And if we fold them in, and the user selects, say, 0 in the GUI, how do we know that what actually belongs in the template is "no" and not '0'?

Ideally all the templates would switch to accepting '0' or '1' and that would fix things. I don't see a nice way to do this otherwise.

'0' or '1' is definitely more practical and language friendly, and expanding to other definitions is really problematic because the actual template are all over the place with how they're denoting bools.

Is possible to define some aliases on each wiki?

If so Templates maintainers will be able to implement the boolean option properly.

The most important thing is to have a nice interface for final users.

In T144155#3588622, @Trizek-WMF wrote:

Is possible to define some aliases on each wiki?

0	yes	oui	vrai
1	no	non	faux

If so Templates maintainers will be able to implement the boolean option properly.

The most important thing is to have a nice interface for final users.

Hmm, I don't think I'm quite explaining the issue well.

1. We set the parameter to "boolean."

2. The template data displays this means the value can be 0 or 1.

3. We implement your suggestion.

4. Now the user sees you can set the value to 0, 1, oui, non, vrai, or faux

5. They type in 'non' and the template displays an error because that template only accepts 'vrai' or 'faux'.

Simply put, a per wiki definition doesn't work because every single template is different. Some might accept 0 or 1, some yes and false but not 1, some 0 and no not false, etc.

The first thing that should be done when you define a parameter in Template data is to define the type of data you handle.

This would open more options, like defining two values for a boolean and they aliases:

type: boolean
"param0": "oui",
"param1": "non",
"Aliases0: "0,yes",
"Aliases1: "1,no"

I hope I'm clear enough... :)

I understand that there may be cases where you believe a user would not understand the parameter's purpose when the interface is a checkbox. For example, if a template accepts "large=yes/no", it might be preferred to present this to the user as "Size: [x] Small - [ ] Large" instead of "Use large version: [ ]". I can also imagine cases like "state=expanded/collapsed" and many others where a label is better than a toggle.

These are important cases. But that is not what booleans are for. For that, I recommend you support task T53375. That tasks asks for a new type that supports documenting a number of allowed values (two, but maybe more). They will be represented as radio buttons or a dropdown menu. The user can choose only one option. Each option has a custom value for the wikitext, and a custom (localisable) label for the user in VisualEditor.

Back to this ask, a boolean is intended to be a simple toggle. This is best represented for accessibility and semantic reasons, as a checkbox. In terms of appearance in the form, I would actually recommend using a toggle switch (https://doc.wikimedia.org/oojs-ui/master/js/#!/api/OO.ui.ToggleSwitchWidget, https://doc.wikimedia.org/oojs-ui/master/demos/#!/widgets/ToggleSwitchWidget) because checkboxes are often not a very good user experience for things that are optional and where both states are "something" (e.g. large=off, means size=small, not size=nothing). From what I can see, VisualEditor already uses toggles as checkboxes in many places so this should be simple.

The boolean type is still important to keep because it helps encourage users and wikis to look for consistency. We should not aim to have every toggle be a custom option (T53375) because that would likely create inconsistent labels between different wikis, different templates, and different languages. In addition, it also simplifies the job for bots. Booleans allow for a simple user interface where "On" (1) and "Off" (0) are mechanically understood and produce an interface where, for example, "On" can be green, bold or blue. And "Off" can be grey or red. Etc.

That is why I do not think we should support custom labels for boolean types. If you do wish to use the boolean type, but the template uses on/off, yes/no, oui/non instead of 1/0, that should be relatively easy to change in the template code to also allow 1/0. I can also help with that.

Info @ all: German Wikipedia introduced a lua function in template programming.

• TemplUtl::faculty (english)
  • L10N

TL;DR

• If template transclusion is set to 1 or yes, Y or affirmation in local language (or something unrecognized) the “yes” path is used.
• If template transclusion is set to 0 or no, N or refusal in local language the result is the empty string and the “no” path is used.

For a decade in source text various spellings for “yes” and “no” have been demanded, and quite often they were mixed up; e.g. nein, Nein, JA, j.

• Check by #ifeq: in template programming always triggered the wrong path.
• Since VE checkbox wrote 1 and 0 values all variants needed to be interpreted as intended, disregarding particular format of human editor or VE or customary requirements.

WRT T178560 that describes a wrong behaviour of the VE form (and is another issue):

A parameter L may be declared as type:boolean in TemplateData.

• The VE form shows a tic box like ☑ if any value for L was already present in template transclusion.
• The VE form shows a text input field if the template transclusion did not yet contain a L parameter assignment, even more on first insertion of template transclusion by means of VE.

The misbehaviour occurs only on missing assignment ahead.

The VE form behaviour and dealing with the old inventory collected during a decade is very confusing.

The traditional approach has been: {{#if: {{{someBoole|}}} | yes-path | no-path }}

• That means: If someBoole got any value, it has been considered as “yes”.
• Users were supposed to set |someBoole=Yes| but anything else worked, even No.
• Now VE users set a 0 which is anything and is also considered as “yes”.

In some cases it was implemented the last ten years:

• {{#ifeq: {{{someBoole|No}}} | Yes | yes-path | no-path }}
• Requiring exactly matching Yes, anything else means “no”.
• Now VE users set a 1 which is not Yes with the “no” effect.
• Could be made case insensitive by {{uc:}} etc. but does not permit Y and YES with the same meaning.

Conclusion:

• Any text neither 0 nor 1 should be regarded as 1 for type:boolean in TemplateData.
• An empty, whitespace-only or unassigned value should be regarded as 0.
• A checkbox shall be visible in VE form, no matter which value is present in current transclusion.

In T144155#3700119, @PerfektesChaos wrote:

The VE form behaviour and dealing with the old inventory collected during a decade is very confusing.

The traditional approach has been: {{#if: {{{someBoole|}}} | yes-path | no-path }}

• That means: If someBoole got any value, it has been considered as “yes”.
• Users were supposed to set |someBoole=Yes| but anything else worked, even No.
• Now VE users set a 0 which is anything and is also considered as “yes”.

If a template accepts "anything" to mean "Yes" and is documented with TemplateData as "boolean", then that is a mistake in the documentation. The meaning of "boolean" is strictly defined as "0", "1" or "". Always has been. This task is about creating an input widget in VisualEditor to make that type easier to use.

There are a few more special types like this for improved usability. But, there are also hundreds or thousands more special concepts invented on every wiki in every language. Most of these are all differnet and do not (currently) have native VisualEditor support. Nobody is being forced to use a special type. If you're not sure, use the default type of type=line which behaves the same as plain wikitext and means the user has to know what to do, ideally with the meaning explained in the description.

If you want to propose a new type to be added to TemplateData and VisualEditor for this "non-empty toggle", please file a separate task. However, note that it is expected that as part of this transition that templates may need to be updated to be more similar to each other. This makes them easier to maintain and easier to use in the long-term for everyone. It is fairly simple to support this and still also maintain compatibility with the older versions.

For example, one can add a new parameter that is strict, and keep old one compatibility. Another way is to separate the template entirely, with the new template taking more strict parameters, and the old template remain as simple wrapper, like so:

# Template:Oldname
{{Newthing
|someBool={{#if: {{{someBoole|}}} | 1 | 0 }}
}}

In T144155#3700119, @PerfektesChaos wrote:

In some cases it was implemented the last ten years:

• {{#ifeq: {{{someBoole|No}}} | Yes | yes-path | no-path }}
• Requiring exactly matching Yes, anything else means “no”.
• Now VE users set a 1 which is not Yes with the “no” effect.
• Could be made case insensitive by {{uc:}} etc. but does not permit Y and YES with the same meaning.

.. and this is exactly why it is not possible for one strict type to work with all existing templates. Or rather, the only strict type that works for everything is the generic type line where the user is required to know what to enter, just like with wikitext.

Note that if you're looking for a way to have localised or flexible limited options like "Yes" or "No" in a template, this is covered by the request in task T53375.

But as I mentioned, it is also possible to support strict boolean in existing templates without breaking compatibility. The question is how much priority and resources is available to support mulitple ways to achieve conceptually the same thing, and how much that helps improve or degrade the user experience, compare to the benefit of investing in updating templates instead.

Mentioned in https://meta.wikimedia.org/wiki/Talk:WMDE_Technical_Wishes/Suggested_values_for_template_parameters#if