Page MenuHomePhabricator

Template names are forced to lowercase, which can cause conflicts with other templates
Open, LowestPublic

Description

Part of our template title normalization was forcing all titles to lowercase, but wiki titles are case-sensitive. This means that a template "GPL" would have matched "gpl", when they may be different articles. The correct normalization is "ucfirst", making the first character uppercase but leaving the rest of the title unchanged. The impact of this change should be minimal, but the lowercase assumption is built into much of our code.

I noticed this as part of work for T228858. which is soft-blocked by this detail.

Event Timeline

awight created this task.Sep 9 2019, 12:14 PM
Restricted Application added a project: TCB-Team. · View Herald TranscriptSep 9 2019, 12:14 PM

Can you explain when exactly this is a problem?

The case-insensitive comparison was derived from CommonsHelper2, which does it the same way. The assumption is that:

  • It's very rare that two templates with the same name but different capitalization exist. If they do, it's either a mistake that needs to be/will be fixed, or a redirect.
  • I feel we should be defensive, especially when checking for forbidden templates and categories. If a file is marked with {{nOcOMMONS}}, I feel we should still block it, even if this template transclusion is technically broken.

Also, if we make the comparisons case-sensitive, all config pages need to be updated to include all redirects.

Can you explain when exactly this is a problem?

This will only cause a problem if article titles overlap, with differing case. I'm sure this is an extreme edge case, maybe never. Practically, it bothers me because we aren't tracking the correct title for these articles. When a redirect template isn't available, we've created a situation where the user might see configuration for Template:Nowcommons, and it will be difficult (and uncertain) to find that the correct page is Template:NowCommons.

The case-insensitive comparison was derived from CommonsHelper2, which does it the same way. The assumption is that:

  • It's very rare that two templates with the same name but different capitalization exist. If they do, it's either a mistake that needs to be/will be fixed, or a redirect.

I think this is correct, except that the redirect assumption seems fragile. There is *always* a redirect from a lowercase title to the correctly-cased title?

  • I feel we should be defensive, especially when checking for forbidden templates and categories. If a file is marked with {{nOcOMMONS}}, I feel we should still block it, even if this template transclusion is technically broken.

Defensive is good, and I'm okay with not making my proposed change unless we run into real scenarios where we over-zealously block an import due to templates with overlapping case, for example.

Also, if we make the comparisons case-sensitive, all config pages need to be updated to include all redirects.

No, I believe that the config pages only need to be updated to reflect the correct page title case. Redirects are transcluded as part of parsing, so the ParserOutput will include the resolved template names.


This task does feel mostly cosmetic. I was goaded into action by the thought of having to reimplement our defensive logic on the FileExporter side, it seemed like I was perpetuating a mistake.

awight triaged this task as Lowest priority.Sep 10 2019, 10:01 PM
awight updated the task description. (Show Details)Sep 13 2019, 6:59 AM