Page MenuHomePhabricator

Add support for boolean parameter type
Open, LowPublic

Description

TemplateWizard can support customized inputs for different content types, to make it easier for the user to enter information and to prevent the user from entering inaccurate information in some cases (like with the datetime selector).

We're currently not doing anything special for the 'boolean' parameter type. It is defined as "a boolean value ('1' for true, '0' for false, '' for unknown)".

They should use a ButtonSelectWidget with Yes/No/Unknown (equating to 1/0/'') as options, e.g.:

(This ticket used to also cover multiline fields, but they've been moved to: T201378: Add multiline input fields for 'content' and 'unbalanced-wikitext' parameter types)

Event Timeline

Restricted Application added a project: Community-Tech. · View Herald TranscriptJul 30 2018, 6:54 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Samwilson updated the task description. (Show Details)Jul 30 2018, 6:55 AM

Change 449128 had a related patch set uploaded (by Samwilson; owner: Samwilson):
[mediawiki/extensions/TemplateWizard@master] Add 'content' type for parameters

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

Samwilson updated the task description. (Show Details)Jul 31 2018, 1:43 AM

Regarding the booleans, we could probably get rid of the 'unknown' if there's a default value, but in other cases it's conceivable that templates would be making a distinction between a parameter with no value and a parameter that's not present.

Niharika triaged this task as Low priority.Jul 31 2018, 2:45 AM
Niharika moved this task from Untriaged to To be estimated/discussed on the Community-Tech board.
Niharika added a subscriber: Niharika.

@Samwilson I think it'll be helpful to get screenshots of the multilineinput too. We can then run this by Carolyn to get her feedback.

Niharika renamed this task from Add missing parameter types: content and boolean to Add support for missing parameter types: content and boolean in TemplateWizard.Jul 31 2018, 2:52 AM
Niharika updated the task description. (Show Details)
Samwilson updated the task description. (Show Details)Jul 31 2018, 5:37 AM

Done; see description.

We could also choose to 'autosize' the textareas, so they get bigger the more text is entered (up to a maximum we specify).

Re T198921: All the input fields should have the same width, would we want the boolean field (whatever we end up choosing for it) to also be full width?

aezell added a subscriber: aezell.Jul 31 2018, 3:12 PM

As for width of the boolean, won't we need to be concerned about non-English languages fitting on a single line in the available width?

As for width of the boolean, won't we need to be concerned about non-English languages fitting on a single line in the available width?

What we can do (there are other places that do this type of thing) is request, in the qqq (the explanation for translators) to try and use a relatively short word for the translation. We do this a lot for cases like these, where the action is quick and small. It also makes sense when the words are relatively simple boolean ("true / false / none" etc) We also do this a lot for mobile designs, where the space for wording is already limited, so there's precedent.

Usually, the most "dangerously long" language tends to be German, but since the words are short ("ja" / "nicht" / "unbekannt" if my translation is right) I think it should be safe.

Worse case, if we see some language that are too long, we can relatively easily switch this toggle to be one-button-per-line, which would also work.

I think this is still better than having a free-text input that assumes the user knows to put "1", "0" or "".

I think this is safe enough, though, especially for such short action words, and if we emphasize "use short words" in the qqq.json.

aezell added a comment.Aug 2 2018, 5:25 PM

@Mooeypoo Thanks for the clarity on that. I'm glad we have some common solutions there.

cmadeo added a subscriber: cmadeo.Aug 2 2018, 7:43 PM

The screenshots in the ticket look reasonable to me. I'd agree with @Mooeypoo that using words over 1 / 0 / ' would be easier for most users to understand and preferred overall.

Samwilson renamed this task from Add support for missing parameter types: content and boolean in TemplateWizard to Add support for boolean parameter type.Aug 7 2018, 3:01 AM
Samwilson removed a project: Patch-For-Review.
Samwilson updated the task description. (Show Details)
Samwilson updated the task description. (Show Details)

I've created T201378, and moved stuff from here to there.

With the boolean 'unknown': could it be said that if there's a default value of 1 or 0 for a boolean parameter, then we could leave out the 'unkown'? It would look nicer in many cases. I know it doesn't quite cover it, because it is technically possible for a template author to make a distinction between empty when defining the default value. For example, a {{pet}} template might have a is_good parameter with a default of 0:

{{#ifeq: {{{is_good|}}} | 1 | Good dog! | {{#if: {{{is_good|cat}}} | Bad dog! | You're a cat. }} }}

If we can in some circumstances do away with the 'unknown', do we want to change to a checkbox for those ones?