Page MenuHomePhabricator

Create dedicated input methods for "boolean" transclusion parameters
Open, LowPublic8 Story Points

Description

When a template defines a boolean value (like url = yes) to would be useful to have a switch button instead of a field with a doom instruction like "fill only if the answer is 'no'".

Event Timeline

Restricted Application added a project: VisualEditor. · View Herald TranscriptAug 29 2016, 8:31 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Ltrlg added a subscriber: Ltrlg.Sep 1 2016, 5:01 PM
Krinkle renamed this task from TemplateData: add a switch for boolean values to Create dedicated input methods for "boolean" transclusion parameters.Sep 13 2016, 1:56 AM

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.

Krinkle moved this task from Backlog to External on the TemplateData board.Sep 13 2016, 2:01 AM

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?

Jdforrester-WMF triaged this task as Low priority.Oct 4 2016, 7:29 PM
Jdforrester-WMF moved this task from To Triage to TR1: Releases on the VisualEditor board.
Jdforrester-WMF set the point value for this task to 8.Nov 15 2016, 6:17 PM
Mvolz added a subscriber: Mvolz.

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

Mvolz added a comment.Sep 7 2017, 10:33 AM

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.

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.

Mvolz added a comment.EditedSep 7 2017, 3:01 PM

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?

0yesouivrai
1nononfaux

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.

Mvolz added a comment.Sep 7 2017, 3:26 PM

Is possible to define some aliases on each wiki?

0yesouivrai
1nononfaux

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."
  1. The template data displays this means the value can be 0 or 1.
  1. We implement your suggestion.
  1. Now the user sees you can set the value to 0, 1, oui, non, vrai, or faux
  1. 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.

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.
Magol added a subscriber: Magol.Dec 28 2017, 11:09 AM