Template talk:Fix/Archive 1

Archive 1

Deprecated

Resolved

 – Moot.

This template, while clever, is complex, fails to support date parameters properly, uses old cats that have long since gone, and is onl used by one or at most two articles.

I have therefore deprecated it.

Rich Farmbrough, 17:21 2 April 2007 (GMT).

It seems to have come back, and is being worked on. Carcharoth 14:59, 14 June 2007 (UTC)

Indeed! In its overhauled, repurposed form, it is the basis for all (well, not quite all yet) of the inline templates. — SMcCandlish [talk] [cont] ‹(-¿-)› 17:42, 25 July 2007 (UTC)

Dox fix

Resolved

 – Requested edit performed.

{{Editprotected}}
Needs its documentation moved to a /doc file, with the proper template documentation templates, as with Template:Verify credibility and Template:Verify credibility/doc, so that [[Category:Inline templates]] can be added, and the documentation otherwise edited as needed without having to use pointless {{Editprotected}}s. — SMcCandlish [talk] [cont] ‹(-¿-)› 17:42, 25 July 2007 (UTC)

Y Done - I moved the template documentation to an unprotected /doc subpage. Nihiltres^(t.l) 18:59, 25 July 2007 (UTC)

Mouseover popup tooltip failing

It's been reported at Template talk:Vague that the mouseover code is not working. This can be confirmed with the example in that template's documentation. — SMcCandlish [talk] [cont] ‹(-¿-)› 19:47, 26 July 2007 (UTC)

Responded at that talk page. --CBD 00:06, 27 July 2007 (UTC)

Since this behavior is inherited by any template using this meta-template, I think the issue should be discussed here. Devourer09 (t·c) 21:38, 13 October 2010 (UTC)

The title paraneter needs to be put in as the title parameter of the link. There's no point putting it anywhere else. Currently the link has the title set to things like "Template:citation needed". Dmcq (talk) 21:51, 30 June 2011 (UTC)

See discussion Mouseover fix below. — Bility (talk) 15:52, 5 July 2011 (UTC)

Catchall category

The catchall category "all pages needing cleanup" is not really correct.

In the worst case there can be three different names for the categories:

1. A catchall, typically "All pages needing...
2. An undated category typically "Pages needing....
3. A set of dated cats, typically ... from <date>" or ... since <date>"

Having said this one purpose of the catchall was to allow Dragons Flight Cat tracker to keep track, since this is no longer working, perhaps these cats need to go anyway. Rich Farmbrough, 14:23 2 October 2007 (GMT).

From vs since

I have added a "from" parameter since some dated cats use "from" and other "since". (See User:Rich_Farmbrough/list_of_dated_categories.) Ideally they should all use the same, but changing over is quite a task. Rich Farmbrough, 12:15 10 December 2007 (GMT).

Resolved

 – After some considerable time and work.

Rich Farmbrough, 05:11, 5 November 2009 (UTC).

Spaced out?

I just discovered something odd about this template. Not really a bug, but more like an unintentional feature:

When templates like {{fact}} that are based on this template are placed after a word and there is a space between them in the page code, then that space disappears in the rendered text. But that only happens when in articles, not in the other namespaces. It happens in all browsers since the space is missing in the XHTML rendered by MediaWiki.

So this code on this page:

Word {{fix|text=fix}} word {{fix|text=fix}} word {{fix|text=fix}}

As expected it renders with a space after the word on this talk page:

Word word word

But if you try the same code in an article it would look like this:

Word word word

It took me some testing to figure out what is going on. It is the category tags that are placed in front of the text that causes it. That is, MediaWiki strips away any spaces that come before category tags. And since this template only uses those category tags when on article pages, then it is only visible there.

This is not really a problem, its probably a good thing for this template. But since I code templates it triggered my curiosity. And I wanted to share my findings here since perhaps others will wonder about this in the future.

--David Göthberg (talk) 22:04, 22 March 2008 (UTC)

This is because the Categories are inserted BEFORE the [fix], and categories tend to eat whitespace around them. (Actually, this is why they were moved from the back to the front, since loosing whitespace AFTER [fix] is much more annoying. The reason why you are only seeing this in articles, is because only in the mainspace, these categories are included by the template. --TheDJ (talk • contribs) 20:21, 20 June 2008 (UTC)

Italics breaks linewrapping

This is odd. If you have a template that uses fix is placed in italics, it breaks line wrapping:

foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo

foo  foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo

foo  foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo

foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo

--— Gadget850 (Ed) ^talk - 13:26, 2 May 2008 (UTC)

This edit seems to fix the problem in a local copy I made in my sandbox:

[obsolete example removed now that the bug is fixed]

It looks like the wikimarkup italics inside the template were confusing the parser, and then HTML Tidy ended up putting the rest of the line inside the template's nowrap. Anomie⚔ 23:40, 2 May 2008 (UTC)

{{editprotected}}

Any reason not to make this change to fix this bug? It's been awaiting discussion for over a month. Anomie⚔ 01:24, 18 June 2008 (UTC)

Simple and effective solution to this problem. Lets hope an admin fixes it soon. --TheDJ (talk • contribs) 11:39, 18 June 2008 (UTC)

I've now reviewed, and applied, your fix. It seems to work OK. Please let me know if it causes any problems. -- The Anome (talk) 11:41, 18 June 2008 (UTC)

Fix at end of paragraph

When a fix template such as {{fact}} is placed at the end of a paragraph, it kills paragraph breaks. Normally I would give an example here, or copy the affected text to illustrate the problem, but the problem does not occur when the text is copied.

Examples:

• Belmont Stakes: Under Broadcasting History, "CBS Sports 1960-1985[citation needed]" is the end of a paragraph.

• Copa del Rey: Under controversies, "However LFP and RFEF official statistics do not include this as an Athletic win.[citation needed]" is the end of a paragraph.

--—— Gadget850 (Ed) ^talk - 14:05, 27 May 2008 (UTC)

See also Template talk:fact#Broken results when used at the end of a paragraph in article space with a wikilink/image at the start of the next paragraph --TheDJ (talk • contribs) 20:18, 20 June 2008 (UTC)

How about another field

I'd have to guess the predominant occurrence of this kludge is in {{fact}}. Working technical topics, I'm constantly running into fact tags that leave me guessing what the hanger wanted cited. Lots of times I suspect this is just experience and knowing the subjects context, and the tag hanger is questioning what the psyche types call "Crystallized Knowledge"... basis stuff most everyone that knows something about a field knows. In such cases, t'would be truly good to have a tag hangers reasoning or objection (returning to {fact}). This seems best accomplished by using an unnamed default parameter, specifically {{{1|}}} to define a field I'm requesting here... a popup field that invokes {{r-phrase}} inside an #if: test.

1. Calling the param "popup", {{#if:{{{popup|}}}|{{r-phrase{{{popup}}}}} were here in this template, it will allow:
   
   
2. {{#if:{{{1|}}}|popup={{{1}}}}} in the call to here from in {{fact}}
   
   
3. Thus satisfying the cultural trend I wrote into the help in this edit, and one long overdue imho. (see the last few numbered notes in the green part of the page, and the instructions and examples above that).
   
   

Anything simple that promotes better communication and understanding between editors saves someone time, usually many someone's, is a good idea in my book.

• Two if's and one named param is pretty simple. Any takers on implementing those changes? // FrankB 09:19, 27 June 2008 (UTC)

Implementing category for transclusions of this template with an invalid date parameter set

After adding this code on various templates ({{fact}}, {{expand}}, etc) and after prompting from Dispenser, I've added the code to the template. I tested it in my userspace (see Base1, Base2, Base3 if interested) and hopefully covered all of the checks and parameters needed. The code will detect whether the category used when a user enters a date in the date parameter when they trasclude one of the template derivatives. If it doesn't exist then the code will place the article in Category:Articles with invalid date parameter in template. That way, if a user types "date=Feb 2008" instead of "date=February 2008", or if a category gets deleted with a few articles remaining, it ensures that the articles don't fall through the gaps as we progress through the backlog. Harryboyles 15:46, 28 June 2008 (UTC)

I'm not sure if this would be useful but we could use the {{{date}}} parameter as the sort key in the category as to cluster invalid dates together. Although one problem is it wont work with multiple templates. — Dispenser 16:26, 28 June 2008 (UTC)

I don't think it would be worth the effort for the servers to update all the transclusions. There are only up to 20 pages on average per day, and it's easy enough to fix the articles. I don't think there is enough of a benefit to make the change. Harryboyles 04:22, 3 July 2008 (UTC)

Unbalanced {{#if:

{{editprotected}}

This edit has broken the template by adding a {{#if: without a corresponding }}. I think the two missing braces should go after Category:Articles with invalid date parameter in template. —ras52 (talk) 15:49, 28 June 2008 (UTC)

Worked it out myself before reading this comment. Thanks for pointing it out though. Harryboyles 15:56, 28 June 2008 (UTC)

Needs comment/reason parameter

The one thing that all the {{Clarifyme}}, {{Dubious}}, etc. templates lack is a comment field. What is typically done (when people bother to explain themselves, which is too rarely) is something like this:

• ...according to Johnson.{{Clarifyme}}<!--WHICH Johnson, Harry Johnson or P.S. Johnson?-->

What of course is even more common is:

• ...according to Johnson.{{Clarifyme}}

because adding the HTML comment is both an extra step, and requires basic HTML skills, which not all Wiki editors have.

How this should really work is:

• ...according to Johnson.{{Clarifyme|comment=WHICH Johnson, Harry Johnson or P.S. Johnson?}}

or

• ...according to Johnson.{{Clarifyme|reason=WHICH Johnson, Harry Johnson or P.S. Johnson?}}

There are numerous non-inline templates with "comment" or "reason" fields from which code can probably simply be copy-pasted to make this work (though I think it would be wise to make "comment" and "reason" both work synonymously; different templates use one or the other, and there is no reason to make editors try to guess which one works with inline templates.

After it does work, please notify WT:INLINE so that project's members can enable this parameter in all of the inline templates. — SMcCandlish [talk] [cont] ‹(-¿-)› 09:05, 16 August 2008 (UTC)

For that matter, adding any comment is an extra step that the lazy will leave out. How would you have this comment appear in the page? Anomie⚔ 13:23, 16 August 2008 (UTC)

I don't care if it does at all; the entire point is to have a field for putting comments that are now being done in HTML comments into the template itself, for tidiness and for not hurting the brains of wikicode editors with poor HTML skills. I guess it could be in a mouseover tooltip (and would necessarily be incompatible with the separate feature for that), but it really doesn't matter to me. Another option would be to have <sup>?</sup> at end of template if this parameter is used, and have hovering over the "?" pop up a different tool tip. Whatever. — SMcCandlish [talk] [cont] ‹(-¿-)› 20:25, 21 August 2008 (UTC)

Well, if it doesn't need to be displayed at all... you can do that now. Your 'Clarifyme' examples above would work just fine with no changes whatsoever to any of the templates. Passing a non-existant parameter to a template does nothing, so they are effectively 'comments'. At that, since there aren't any numbered parameters on this template, {{Clarifyme|WHICH Johnson, Harry Johnson or P.S. Johnson?}} works too. --CBD 10:45, 22 August 2008 (UTC)

It'll need to be added to the documentation, then. Anyone else care if this actually displays in some manner other than in the source? — SMcCandlish [talk] [cont] ‹(-¿-)› 22:50, 22 August 2008 (UTC)

I would prefer the parameter to be called "reason" becasue SmackBot is already coded to expect a possible "reason" parameter in these templates. Rich Farmbrough, 21:24 6 February 2009 (UTC).

mouseover still not working

Unresolved

 – This is still broken a year and a half later

Even when I use the {{fix}} tag directly (instead of another template that transcludes {{fix}},) the mouseover doesn't work. 69.140.152.55 (talk) 22:17, 19 August 2008 (UTC)

Do you get tooltips for other links on Wikipedia? The tooltip is working on all cases I checked so this may be an issue with your browser or some other configuration problem. --CBD 10:48, 22 August 2008 (UTC)

It does not appear to work in Firefox 3.x under Windows Vista, for one (i.e., probably one of the top-five most common browser/OS configurations in the entire world). Cannot answer "other links" question without an example to try. Most templates here are not using tootlips. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 16:33, 27 January 2010 (UTC)

Longstanding spacing problem

Resolved

 – Fixed.

{{editprotected}}

This has been reported on various Fix-derived templates' talk pages, but really needs to be fixed here.

Needs a space between text value and both the pre-text and post-text parameters' value when either are used. See this example to see why: {{clarifyme|pre-text=FOO|post-text=BAR}} renders as .

— SMcCandlish [talk] [cont] ‹(-¿-)› 22:52, 22 August 2008 (UTC)

 Done. --Philosopher ^{Let us reason together.} 02:33, 23 August 2008 (UTC)

Was it supposed to be implemented even when pre- or post- text aren't being used? It makes look rather odd now as it is. (NB, I don't know about the problem at hand, so it may be completely necessary, in which case that's fine.) AllynJ (talk | contribs) 05:50, 23 August 2008 (UTC)

Yeah, I just came here because it looked a bit weird. Tombomp (talk/contribs) 09:47, 23 August 2008 (UTC)

{{Editprotected}}

No, it shouldn't have the space unless the parameter in question is actually used; the space is in the wrong place... I've posted another editprotected to fix this (it will probably have to be done with   since the template syntax "eats" plain whitespace). The spaces need to be inside the code that is activated when these parameters are used. — SMcCandlish [talk] [cont] ‹(-¿-)› 10:14, 23 August 2008 (UTC)

 Fixed Happy‑melon 11:41, 23 August 2008 (UTC)

Rationale for pre-text parameter

What is the rationale for the pre-text parameter? I'm having a hard time thinking of a legit use for that, and can think of a lot of dumb misuses for it. — SMcCandlish [talk] [cont] ‹(-¿-)› 22:53, 22 August 2008 (UTC)

The parameter was included to accommodate existing inline templates which had text prior to the link. {{Nonspecific}} is one example. --CBD 15:39, 25 August 2008 (UTC)

Strikes me as something that can be AWB'd out of existence, and rightly so... — SMcCandlish [talk] [cont] ‹(-¿-)› 07:59, 26 August 2008 (UTC)

Accessdate formatting

Resolved

 – A mistake; ignore.

[This discussion was moved here from multiple talk pages of templates derived from {{Fix}}, since the issue cannot be resolved there.

Can the templates be fixed so that they allow the form "Retrieved on January 1, 2008" as an alternative to "Retrieved on 2008-01-01"? If I indicate the article date as June 1, 2007, for consistency, I prefer to use the same date style for the accessdate: "Retrieved on January 1, 2008" as opposed to "Retrieved on 2008-01-01". Also, I would prefer it if wikilinking the accessdates was optional (requiring the use of brackets). Thanks. --Phenylalanine (talk) 06:07, 26 August 2008 (UTC)

I think this has been moved to the wrong place. While this template does have a "date" parameter, that parameter is intended to be a month name and year which is used as entered to construct the name of a category such as Category:Articles with unsourced statements since August 2008 and to construct the title parameter of a span. This sounds more like it wants to be on the talk page of one of the citation templates. Anomie⚔ 10:39, 26 August 2008 (UTC)

Can someone fix this? Thanks. --Phenylalanine (talk) 23:25, 26 August 2008 (UTC)

Will respond at Template talk:Cite news. The various 'cite' templates are each independently (though redundantly) coded. None of them call this 'fix' template. --CBD 10:03, 27 August 2008 (UTC)

My bad; I confused myself between two different conversations about two different sets of templates, while I was talking on the phone. D'oh. — SMcCandlish [talk] [cont] ‹(-¿-)› 15:48, 27 August 2008 (UTC)

Redundant coding

{{editprotected}} Please sync with the sandbox. This removes a redundant <span> and does not have a visible effect on the template. TIA. —Ms2ger (talk) 17:56, 6 May 2009 (UTC)

 {{Fix}} has been fixed. — Martin (MSGJ · talk) 18:46, 6 May 2009 (UTC)

Use in mainspace

The template should never be used directly in mainspace - only through its use in other templates. Is there a way to categorise uses in mainspace? - Jarry1250 ^{(t, c)} 15:55, 14 May 2009 (UTC)

There is a trick for putting "do not subst" into templates. I guess that could be invoked. Rich Farmbrough, 20:47 23 May 2009 (UTC).

Nbsp?

{{editprotected}} When {{fact}} is used, for example, it adds the following annoying hover-text:

title="This claim needs references to reliable sources from May 2009"

However one feels about this hidden message, the non-breaking space is useless in this context. Moreover it conflicts with a script I use to highlight and distinguish nbsps in the actual content (a select few of which serve a purpose) from regular ones.

Please change the non-breaking space to a regular space:

title="{{{title|}}}{{#if:{{{date|}}}| from {{{date}}}}}"

to

title="{{{title|}}}{{#if:{{{date|}}}|<nowiki/> from {{{date}}}}}"

The null tag would establish the edge of the parser-function input (avoid trimming it) without needing to use an encoded space of any kind. — CharlotteWebb 23:55, 4 July 2009 (UTC)

 Done Hersfold ^(t/a/c) 02:38, 5 July 2009 (UTC)

New check for valid date

{{editprotected}} I thought of a new way to check for a valid date instead of the ifexist parser function which can fail if the category for the month simply hasn't been created yet. I'm pretty sure this would work but would like confirmation. We can use a #time to check if the {{{date}}} parameter is valid like this: {{#ifeq: {{{date}}}|{{#time: F Y|{{{date}}} }}|(if date is valid)|(if date is not valid)}}. If the date is in the standard Month Year format it will pass and otherwise it will fail. --Yarnalgo _{talk to me} 05:00, 31 July 2009 (UTC)

After reading the above discussion (with a really long name) #Implementing category for transclusions of this template with an invalid date parameter set, it might just be easier to have {{#time: F Y|{{{date}}}}} and then use #iferror to send it to the invalid date category. --Yarnalgo _{talk to me} 05:09, 31 July 2009 (UTC)

This sounds like a good idea, but it might be worth getting some more views here beforehand. My concern is: if the category doesn't exist, isn't that something that we would want to draw attention to? Otherwise the people going through the backlogs might not notice it. — Martin (MSGJ · talk) 08:37, 31 July 2009 (UTC)

Yes this is deliberate. What happens is that the cat gets deleted, and then an article or worse, a navbox, gets reverted and a bunch of articles are in non-existent cats. We could of course supress that but again it's the principle that it's better to see - and I can tell you I have spent a lot of time hunting through articles for hidden maintenance tag dating problems. Rich Farmbrough, 02:49, 4 October 2009 (UTC).

Fix category breakage

{{editprotected}} There is now a bug where a {{fix}}-using template at the end of a paragraph where the next paragraph starts with a wikilink or image loses the paragraph break in mainspace. Compare the HTML output in this (main namespace, broken) versus this (non-main namespace, correct). The cause is that the MediaWiki software eats linebreaks after category links at the end of a paragraph, as discussed here a few years ago. This edit seems to have caused the problem this time, as it moved the categories to the end of the output text.

Please make this edit to fix it. It simply moves the categories to before the output text rather than after, so they are no longer at the end of the paragraph. It will still cause problems if |text= is not specified in some use of this template, but is there ever a reason for that to happen? Anomie⚔ 17:36, 17 July 2010 (UTC)

Done. Ucucha 17:44, 17 July 2010 (UTC)

Thanks! Anomie⚔ 17:50, 17 July 2010 (UTC)

Detection for substituted templates

There are a few {{editprotected}} requests to add the following code

{{#ifeq:{{NAMESPACE}}|{{<includeonly>subst:</includeonly>NAMESPACE}}|<includeonly>[[Category:Pages with incorrectly substituted templates]]</includeonly>|}}

to templates which use this meta-template. I thought it might make sense to centralise the code in a similar way to how {{WPBM}} manages this. Then, if it was desired to change this category, or add some visual warning, it could be achieved with one edit rather than many. — Martin (MSGJ · talk) 12:39, 4 February 2011 (UTC)

To be clearer I am proposing that we add some code like the following to each template that uses {{fix}}

 |substcheck=<includeonly>{{subst:</includeonly><includeonly>substcheck}}</includeonly>

and then put some code in {{fix}} which adds the required tracking category. — Martin (MSGJ · talk) 16:02, 4 February 2011 (UTC)

This makes my head hurt and seems a little complicated. I'm not sure how/if this would work... Maybe it's just me, though. --- c y m r u . l a s s ^{(talk me, stalk me)} 01:45, 5 February 2011 (UTC)

Well, please try substituting {{dubious}} and/or {{verify source}} and check it's working. — Martin (MSGJ · talk) 18:37, 6 February 2011 (UTC)

Question: should we include a visible message such as when these templates are substituted? — Martin (MSGJ · talk) 18:46, 6 February 2011 (UTC)

I don't think so... I think it's enough to have the category. But perhaps a uw notice? (Not a warning, mind you, but just one of those single issue warnings.)

Ohh and you're a genius. It works! --- c y m r u . l a s s ^{(talk me, stalk me)} 20:00, 6 February 2011 (UTC)

Dated categories and formatnum

{{editprotected}} Per discussion at Template talk:Infobox settlement#Dated maintenance category issue, could the date parameter in this template be formatted with {{formatnum: }}? Currently, adding an inline, dated maintenance template to an infobox field which uses {{formatnum: }} will result in a malformed dated maintenance category—see the article Mombasa for an example. Thank you, -- Black Falcon ^(talk) 19:32, 20 March 2011 (UTC)

Don't think that is going to work. I'll reply over there to keep the discussion together. — Martin (MSGJ · talk) 09:22, 21 March 2011 (UTC)

Actually, I was suggesting that you want to reverse format it. For example, I would have thought that if {{formatnum:August 200,9|R}} produces August 2009, then a {{formatnum:{{{date|}}}|R}} would do the trick. However, there may be some other bug I am missing? Plastikspork _―Œ^(talk) 05:17, 24 March 2011 (UTC)

What you're missing is that {{formatnum:{{formatnum:August 2009|R}}}} (the inner formatnum with the 'R' coming from your proposed edit here, and the outer from the infobox) produces August 2,009. Anomie⚔ 10:41, 24 March 2011 (UTC)

Makes sense. Thanks! Plastikspork _―Œ^(talk) 01:57, 28 March 2011 (UTC)

Mouseover fix

The broken mouseover (|title) feature of the template has been an issue for quite a while. A recent discussion (Wikipedia:Village_pump_(technical)#Template:Fix_title_feature) brought a solution from User:Bility, which can be seen in the Template:Fix/sandbox. As Bility said the fix involves "building a full URL [where] you can specify the title in a span around it and it will act as expected. The only difference is the slightly lighter blue of an external link (on Monobook anyway) and I don't think it usually shows up in Special:WhatLinksHere."

So is this worth implementing for the template? Or because it changes things slightly, for a heavily used template, should we perhaps create a separate version of the template? That might be appropriate if most templates relying on Fix don't use the |title parameter anyway. (One that does, which prompted this discussion, is {{Vague}}.) Thoughts? Rd232 ^talk 22:59, 9 May 2011 (UTC)

Alternatively you could use an image to handle linking and the tooltip. — Bility (talk) 23:41, 9 May 2011 (UTC)

I quite like the icon. Could we get a version in the sandbox for people to look at? — Martin (MSGJ · talk) 08:35, 10 May 2011 (UTC)

Code is in Template:Fix/sandbox2 and the example above is now using it. — Bility (talk) 18:24, 10 May 2011 (UTC)

Okay, I think what's in the sandbox (diff) should fix the issue. Usage is shown on testcases. — Bility (talk) 20:58, 25 August 2011 (UTC)

Well done for following through with this.  implemented — Martin (MSGJ · talk) 20:01, 29 August 2011 (UTC)

Substitution check

I'd like to ask for the parameter calling the substitution check to be changed to "subst" like in {{Ambox}}. For two reasons. To avoid confusion and make it easier to copy code. And to use a shorter name, which is useful to make the templates using {{Fix}} look nicer and easier to understand. I could add a third reason: for uniformity's sake.

If the number of templates using substcheck is too large to change them all easily (I would be willing to do some 100 e.g. if somebody were to provide me with a list), then perhaps it is possible to use "subst" and "substcheck" both. Debresser (talk) 23:50, 26 November 2011 (UTC)

Method of substitution check

{{Ambox}} uses the following code for substitution checking

{{#ifeq:{{{subst}}}|SUBST
 |{{#if:{{{name|}}}
  |{{error|Template {{tlx|{{{name}}}}} has been incorrectly substituted.}}
 }}[[Category:Pages with incorrectly substituted templates]]
}}

{{Fix}} uses

{{#switch:{{{substcheck|¬}}}
 |¬={{category handler
  |template=[[Category:Templates needing substitution checking]]
  |nocat={{{nocat|<noinclude>true</noinclude>}}}
 }}
 |SUBST=[[Category:Pages with incorrectly substituted templates]]
}}

I do not understand these codes very well. What does jump to the eye is the addition here of a line adding Category:Templates needing substitution checking. What is this page for? What is the checking that needs to be done? Is this a temporary category? It includes templates that use fix directly, but also templates that call upon other templates that use fix. Is that the intention?

Another question is, which of the two ways of substitution detection is better? That is, assuming that the line adding Category:Templates needing substitution checking is temporary. Debresser (talk) 00:48, 27 November 2011 (UTC)

The basic idea behind both is that a parameter is passed the value "SUBST" if the template containing the call to {{ambox}}/{{fix}} is being substed. The {{ambox}} version has the additional feature that it will output an error message to the page if |name= is used from the using template. The {{fix}} version has the additional feature that it will categorize any calling template into Category:Templates needing substitution checking if the calling template does not use |substcheck= to properly use the substitution checking code. Unfortunately, there is no way for it to tell the difference between e.g. {{clarify}} that would need the subst-checking code added and e.g. {{m}} that just happens to be using {{clarify}} (note also that {{clarify}} uses a different trick, where {{subst:clarify}} will actually result in {{Clarify| date=December 2011}} being output to the page). The intent of the category is most likely to be a cleanup category for all {{fix}}-using templates. Whether it is temporary or not depends on whether the lack of subst-checking support in new {{fix}}-using templates is an issue that needs to continue to be tracked.

Neither is necessarily "better" than the other, they serve slightly different purposes. Anomie⚔ 21:43, 3 December 2011 (UTC)

Anomie has explained it better than I could. I'll add that I don't think it's worth changing over the name of the parameter to match. However if you really would like to do this, I can make both work temporarily and then remove the other when you've finished. I don't think it would be much work because I don't think this feature has actually been implemented on very many templates. — Martin (MSGJ · talk) 21:47, 3 December 2011 (UTC)

If you would agree to do so, please do. I think it would be a good idea, both to use the shorter name for the parameter, and to have these templates look alike as much as possible. Just notice that I am not an admin and would need help with editprotected templates. How would I know which templates to edit? Is there a way to check this? Debresser (talk) 23:17, 3 December 2011 (UTC)

I think there is no good reason to have the Category:Templates needing substitution checking category with {{Fix}}, unless there would be serious intent to add substitution checking to all templates. What do you think? Debresser (talk) 23:20, 3 December 2011 (UTC)

In addition, I think that the substitution checking in {{Fix}} is better than in {{Ambox}}. It is of obviously more worth to fix the substitution then to warn about it. Wouldn't you say so? If I understand things correctly, of course. Perhaps we should consider to implement the substitution checking of {{Fix}} in {{Ambox}} as well? Debresser (talk) 23:23, 3 December 2011 (UTC)

Both warn about the substitution, by applying Category:Pages with incorrectly substituted templates. The ambox version does in the article text as well. And the fix version warns (via category) about templates that don't use its subst checking code. Neither fixes substitution; to do that you'd apply {{unsubst}} or the slightly simpler {{User:Anomie/Nosubst}} (probably to the individual templates rather than the meta template). Anomie⚔ 23:46, 3 December 2011 (UTC)

What I meant is that with {{Fix}} the output is as it was intended to be, even if the template was substituted. If I understand correctly. That is a big advantage over the code of {{Ambox}}, which only gives warnings. Debresser (talk) 00:43, 4 December 2011 (UTC)

I was mistaken, Anomie. I thought that {{Fix}} ensures that the output of a substituted template would be as intended if it were not substituted. But I was mistaken. That is only when you use code like {{Clarify}} does. Debresser (talk) 00:02, 8 December 2011 (UTC)

Date formatting

A comment was raised at template talk:citation needed#Confusing flag regarding the formatting of the date option. Simply putting "... from December 2011" is confusing in the case of {{citation needed}} at least and possibly other uses. Rather than running the sentence on, it might be worth considering starting a new sentence with "Tagged since" for the date. Code change is pretty trivial, but does anyone have any comments first before I run up a sandbox? Chris Cunningham (user:thumperward) (talk) 10:57, 6 December 2011 (UTC)

Another option is to leave the date in the wikicode for categorisation purposes, but not to display it with the tag. — Martin (MSGJ · talk) 15:17, 12 December 2011 (UTC)

Request

I created Template:Fix/category, and adapted the category section of Template:Fix/sandbox to use that template. And then I added the possibility for a second and third dated and undated category. I have tested these versions successfully , see Template:Template sandbox2 and Point Valid (my usual testing sacrifice). Note that the documentation should be updated, minimally, by adding these parameters at least to the full list of parameters. Debresser (talk) 23:56, 10 December 2011 (UTC)

The way you have coded that template I'm not sure there is any benefit to using a subtemplate (i.e. no simplification of code, and no duplication avoided). So why not just add the required code to the main template? By the way, are there cases where 2 or 3 different categories are needed, or can you provide some examples? — Martin (MSGJ · talk) 15:21, 12 December 2011 (UTC)

I agree that an extra template might not be necessary. But having it will add some clarity to the code, and make it easier to change the way categorisation is handled (something which has happened in the past on Ambox, from where I got the idea of making a separate template for handling the categorisation).

Yes, many maintenance templates use two categories, of which either may consist of a dated category and an all-inclusive category. Only very few use three categories, but it does happen. Please see Wikipedia:List of monthly maintenance categories with templates (which I compiled and update from time to time) for details. In any case, to the best of my knowledge, three categies (dated and all-inclusive) should be enough to serve all templates using Fix. Debresser (talk) 16:51, 12 December 2011 (UTC)

It might make sense to call the subtemplate 3 times with each of the categories. I have done this in the sandbox, you might like to have a look. But I still don't think there is any benefit in the way you coded it. About the subst/substcheck: I have also made this change to the sandbox. — Martin (MSGJ · talk) 17:41, 13 December 2011 (UTC)

The subst/substcheck change is obvious. The category handling is flawed. You combined date and cat-date, both in Fix/sandbox and in Fix/category. I tested it, and it doesn't work. As to the calling of Fix/category three times, instead of repeating the same code in Fix/category three times, I think my way is more elegant, but that is not crucial. If you want a working version, you had it, and it was ready to use. If you want to do it your way, just fix the code by separating date and cat-date, the way it was, and it will work also. Debresser (talk) 19:48, 13 December 2011 (UTC)

Calm down a bit? You come across as quite agressive. I'll take a look at the code again shortly. — Martin (MSGJ · talk) 23:09, 13 December 2011 (UTC)

I'd say more matter-of-factly. At least, that was how I intended it. I just don't understand what was wrong with the code I wrote. Even if you want to replace the repetition in Fix/category with a repetition in Fix itself, you could just have copied code, without changes, and it would have worked. If anything, I am frustrated with the fact that only admins can change protected templates, and they feel they have to do things their way. If you want, I could draw up the codes you need on my userpage in five minutes, and here I am waiting for days, just to implement a simple and sourly need extension from 1 to 3 parameters. Hardly a big deal. Sorry, if I write this to you. It is not about you personally. I was trying to be polite, instead of just putting up an editprotected template, when asking for your advice. I hope my being honest has not pissed you of. Because I think there are good things we can do with Fix and Ambox yet. Debresser (talk) 07:15, 14 December 2011 (UTC)

Please copy the sandbox version to the template to allow for second and third categories. This version will also add a temporary mechanism to replace "substcheck" with "subst". All of this analogously to {{Ambox}}. Debresser (talk) 17:19, 31 December 2011 (UTC)

Done. Killiondude (talk) 06:17, 11 January 2012 (UTC)

That is great, thank you. Now if only I had some time to start using these features. Debresser (talk) 09:49, 11 January 2012 (UTC)

Brackets in the 'Fix' supertext

(Pulling this in from Template talk:Citation needed on the recommendation of Gadget850 (Ed) ^talk.)

Footnote marks (example: ^[1]) include the opening bracket, the number, and the closing bracket in the hyperlink. In Template:Fix and its offspring (example: ), the brackets aren't included as part of the link. Can this be changed, for the sake of consistency? BreachReach^talk 22:17, 19 December 2011 (UTC)

No, it's not a footnote. — Bility (talk) 06:20, 20 December 2011 (UTC)

Seems to make sense to me. Unless there's a specific reason to keep the brackets out of the link. --Waldir ^talk 15:33, 8 March 2012 (UTC)

It's consistent with the rest of Wikipedia's style. For exmample we write "His valet (Jeeves)" not "His valet (Jeeves)." If anything the footnote style is wrong, but the number alone is a very small click target. Rich Farmbrough, 17:04, 20 March 2012 (UTC).

Progress

I had some time yesterday and today (basically by not going to sleep), and changed all instances of "substcheck" to "subst". That is, all instances I know of. If somebody could check whether perhaps I forgot any, and then delete the "substcheck" parameter from the code.

In addition, I think we there is no point in Category:Templates needing substitution checking. For three reasons:

1. The reason mentioned by Anomie, that it is impossible to tell which template in that category uses {{Fix}} and which uses another template that uses {{Fix}}.
2. Because I checked all of the templates there, and added substitution checking wherever necessary.
3. There are quite a few templates that don't do substitution checking but do actual substitution fixing, like Template:Edition needed. And these are needlessly listed in that category.

In short, the code could be {{#ifeq:{{{subst}}}|SUBST|[[Category:Pages with incorrectly substituted templates]]}}, much like in {{Ambox}}, and Category:Templates needing substitution checking can be deleted. Debresser (talk) 23:00, 15 January 2012 (UTC)

The first thing was done today by Rich. Any objections to the second? Debresser (talk) 00:06, 8 February 2012 (UTC)

The self-substing mechanism is a better solution. Rich Farmbrough, 17:05, 20 March 2012 (UTC).

But that would mean changing a lot of template with intricate code. While here I propose a minor edit which also is a simplification. Debresser (talk) 23:03, 20 March 2012 (UTC)

Post-title

Could we add a Post-title parameter that simply appends a space and the text provided to the existing title and (optional) date message? This could then be used to provide the reason in the tool-tip, as has been asked at various uses of this template. Mark Hurd (talk) 17:30, 17 August 2012 (UTC)

instead of "(November 2013)", use "(tagged since November 2013)"?

Stale

At Wikipedia talk:WikiProject Inline Templates, I have posted a new thread about changing the text used to give the elapsed time since tagging. The main issue is whether or not there's enough context for inexperienced editors to know what the tag date means. By adding "tagged since" it gives some context and also a gentle nudge to help fix it. The disadvantage is just the extra length of all {{Fix}}-template's tooltips. Please comment on the Wikiproject page instead of here because I think more people would follow that than this technical template. Jason Quinn (talk) 18:04, 6 November 2013 (UTC)

Appended tooltip text (e.g., "from April 2013") based on date parameter causes confusion

Resolved

 – Done

Templates based on this template have a tooltip that appends text like "from April 2013" onto the tooltip based on the date parameter. I have been cleaning a lot of {{citation needed}} templates from articles in the Category:Pages containing citation needed template with deprecated parameters. I have repeatedly observed problems with the current form of the tooltip. The confusion arises because the text gets appended to the other text that appears in the tooltip and it can change the other text's intended meaning. Even the default tooltip's meaning (used millions of times on Wikipedia) is distorted. When the user enters just {{citation needed|date=April 2013}}, the display text is

The appended "from April 2013" changes the meaning of the text. Interpreted literally,makes the text ambiguous. It may be interpreted that the editor wants sources from that specific month.

Things can be really confusing when a user enters specific text as with a "reason" parameter. It's a fact that editors use ending punctuation on their supplied reason about as often as they do not; so half of the time we get tooltips like

which is syntactically incorrect, and

which is semantically incorrect.

I propose that the appended text be changed to just "(April 2013)".

It would be MUCH nicer is the default tooltip were

and the user-supplied tooltips no longer are influenced by ending punctuation:

which is syntactically incorrect, and

I am not very familiar with all the templates that this meta-template get used by; so it's hard to say how may proposal would affect them all... but my observations are by no means limited to the {{citation needed}} tag and I have seen exactly the same problems with many other inline templates. For instance, the {{Verify credibility}} tag's default tooltip says:

Here the same problem occurs as above but reads even more convincingly the wrong way.

I'm actually surprised that a template so ubiquitous has such obvious usage issues but has gone unfixed for so long. If no convincing reason is given to keep the current approach, I will just made the change and revert if any major issues are discovered. Input please. Jason Quinn (talk) 19:30, 3 April 2013 (UTC)

PS I have contacted a few people from the articletemplate's history to generate some discussion. Jason Quinn (talk) 19:39, 3 April 2013 (UTC)

• Support, makes sense to me. — Bility (talk) 21:21, 3 April 2013 (UTC)
• Support - I never noticed the hovertext before, but now that I do, I support this proposal. GoingBatty (talk) 02:09, 4 April 2013 (UTC)
• Support; it looks better to me. Note it becomes very similar to the displayed output of Template:Ambox#date. Mark Hurd (talk) 04:36, 4 April 2013 (UTC)

I have gone ahead and made the change. I have examined a few test cases. Seems to work. Big improvement. Changes only show up on newly edited pages as for now. Not sure how long it will take for the servers to cache versions of the rest of the articles. Jason Quinn (talk) 00:48, 5 April 2013 (UTC)

Jason's edit has a minor typo:

}}[[{{{link|Wikipedia:Cleanup}}}|<span title="{{{title|{{{link|Wikipedia:Cleanup}}}}}}{{#if:{{{date|}}}|<nowiki/> ({{{date}}}}})">

should be:

}}[[{{{link|Wikipedia:Cleanup}}}|<span title="{{{title|{{{link|Wikipedia:Cleanup}}}}}}{{#if:{{{date|}}}|<nowiki/> ({{{date}}})}}">

To emphasise the correction "date}}}}})" should be "date}}})}}".

Mark Hurd (talk) 12:09, 5 April 2013 (UTC)

Yes, I spotted that too. Done --Redrose64 (talk) 12:25, 5 April 2013 (UTC)

Prevent broken tooltips

The following code:

 }}[[{{{link|Wikipedia:Cleanup}}}|<span title="{{{title|{{{link|Wikipedia:Cleanup}}}}}}{{#if:{{{date|}}}|<nowiki/> ({{{date}}})}}">{{{text|}}}</span>]]{{#if:{{{post-text|}}}

Should be:

 }}[[{{{link|Wikipedia:Cleanup}}}|<span title="{{delink|1={{{title|{{{link|Wikipedia:Cleanup}}}}}}{{#if:{{{date|}}}|<nowiki /> ({{{date}}})}}}}">{{{text|}}}</span>]]{{#if:{{{post-text|}}}

This will fix the problem of people attempting to insert links in this parameter's value, which will cause template breakage. Various {{Fix}}-derived templates have this manually inserted into their |title= parameters as a wrapper around the value, but most do not, and it should be applied across the board, since there are zero cases where attempting to link inside the ... value of a <span title="..."> would be valid.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:23, 3 April 2016 (UTC)

Code added to /sandbox and tested at /testcases. Seems to work as described. Will pushing it through {{delink}} twice (for those templates which have already been adapted) cause any issues? — Martin (MSGJ · talk) 09:02, 4 April 2016 (UTC)

I can't see why it would: "Chicken nuggets" was just passed through it three times in this sentence. At any rate, it can be removed from the derived templates that are calling it manually.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:02, 5 April 2016 (UTC)

Done Please do remove delink from the others templates. Thanks — Martin (MSGJ · talk) 08:48, 5 April 2016 (UTC)

Optional standardized handling of the "reason" parameter

See also: Template talk:Contradict-inline § Feature merge and improvement

It would be nice if this had a standardized feature to append the value of |reason= to the mouse-over tooltip, when this feature is enabled. This can be done by changing:

{{{title|{{{link|Wikipedia:Cleanup}}}}}}{{#if:{{{date|}}}|<nowiki/> ({{{date}}})}}

to

{{{title|{{{link|Wikipedia:Cleanup}}}}}}{{#if:{{{reason}}}| Note: {{{reason}}}}}{{#if:{{{date|}}}| ({{{date}}})}}

(which also replaces the ungainly use of <nowiki /> to force the space, with a simple encoded space character,  ). This would go inside the {{delink}} code in the above thread.

Using this would be optional, as some {{Fix}}-derived templates use this parameter differently. Presently there are the following behaviors:

• Display nothing. This is the most common, but there is generally no reason to not use the tooltip to help editors identify what the tagged problem is without having to go look at the source code of the tag and hope it has a |reason= parameter or an HTML comment. I was the one who introduced the idea of documenting a "silent" |reason= parameter as supported by any cleanup/dispute template that didn't have a more specific use for one, back in 2005 or whenever it was; I don't think {{Fix}} even existed back then, or I would have done it the way being proposed now, for this class of template.
• Manual code adding the reason value to the tooltip in a way that locally mirrors what is proposed here. This is rare, and "invented" by me, so I can just convert it in the few places I've put it, to use the new parameter supported by {{Fix}}.
• Manual code doing something else, like adding the |reason= text to the tooltip in mid-sentence; these cases would be unaffected, simply by not passing the |reason= to {{Fix}}, though many of these could be adapted to the new method instead.
• Replacing the entire tooltip with the |reason= value. Ten or so templates do this, and it is a terrible idea, since it leads to things like , that WP:BITE new editors, or , occluding the entire rationale for the template. The default wording of the tooltip (aside from any custom output generated by specific parameters that contextually modify it) should be preserved because it was written for a reason. If people need to tag a problem that the template does not actually address, they are using the wrong template. I would replace the few extant cases of this "clobber it all with |reason=my idiosyncratic nonsense goes here" usage in derived templates with the proposed new feature.

 — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:29, 5 April 2016 (UTC)

Pinging Redrose64 and Debresser who have been involved with a similar proposal on other templates — Martin (MSGJ · talk) 08:52, 5 April 2016 (UTC)

@MSGJ Thanks. Indeed, why do we need to discuss this at 3 template talkpages?

I am opposed to adding "notes", in general. It is enough that we have tags all over the place with standardized messages. We don't need personalized messages as well, with all the ambiguous language sand spelling mistakes of the average editor.

A reason is not a note, but something completely different, so a "reason" parameter should not be displayed as "note".

Some templates use the reason parameter instead of the usual text, and in those cases it would definitely not be a note. On the other hand, we should probably remove that function and replace it by a silent reason, as in most templates (see discussion at Template_talk:Contradict-inline#Behavior_of_the_.27reason.27_parameter).

Who is to say what is a note, and what is the main problem?

In short, I prefer the silent reason parameter. Debresser (talk) 10:18, 5 April 2016 (UTC)

I'm centralizing the discussion here specifically because it makes no sense to hash it out on the talk pages of each derived template, of course.

1. The first objection doesn't seem salient, since none of the |reason= notes not affect reader-intended content (presently or under this proposal), but only appear in tooltips, or source, intended for editors (the very purpose of the tooltips is to minimize the amount of editorial annotation that is visible in the pages, so only a one-or-two-word tag is present, while still making it easy for editors to get the point). If anything, this objection is to the |pre-text= and |post-text= parameters, not to the one proposed here. Whether an editor's spelling is great or not is irrelevant; since no one cares about these notes but editors, and the will have the same text regardless what is done with the |reason= parameter, language skills are a moot point. Your root objection appears to be that you don't like inline cleanup/dispute tags in the first place. Sorry, but that ship has already sailed.
2. Asserting a difference that one does not make a case for, does not establish a difference. Obviously, a reason, written as a note following the text |reason=, is in fact a note; the only question is whether we should standardize the possibility of showing this note inside the tool tool tip, or continue being weird and unpredictable about it for no good reason. If you simply don't like the word "Note:" in the tooltip, which seems to be the gist of the wording-niggling objection, then propose a replacement. How about "Reason:"?
3. Next, I already pointed out that some templates use the reason parameter as a whole-text replacement for the template's tooltip output, and outlined why that's a terrible idea. I spelled out why in much greater detail at one of the other pages (including how it interferes with automated categorization). I'm glad we agree it is "functionality" we do not want. This proposal, whatever its other features or flaws, is a way to fix that.
4. Who is to say what you mean by that question, and what relevance it has for whether we should have a feature for a consistent approach, rather than continue to have wildly conflicting, random ones, some of which do not make sense? Heh. The fact that main problem being flagged by the template, and the editor;s reason for inserting it, are often not identical is precisely why it is proposed to have the |reason= text added to the tooltip – not buried in code that is a pain in the butt to go find or to even know that it exists at all (the main problem with hiding it), not replacing the stock rationale of the template itself, and not replacing or being added to the always-visible text of the template. That last is what the |post-text= and |pre-text= parameters do, and fortunately they are not frequently abused to do something awful, like:
   
5. Preferring a silent reason parameter is fine. Some of us do not prefer one, so the option should exist, and should be consistent when implemented. The reasonable way to do that is in the meta-template, so code does not fork (and so we undo existing code forks).

I think that addresses all the points you raised.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:58, 5 April 2016 (UTC)

So we agree that it should be a silent parameter (and I think you can go ahead and change that in the templates where it is a visible parameter), but we disagree whether it should be called "note". I think it should not be called anything, but I think that calling it "Reason:", as you propose above, is also acceptable. Debresser (talk) 18:36, 5 April 2016 (UTC)

Suggestion: Make nowrap optional

There are cases where text wrapping is handy. I created a fork of this template with wrap enabled, but a better solution might be to add a parameter in the original template which toggles it. Then templates which are based on Fix could add this parameter as well and pass it on when calling Fix.

• Template talk:Explain#Added a variant of this template with text wrap

--Pizzahut2 (talk) 01:41, 18 October 2017 (UTC)

What's the use case? If you're providing output with this or a related template that looks something like ^{[Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.]}, you're almost certainly making a mistake. Use the |title= or |reason= parameter to say something detailed.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  03:44, 18 October 2017 (UTC)

"Explain" template in tables: List of Intel CPU microarchitectures I guess it's a bordline case. --Pizzahut2 (talk) 14:54, 19 October 2017 (UTC)

Usage help please

I want to add a second category, category:Articles with self-published sources to {{self-published inline}}. Right now it adds a dated category through cat-date = Category:Accuracy disputes; I don't want to add yet another monthly category, but I do want a category that collects all articles which have inline tagged self published sources. This is a different use case form the general tags for unreferenced, self-published etc., because for the most part the articles are well referenced with one or two single exceptions. The why-behind-the-why is, I am working to reduce the use of self-published sources especially Lulu/XLibris), as many of them are basically spam. Guy (Help!) 12:14, 27 December 2017 (UTC)

Quotation marks issue

Somebody's noticed a problem with using quotation marks in the "title" parameter of the template. Refer WP:Requested templates#Let's fix Template:Fix. I'll be here trying to work out why this is happening for a bit. Naturally I'll be breaking the template many times before I fix it, but that's why I'm in the sandbox. Mr rnddude (talk) 23:20, 28 August 2018 (UTC)

I suspect it's interfering with the "span title" since this issue is only happening on the title and date parameters. The link and text parameters have no such issue. Mr rnddude (talk) 23:30, 28 August 2018 (UTC)

html entities work:

{{Fix
|link=Wikipedia:Basic copyediting
|text=needs copy edit
|title=Lorem ipsum "dolor sit amet".
}}

which gives this

so a simple string replacement:

title={{#invoke:String|replace|source=Lorem ipsum "dolor sit amet". |pattern=\"|replace=" |plain=true}}

like this:

{{Fix
|link=Wikipedia:Basic copyediting
|text=needs copy edit
|title={{#invoke:String|replace|source=Lorem ipsum "dolor sit amet". |pattern="|replace=" |plain=true}}
}}

should work

If this really is a necessary fix. I have my doubts but could be convinced.

—Trappist the monk (talk) 00:27, 29 August 2018 (UTC)

Hmm, Distelfinck, obviously you needed quotation marks when using the template or you wouldn't have found out about this error. Perhaps you can weigh in on whether this will help you. You can alternatively use ' instead of " as well. Mr rnddude (talk) 01:46, 29 August 2018 (UTC)

Sure this fixes it. My concern was that this template is used a lot, so I imagine I'm not the first person who's run into this issue, and this fix would save people time. Right now every person happening upon this issue has to replace the quotation marks, this would no longer be the case with the fix. I don't see any downsides to the fix --Distelfinck (talk) 18:15, 29 August 2018 (UTC)

This has been discussed before, but I can't remember when. Before explaining what is happening, I'd like to correct one or two misconceptions: there is no such thing as "span title". In a piece of HTML like this:

<span title="Foo">Bar</span>

span is the name of a HTML element; this element begins with an opening <span> tag and ends with a closing </span> tag. Opening tags may have zero or more attributes, and in our example, title="Foo" is an attribute of the <span> tag. The title attribute may be used with every HTML element (there are no exceptions since HTML 4.0). Some browsers use the title attribute to create a tooltip, but this is not part of the HTML standards. Attribute values are normally delimited with quotes, although under certain circumstances they need not be - but the presence of a space will make the quote delimiters mandatory. Since the quote character is used as a delimiter, it follows that the value cannot contain that character. --Redrose64 🌹 (talk) 21:29, 29 August 2018 (UTC)

Position

In this edit, I placed the Fix template at the beginning of a new paragraph. Nevertheless, the result shows that the tag was positioned at the end of the previous paragraph, and the two paragraphs connected. How did the code do that? And do we think that is a good idea? Debresser (talk) 02:16, 30 April 2019 (UTC)

@Debresser: As suggested by its name and confirmed by its documentation, {{Relevance inline}} is an inline template, and so is intended to go inline with the text - that is, immediately after the text that it applies to. --Redrose64 🌹 (talk) 15:24, 30 April 2019 (UTC)

That is evident. I asked how this is done technically, and whether it is a good idea that the template should itself "enforce" its inline character. Debresser (talk) 19:58, 30 April 2019 (UTC)

I think that it's something to do with the categorisation being placed before the superscripted text. --Redrose64 🌹 (talk) 21:13, 30 April 2019 (UTC)

Protected edit request on 3 January 2020

Can instances of {{{date|}}} be replaced with {{#time: F Y | {{{date|}}}}} (produces eg "November 2024") so that shortened month-year forms such as "Nov 2024" and "2024-11" can be used?  Nixinova   T   C   06:39, 3 January 2020 (UTC)

Oppose We prefer one standard dateformat. Debresser (talk) 14:18, 3 January 2020 (UTC)

Exactly -- this creates a standard date format.  Nixinova   T   C   20:36, 3 January 2020 (UTC)

 Not done not an uncontroversial change. Editor Nixinova: when you gain consensus for this change, reactivate the {{edit fully-protected}} template by setting |answered=no.

—Trappist the monk (talk) 14:29, 3 January 2020 (UTC)

fake fix

The documentation contains a reference to {{fake fix}} "used to create dummy versions of templates based on {{fix}} for use in documentation" - but that actually just redirects to {{fix}}. Is {{fake fix}} dead, or redundant or what? Colonies Chris (talk) 17:24, 28 August 2020 (UTC)

Please convert double quotes to single quotes

I have added a test case that shows that double quote marks break the hover text in this template. One solution would be to convert "double quotes" into 'single quotes'. Can someone please implement this? I don't know the best way to do it. – Jonesey95 (talk) 22:35, 26 April 2021 (UTC)

You might do something like this:

{{#invoke:string|replace|source={{{title|}}}|pattern=" |replace=' |plain=true}}

Here's an example using your testcase text:

{{#invoke:string|replace|source=This is a [[link]] for "fix".|pattern=" |replace=' |plain=true}}

This is a link for 'fix'.

—Trappist the monk (talk) 22:46, 26 April 2021 (UTC)

That appears to work. I have put the code in the sandbox and created test cases that seem to work. – Jonesey95 (talk) 01:26, 27 April 2021 (UTC)

 Done — Martin (MSGJ · talk) 19:49, 21 May 2021 (UTC)

Protected edit request: auto format date

{{#time: F Y | {{{date|}}} }} should be used instead of just {{{date|}}} to format all date inputs properly instead of having the template break if someone types "Nov 2021" instead of "November 2021" etc.  Nixinova   T   C   00:03, 15 November 2021 (UTC)

 Not done: please make your requested changes to the template's sandbox first; see WP:TESTCASES. This is a significant change that would affect 800,000 pages. It needs to be tested first. For example, what should the template do when someone puts in |date=Banana and the template wants to emit Error: Invalid time.? – Jonesey95 (talk) 01:40, 15 November 2021 (UTC)

Please don't convert double quotes to single quotes

The real problem reported about a year ago got a wrong solution. "Wrong" in the sense that it contradicts MOS:DOUBLE and produces an unexpected and undocumented effect. The correct solution would be to convert " to " (or " if somebody wants to save 1 byte). — Mikhail Ryazanov (talk) 23:42, 18 August 2022 (UTC)

 Not done: please make your requested changes to the template's sandbox first; see WP:TESTCASES. Izno (talk) 02:49, 19 August 2022 (UTC)

OK, done and don't see any problems with the test cases. Am I missing something, or the word "complex" in Wikipedia:Edit requests#Requests for templates must be read as "any"? — Mikhail Ryazanov (talk) 16:13, 19 August 2022 (UTC)

 Done No, but it will make your life easier if you can trivially demonstrate a lack of any issue with your suggested change. Izno (talk) 21:03, 19 August 2022 (UTC)

Blank output and invisible mistakes

{{fix|thing}} has no visible output. When previewing a large edit, it's easy to miss the fact that a tag is missing.

IMO the template should treat the unnamed parameter as text, or emit an error saying that I didn't provide any of the parameters that would make it non-empty, or emit an error that there's an unexpected unnamed parameter. Jruderman (talk) 22:04, 8 July 2024 (UTC)

@Jruderman: {{fix}} isn't intended for direct use - it's a core template around which other templates like {{citation needed}} are built. --Redrose64 🌹 (talk) 22:37, 8 July 2024 (UTC)

Right, there's a good set of pre-made tags for "problems", tuned for use in article space. I also use this template in talk pages, to indicate "what needs to be done" within an incomplete example or mini-draft. Jruderman (talk) 23:09, 8 July 2024 (UTC)

I have clarified the documentation; I hope that helps. – Jonesey95 (talk) 00:38, 9 July 2024 (UTC)

I see. I appreciate that you're working to make the change I requested even though the way I'm using this template isn't really among the intended uses. Jruderman (talk) 01:14, 9 July 2024 (UTC)

@Jruderman: We're not working to make the change you requested - we're advising against it. To this end, Jonesey's edit request (below) will put pages exhibiting such misuse into Category:Pages using Template:Fix with unknown parameters. --Redrose64 🌹 (talk) 07:21, 9 July 2024 (UTC)

I'm happy with the outcome. I asked for the template to treat the positional argument as text= or emit an error, and now it emits an error.

Catching pages with the error into a category was a good call too: Jonesey95 and I were able to locate and fix instances in several articles, including one that went all the way back to 2018. Jruderman (talk) 09:18, 9 July 2024 (UTC)

Edit request 9 July 2024

Description of suggested change: Please apply the code in the sandbox (diff here), which is a straightforward addition of the "check for unknown parameters" module that is used in hundreds of templates to categorize pages when a template is used with unsupported parameters. I will be happy to create the appropriate tracking category, or the admin who does this change can create it by copy-pasting the content of Category:Pages using infobox NRHP with unknown parameters and adjusting the template name in the first parameter.

Note that this error-checking module normally applies {{main other}} to limit its tracking to article space. Based on the most recent query on the talk page, it looks like people use this template in other namespaces as well, so I have removed that limit here. It might need to be imposed if I am wrong about this inference. – Jonesey95 (talk) 00:45, 9 July 2024 (UTC)

 Done Sigh. * Pppery * _{it has begun...} 02:01, 9 July 2024 (UTC)