Page MenuHomePhabricator

Parameter names in templates should be case-insensitive
Closed, DeclinedPublicFeature

Description

Author: splash.wiki

Description:
Exactly as it says on the tin for which I can't find a current bug.

So that there is no need to code either conditional templates or entirely
separate templates along with all the associated drudge work to go from one
caseing to another *and* to avoid the many inconsistencies we have at present.

{{template|Par1=val1|Par2=val2...}}

should be exactly the same as far as the editor is concerned as

{{template|par1=val1|par2=val2...}}}

At present, if the templates is coded as either of these, it will fail if the
editor uses the other caseing.


Version: 1.16.x
Severity: enhancement

ignoreCase option

Not a bug but a feature request, if overall doable.

It would be highly useful to have a RegExp i (ignore case) equivalent for {{{param}}}. So instead of current {{{paramName|defaultValue}}} to have {{{paramName|defaultValue|ignoreCase}}}

The situation of say Profession=something or profession=something being sent randomly or different in different templates is rather often and we have to deal with it in any case but so far for "magic words" in an awkward way like {{#if: {{{Profession|}}}{{{profession|}}} | argument provided | argument not provided }}

{{#if: {{{profession||i}}} | argument provided | argument not provided }} would be much leaner, reliable and w/o extra value check on server.

Details

Reference
bz4964

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 9:04 PM
bzimport set Reference to bz4964.
bzimport added a subscriber: Unknown Object (MLST).

stux wrote:

This makes sense, since I've run into several improperly used template, but doing so will likely break other templates where users may have (inappropriately) taken advantage of case sensitivity:

{{template|par1=val1|PAR1=val2...}}

I think parameter case sensitivity should be treated as a "template standard" and so template "programmers" (i.e. users) should be informed of this issue (i.e. the information widely disseminated through as many channels as possible).

ayg wrote:

This might or might not have been a good idea to start with, but by now there's way too much legacy content. Also, case-sensitivity of template parameters matches case-sensitivity of the template names themselves. Given the relatively marginal benefit of allowing case-insensitive parameters to begin with (is it really hard to always use lowercase?), I would suggest WONTFIX.

I was considering doing this, but with a config variable to enable it (disabled by default), but if people think that's excessive, I'm not especially attached to the idea.

ayg wrote:

I don't think a config option would be useful here. It would potentially break copying content between wikis, e.g., Wikipedia.

(In reply to comment #4)

I don't think a config option would be useful here. It would potentially break
copying content between wikis, e.g., Wikipedia.

I agree completely. This should either be fixed or not fixed, introducing a variable here would just create incompatibilities between wikis and make Import/Export unreliable.

(In reply to comment #2)

This might or might not have been a good idea to start with, but by now there's
way too much legacy content. Also, case-sensitivity of template parameters
matches case-sensitivity of the template names themselves. Given the
relatively marginal benefit of allowing case-insensitive parameters to begin
with (is it really hard to always use lowercase?), I would suggest WONTFIX.

I'm inclined to agree here. This seems like it would've been a great idea when it was being designed, but it's too late now.

Iniquity subscribed.

I think we need to discuss this anew.

I think we need to discuss this anew.

Why?

It cannot really be my decision, but I'd decline it.

Evidently, this has been requested for many years, and people are still asking for it. However, it seems to me that the problems that such a change in templates syntax after so many years outweigh the possible benefits.

The problems currently caused by case-sensitivity of templates are minor in any case. A better way to address them is to write good TemplateData. This will help people use less manual and error-prone source editing and more visual editing, and it will also help wikis implement linting tools, such as https://he.wikipedia.org/wiki/Module:ParamValidator in the Hebrew Wikipedia.

Pppery subscribed.

Removing good first task project since this is evidently not "non-controversial", as required by bullet point 2 in the description.

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:02 AM
Aklapper removed a subscriber: wikibugs-l-list.

Since this was reopened it has received no constructive activity and several arguments against it. There's even more legacy code now that there was in 2009. Re-declining.