Talk:WMDE Technical Wishes/Suggested values for template parameters

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

Labels[edit]

As I noted in phab:T53375#5769182, it would be great if this feature could support labels. For example, in the language example, maybe the template expects a language code like en or hi, but the template user should still see English and Hindi, otherwise the WYSIWYG experience is kinda ruined. Are there any plans to implement this? —Tacsipacsi (talk) 22:14, 2 March 2021 (UTC)

Hi @Tacsipacsi:: we have considered doing this but came to the intermediate decision for not implementing this in the first version but make sure the implementation is done in a way, that this can be added later. It would however be very interesting to hear about more concrete examples where that might be useful, so that we can get a better estimate of how big the extra benefit would be. -- Michael Schönitzer (WMDE) (talk) 13:47, 12 March 2021 (UTC)
@Michael Schönitzer (WMDE): Apart from the one already noted on Phabricator, nothing comes to my mind, but I’ll keep an eye out and make sure to note here any template I find interesting. —Tacsipacsi (talk) 15:21, 30 March 2021 (UTC)
@Michael Schönitzer (WMDE): Another example is {{clear}}—the CSS property values (the actual parameter values) are English-only, but it would be useful if the UI would let a German editor choose between “links”, “rechts” and “beide” instead of “left”, “right” and “both”. —Tacsipacsi (talk) 18:51, 5 May 2021 (UTC)

Marking list as exhaustive[edit]

There’s a sentence Furthermore, in some cases only certain values are considered valid, but no details on it. How does one differentiate non-exhaustive lists (e.g. list of languages, where the user may insert other smaller languages) and exhaustive lists (e.g. list of module entry points, where a value not on the list would cause a script error)? —Tacsipacsi (talk) 22:24, 2 March 2021 (UTC)

This might be a misunderstanding, sorry. There won't be any change that forbids using custom values, this was meant that the feature might be especially useful for parameters for which only certain values are appropriate. The community is of course up to decide where to use the feature. There won't be any feature technically limiting input. -- Michael Schönitzer (WMDE) (talk) 13:47, 12 March 2021 (UTC)
@Michael Schönitzer (WMDE): I still don’t understand your intentions. If only certain values are appropriate, then why not limit the input to them? (If you worry about what to do with templates that already contain values not on the list, for example inserted using the wikitext editor—this problem already exists, for example numeric parameters containing non-numeric values, so clients should already have ways to handle it.) Of course, this feature is useful also when the list contains only suggestions and other values are also appropriate, this is why there should be a way to differentiate the two cases in TemplateData JSON. —Tacsipacsi (talk) 15:21, 30 March 2021 (UTC)
We decided against making the list exhaustive (in general), since our research suggests that for many cases that might seem like an exhaustive list there end up to be some (rare) edge-cases where a different value makes sense. The other input types, that the template-form of VE has, are also built in a way that they don't force the input type. There is of course the possibility to late add a further option for this, if there is notable demand by users. Michael Schönitzer (WMDE) (talk) 23:39, 30 March 2021 (UTC)
@Michael Schönitzer (WMDE): - we should not confuse visual editor with templatedata. you are not "making the list exhaustive", but the template might do it anyway: when a parameter is only used for a #switch, which has no #default, the list _is_ exhaustive (since any other value is equivalent to not supplying the parameter at all), regardless of what you decide to do or not do. the deficiency here is that the current definition does not allow templatedata to convey this fact. visual editor may well ignore this, but templatedata is used for more than just VE, and other tools that use it to glean information about the template _do_ want to know if the list is "suggested values", or is it "permissible values" (tbh, the latter is much more common case than the former). such tools are, e.g., wikicode template wizards, and validation tools ("lint" like) which detect incorrectly filled templates (use of non-existing params, omitting "required" params, non-numeric values for params typed "number", etc.). linting tools should ignore the value when the list is "non exhaustive", and verify correct values when the list is exhaustive, and wizards should provide "drop down combo box" for non-exhaustiv list, and simple "select" for exhaustive (allowing the editor to enter values we know the template will ignore it is not a good practice, like supplying someone a block of ice for note taking). this is not a pipe dream or some far fetched hypothesis: such tools are in use on hewiki, both wikicode wizard (not to be conflated with the "template wizard" extension, which is a crippled and barely usable tool, due to its inability to assist in editing templates already in the source code), and a comprehensive template-parameter validation system. the "suggestedvalues" feature of templatedata is something we asked for for years now, and it's disappointing to see this datum (i.e., whether values not in the list are permitted by the template) missing.
visual editor is of course free to ignore this piece of information, but tempaltedata should provide it. peace - קיפודנחש (talk) 23:27, 22 April 2021 (UTC)
Thank you very much, for the explanation, I now get why this is a valuable feature. I will forward your explanation to our product manager, but can't promise anything. Michael Schönitzer (WMDE) (talk) 12:00, 5 May 2021 (UTC)

Use for langages[edit]

Hello,

That sounds great, thanks for this feature. I think I will try it to suggest a list of language in a template I just started. That said, I think it would be me relevant to have a type "langage", as I guess it's a rather common use case. Moreover, having an integrated type could allow better internationalization of templates. What is your opinion? Psychoslave (talk) 04:55, 23 April 2021 (UTC)

Hi, that sounds like a useful feature request. Implementing this would however be a separate project since it would require quite a few additional resources of engineering, UX, cross-wiki-communication and research, and it's rather unlikely that our team will be able to do this project as part of our current two-years plan. However, I created a task, so that it is in the backlog of suggested improvements for template data and visual editor: task T282238. – Michael Schönitzer (WMDE) (talk) 18:29, 11 May 2021 (UTC)

if[edit]

Often templates have this {{#if: {{{1|}}} | | [[Category:...]] }}. Parameter "1" is usually given as a boolean and in the example "yes". Since specifying a boolean type does not affect anything, would it be better in such a situation now to specify the parameter "1" as a string? Then the user can immediately select "yes" from the list ... Sunpriat (talk) 17:26, 23 April 2021 (UTC)

If you set the type to boolean and add autovalue: 0 to template data the parameter will be shown as a checkbox that can be toggled on and off. Does that solve your use case? Michael Schönitzer (WMDE) (talk) 11:43, 5 May 2021 (UTC)
@Michael Schönitzer (WMDE): No, it would just worsen things, as |1=0 is also truthy ({{#if:0|yes|no}} produces yes). This is why a binary (empty/not empty) boolean type—in addition to the current ternary (empty/on/off) one—has been requested for a long time (I could not find its Phabricator ticket, although I’m pretty sure it has one). —Tacsipacsi (talk) 19:00, 5 May 2021 (UTC)
An interesting option, but it will require changing many pages to ifeq. And usually an empty parameter in VE is not written into the wikitext, and here it is more difficult to find the delete button for this parameter with a checkbox, it will more often remain in the wikitext with | 0, so there will be more uses (disabled the parameter but forgot to delete) the parameter even when it is not needed. The drop-down list is somehow easier - you can intuitively make the field empty and it will disappear from wikitext. Sunpriat (talk) 14:54, 9 May 2021 (UTC)
I don’t consider changing loads of pages an option. If there’s a well-established pattern, the software (TemplateData) should adapt to the already-existing pages, not the other way round. —Tacsipacsi (talk) 23:00, 9 May 2021 (UTC)
Yes, but the situation is like they don't want to look at our use. For the boolean type, it seems that only two options are offered: either such a yes-no or yes-no-unknown phab:T200664 (in which it is also unclear what we require to indicate unknown and not no). For our use of yes-empty, we probably have to choose a different type. Sunpriat (talk) 16:21, 10 May 2021 (UTC)
Thank you for the insides! I looked at phabricator and found two tickets that seem to be at least very close to this issue: task T176009 and task T144155 Do you consider these two to cover the hole problem? Implementing this would be a separate project next to suggested values. We would love to implement further projects from the long list of technical wishes, but our team currently cannot commit to any further projects since our resources are limited. Michael Schönitzer (WMDE) (talk) 16:11, 10 May 2021 (UTC)
Yes, phab:T144155#2631528 describes a similar use of if. But it looks like the implementation of this task may take several more years. Ok, it looks like for #if I can use the suggested and wait for other options for the #if if there will be progress in that task. Sunpriat (talk) 16:57, 10 May 2021 (UTC)
What wish list do you mention? Is there anything about other date formats besides ISO that many people are not familiar with (not natural in daily use)? Sunpriat (talk) 17:08, 10 May 2021 (UTC)
Based on a survey in German Wikipedia, our team committed to work for two years on improvements for working with templates. We investigated what pain points exists and where improvements would be desirable. We then estimated their impact and effort and based on this choose the projects where we believe that the impact-effort-ratio is best while making sure that there is some improvement for everyone. Should we manage to fulfill them faster than estimated, we would of course pick further projects. The list of projects that we committed to implementing can be found here. A summary of the most often mentioned pain points found in our research can be found here. Michael Schönitzer (WMDE) (talk) 18:40, 11 May 2021 (UTC)