Template talk:Smallcaps all

This template was considered for merging with Template:Smallcaps on 4 March 2012. The result of the discussion was "no consensus".

Talk from template:Sc

Two reasons against

It is not an advantage to store (and export via copy and paste) Old McDonald (McDonald) as Old McDONALD, because that’s not the orthographically correct form of the name. Template:Smallcaps does it right.

Besides, I like small caps when done correctly, but with most fonts and most browsers that does not yet happen – they simply automatically scale down uppercase glyphs – and so it looks ugly. Therefore I wouldn’t support their recommendation by WP:MOS (yet). — Christoph Päper (talk) 20:05, 13 December 2007 (UTC)[reply]

I agree about the raw-capitalising form (which i actually dislike in all cases). Note, though, that this template can be used either way.
—überRegenbogen (talk) 10:51, 11 April 2010 (UTC)[reply]

Invisible content in popups

The template output does not appear in wikilink popups. I suspect that skipping templates is hardwired into the popup mechanism. I don't know if there's a way to make an exception; but we could use it here—and i'm sure other places. If not, perhaps it could become a wish-list item.
—überRegenbogen (talk) 10:37, 11 April 2010 (UTC)[reply]

move

The following discussion is an archived discussion of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

Not moved. Not convinced that there is a consensus here. As mentioned below let the TfD discussion reach a conclusion and then see if a rename is needed. Note that the outcome there can dictate a rename if the template is re purposed. Vegaswikian (talk) 23:12, 15 March 2012 (UTC)[reply]

Template:Smallcaps all → Template:Hard smallcaps – The essential difference between this and {{smallcaps}} is that the small caps are hard-coded, so that when you copy-paste them they remain capitalized. The current name is obscure. — kwami (talk) 04:22, 8 March 2012 (UTC)[reply]

Let's first see the outcome of the TfD. It might change the template in its core. -DePiep (talk) 11:11, 8 March 2012 (UTC)[reply]
Object. The small caps are not hard-coded, the uppercase is hard-coded. Neither old or proposed name is descriptive of what the template does. Upper-case to small-caps is what it is doing, but that does not inform the editor that it permanently changes to uppercase first. If it is necessary for the text to be all uppercase, why doesn't the editor press CapsLock and type it that way to begin with?—Telpardec TALK 20:03, 9 March 2012 (UTC)[reply]

If you are starting with uppercase to be changed to smallcaps, why change it to lowercase so the small caps style can change it back to uppercase and reduce the size? That's redundant. Skip the upper to lower to upper and simply reduce the size of the uppercase. (. . . style="font-size:83%" . . .)
Also, when applying more than one style to something, why use more than one span, if they are operating on the same text? Use a single span with semicolon separated style specifications.
—Telpardec TALK 20:03, 9 March 2012 (UTC)[reply]

More redundancy: <span class="smallcaps" style="font-variant:small-caps;">
That class uses the same style instruction, so there is no need to use both.—Telpardec TALK 20:22, 9 March 2012 (UTC)[reply]

That was suggested by s.o. with vision problems who wanted to be able to override the caps. I'd welcome a proposal for a more streamlined encoding; I can run it past him to see it it works.

Directly reducing to 83% would mean that this template would no longer be synched with the other. Perhaps not a problem with only two, but IMO it's better to keept them locked together unless we have a need to separate them. — kwami (talk) 01:04, 10 March 2012 (UTC)[reply]

I struck out my previous comment. It is not redundant – I was misinformed – the "smallcaps" class is undefined in the Wikipedia global.css, and does not need to be defined, since the class is only needed for user defined styles. (See my message earlier today on Template talk:smallcaps) This template does not need to be synched with the other, nor call the other. The Smallcaps template is designed to change lowercase to smallcaps. This template is for changing allcaps to smallcaps. I discourage the use of the "uc:" magic word to permanently change the selection to all caps. If there is a legitimate reason for it to be all caps, the editor applying the template should make it all uppercase. IMO, the simplest and best way to code this template, including accessability css concerns is:

<span class="Allcaps-to-smallcaps" style="font-size:83%;">{{{1}}}</span><noinclude>
{{documentation}}<!-- PLEASE ADD DOCUMENTATION/CATEGORIES/INTERWIKIS TO THE /doc SUBPAGE, THANKS--></noinclude>

The end users who prefers lowercase can define that class in their user css as:

.Allcaps-to-smallcaps {
    text-transform: lowercase !important;
    font-size: 100% !important;
}

Note that I used font-size for the over-ride, not font-variant:normal. For people that want to switch to all-caps instead of smallcaps, only the font-size:100% is needed in the user style sheet. BTW: Template:Allcaps to smallcaps is my new suggestion to rename this template. Again, we only need to include the class in the wrapper, it does not need to be defined in the wiki global.css. Thanks. —Telpardec TALK 22:35, 13 March 2012 (UTC)[reply]

Object. Jee, there is a TfD going on. Just wait another week please. -DePiep (talk) 23:18, 9 March 2012 (UTC)[reply]

The above discussion is preserved as an archive of the proposal. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Proposed name change

Change Template:Smallcaps all to Template:Allcaps to smallcaps

That is more descriptive of what it does. —Telpardec TALK 15:42, 27 March 2012 (UTC)[reply]
- Does it? It is not just changing allcaps, it is also changing alllowercase to small caps. I think the proposed name is incorrect. -DePiep (talk) 15:57, 27 March 2012 (UTC)[reply]

Template:Smallcaps should be used to change lowercase to small caps. If there is a legitimate reason for a text to be all uppercase, then the editor should change it to allcaps before or when this template is applied. Right?
—Telpardec TALK 22:59, 27 March 2012 (UTC)[reply]

No. {{smallcaps}} should be used? 1: we are not talking {{smallcaps}} here, remember. 2: should be used -- whatever. {{smallcaps}} does something, and one can use it. Why care here? {{smallcaps all}} does another thing. So: No.-DePiep (talk) 23:06, 27 March 2012 (UTC)[reply]

Changes needed from results of TfD

Unresolved

which concluded "…no consensus to merge, but consensus to fix improper transclusions, and to make improvements to make the template closer to complying with accessibility"

The accessibility problem is solved by including class="smallcaps" within outer wrapper.
The simplest and best way to code this template, including accessibility css concerns is:

<span class="smallcaps" style="font-size:83%;">{{{1}}}</span><noinclude>
{{documentation}}<!-- PLEASE ADD DOCUMENTATION/CATEGORIES/INTERWIKIS TO THE /doc SUBPAGE, THANKS--></noinclude>

An end user who prefers lowercase can define that class in their user css as:

.smallcaps {
    text-transform: lowercase !important;
    font-size: 100% !important;
}

Note that that css uses font-size for the over-ride, not font-variant:normal. For people that want to switch to all-caps instead of smallcaps, only the font-size:100% is needed in the user style sheet.
Note that "class=smallcaps" is also used in these 3 templates also: Smallcaps, LORD, GOD. The latter 2 use font-size:83%, so the user css needs the font-size: 100% to change. Although the "Smallcaps" template may not need the font-size change, it causes no harm, so the same class=smallcaps will work on this template, as well as the other three. (Yet to be tested on various browsers... :)
What changes need to be made to the documentation? —Telpardec TALK 15:42, 27 March 2012 (UTC)[reply]
Changed class="Smallcaps" to class="smallcaps" to match other 3 templates. —Telpardec TALK 00:44, 28 March 2012 (UTC)[reply]

This proposal still has problems:

It does not match the functionality of the current template, because LC is output as LC.
It is not a visual match for {{smallcaps}}.

— kwami (talk) 18:17, 27 March 2012 (UTC)[reply]

The accessibility problem is that it should be output as LC. Whilst I broadly agree with the way in which the TfD was closed, I can't see a way in which it being output as UC is not a problem. Particularly, the uppercasing of all the class names and CSS really bothers me (CSS isn't case-sensitive, but class names are — at least in theory). At the moment, the output of {{smallcaps all|Hello World}} reads (with line-wrapping added for legibility):

     <span class="SMALLCAPS" style="FONT-VARIANT:SMALL-CAPS;">
        <span class="NOCAPS" style="TEXT-TRANSFORM:LOWERCASE;">HELLO WORLD</span>
     </span>

In the TfD thread, DePiep, posted three examples. Now I have my user CSS set to override both {{smallcaps}} and {{smallcaps all}}, using

     span.smallcaps, .navbar.mini li span, span.nocaps, span.NOCAPS, span.smallcaps span.nocaps, span.SMALLCAPS span.NOCAPS
     {
        font-variant: normal !important;
     }

But those three examples display as follows for me (listed as wikitext → your rendering → my rendering, hard-coded):

{{smallcaps|Hello World}} → Hello World → Hello World
{{smallcaps all|Hello World}} → HELLO WORLD → hello world
{{smallcaps|{{lc:Hello World}}}} → hello world → hello world

I could live with it more easily (despite the poor accessibility for most users, as a user would have to be logged in and know how to set up their user CSS to do so) if the middle one rendered the same as the first given my CSS override. But the problem is manyfold:

The case of the input text is altered for all users;
Almost all users will get inaccessible text all in capitals (anyone not logged in, which is the overwhelming majority of users, plus anyone who doesn't know how to set up their user CSS, which I would guess is most logged-in users);
This lack of accessibility comes at almost no benefit — I have yet to be given any examples other than the use within {{Respell}} that do not contravene the Manual of Style, with the possible exception of {{LORD}} (which we avoided discussing on the TfD and I am happy to leave as its own template, given it will be rarely used)

So the point I raised in the TfD still stands: What is the benefit of damaging the accessibility of articles for an æsthetic effect that has almost no legitimate uses?

— OwenBlacker (Talk) 22:34, 27 March 2012 (UTC)[reply]

You have repeatedly failed to justify your claim that this violates the MOS. So that objection so far appears to be invalid.

The fact that you can't think of something only means that you can't think of it. I've given other examples. But in any case, you could make the same argument against the basic small caps template, so any argument specifically against this template is invalid. If you feel that small caps violate the MOS (or whatever), then you should propose that {{sm}} be deleted. — kwami (talk) 00:47, 28 March 2012 (UTC)[reply]

I endorse Owen's accesibility concerns. If the MoS currently allows this to happen, then the MoS needs to be updated to prohibit the issues raised from affecting our readers. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:28, 28 March 2012 (UTC)[reply]

I still don't understand his concerns. As far as I can follow, he says he wants the text to be in all capitals, because he has trouble reading text in all capitals. That is, instead of using small caps that output as caps, we should just use caps, because he wants LC. That, and that we shouldn't use small caps, unless we use small caps. — kwami (talk) 20:40, 28 March 2012 (UTC)[reply]

My concerns are quite simple. Forcing capitalisation of text is bad for accessibility (and, thus, against the MoS). There are almost zero circumstances under which forced-capitalisation is appropriate for use in the Wikipedia (that is to say: under which the benefits outweight the accessibility concerns). Template:Respell is one such circumstance; Template:LORD might be another (whilst that's arguable, it's not an argument I'm interested in having); abbreviations like NASA or AIDS are not appropriate circumstances. For those abbreviations they should genuinely be in capitals — in the source-code and in display. Lord is presentational, as is the use of small-caps in Bluebook citations — both of these should be reversible by users (and preferably disabled by default, but I am open to persuasion on that point). I personally feel the same is the case for pronunciation respellings (certainly I want to be able to override the smallcaps, given they're also emboldened), but I think the accessibility case is weaker there.

I have yet to have seen any argument for the use of smallcaps in the Wikipedia that is not one of these specific examples I've just given, apart from an æsthetic desire to see abbreviations like NASA and AIDS displayed as NASA or AIDS. I'm open to persuasion that there is a compelling need for this template to force capitals in user display, much less in the underlying source-code or in a fashion that is difficult or impossible to override.

You mentioned that you couldn't see how this is a violation of the MoS. WP:DEVIATIONS specifies that we should avoid style="" attributes in favour of CSS classes; MOS:BADEMPHASIS and MOS:SMALLCAPS both advise against smallcaps (particularly the latter) and MOS:ABBR does not at any point advocate in their favour. This isn't about my personal problems with reading capitalised text. We have a policy that Wikipedia should abide by accessibility principles; this is one of them. — OwenBlacker (Talk) 22:25, 3 April 2012 (UTC)[reply]

This all was raised at the TfD. It did not convince. Now you are recycling the same arguments here? No way. There will be no deletion of this functionality. -DePiep (talk) 23:25, 3 April 2012 (UTC)[reply]

As now noted above, the TfD concluded: "…no consensus to merge, but consensus to… make improvements to make the template closer to complying with accessibility" (my emphasis). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:37, 9 April 2012 (UTC)[reply]

Glad we agree. Now how to convince OwenBlacker? Over here [1], they are still saying like "no capitalisation until I agree". (we should disallow {{lc:}} ansd {{uc:}} altogether if I understand them well). -DePiep (talk) 20:21, 9 April 2012 (UTC)[reply]

It seems we all agree that the TfD concluded with consensus to fix the accessibility, as is Wikipedia Policy. It is not me saying "no capitalisation until I agree", I am merely pointing out that the MoS and accessibility concerns do not allow this kind of capitalisation. {{lc:}} and {{uc:}} are magic words, not templates; they are quite rarely used for similar reasons. There are templates at {{allcaps}} and {{nocaps}} which can similarly alter the display, but not the output — {{smallcaps}} does this and doesn't have the accessibility concerns. The whole problem with this template is the way in which it differs from {{smallcaps}}.

I am still waiting for a single example of how this template can legitimately be used. None of the examples at Template:Smallcaps all/doc are legitimate examples — they are all terms that should genuinely be in capitals and are only suggested here for the æsthetic desire I mentioned above. It may seem like I'm "recycling the same arguments"; that would be because those arguments suggest to me that this template should have been deleted and I have yet to see any counterargument against those arguments. —OwenBlacker (Talk) 12:31, 11 April 2012 (UTC)[reply]

And we're still waiting for you to propose anything constructive. You never responded to my last attempt to fix the problem, for example. It's hard to take you very seriously when you're not cooperating. If you're too busy to get that involved, I understand; just point us to where you think we should go to get this fixed. — kwami (talk) 21:15, 11 April 2012 (UTC)[reply]

Sorry, it is partly that I'm busy, but partly that I genuinely can't see a way in which forcing capitalisation can be anything other than an accessibility problem. The reason I keep asking for examples of legitimate use is because that would help me work out how best to handle the situation. If it is just that there are a small number of easily-enumerated examples, we can create specific templates and deprecate this one. If it's that there a handful of legitimate uses, then it might just be that we can agree they're more important than the accessibility concerns and tweak the template documentation to make clear the distinction between legitimate and illicit uses of the template (at the moment the documentation advises its use for NASA, which is definitely a no-no).

I do want to find a mutually-agreeable solution, I'm just not sure there is one. Examples of use cases might help me find some, though. —OwenBlacker (Talk) 13:20, 14 April 2012 (UTC)[reply]

There are several given above: The respelling template, grammatical abbreviations in interlinear glosses, religious euphemisms like LORD and GOD, and initialisms that are set in small caps for stylistic reasons. You say that the latter violate the MOS, but I fail to see how: I've asked on the MOS page, and either no-one thought it important enough to respond, or no-one there sees it as a violation. Also, and this is the question I've never gotten answered from you, I fail to see how "BC" is any more an accessibility problem than "BC" would be: If you have a problem reading things in all caps, then writing things in all caps is the problem, not small caps. Your CSS override won't work on "BC" any more than it does on "BC". If used correctly, this template wouldn't add capitalization at all, it would only format existing capitalization. — kwami (talk) 20:29, 14 April 2012 (UTC)[reply]

Regardless what is decided about what should be capitalized, we need to:

CHANGE THIS:
{{uc:{{#if:{{{2|}}}|{{{1|}}}{{smallcaps|{{nocaps|{{{2|}}}}}}}|
{{smallcaps|{{nocaps|{{{1|}}}}}}}}}}}<noinclude>

TO THIS:
<span class="smallcaps">{{uc:{{#if:{{{2|}}}|{{{1|}}}{{smallcaps|{{nocaps|{{{2|}}}}}}}|
{{smallcaps|{{nocaps|{{{1|}}}}}}}}}}}</span><noinclude>

That way the class selector is in the outermost wrapper and can change anything within to anything, with no need to access the other class selectors within the Template:Smallcaps or Template:Nocaps, which the uc: screws up by changing the case-sensitive class name to all uppercase. For Owen to change the selected text to lowercase, he should only needs this CSS:

.smallcaps {
    text-transform: lowercase !important;
    font-size: 100% !important;
}

That class=smallcaps selector is the same class that is used in Template:Smallcaps, Template:LORD, and Template:GOD, the latter two change font size, so the 100% is needed for those two, and causes no harm to the other two. (I still think my suggestion at the beginning of this section is the way to go. :)
—Telpardec TALK 22:45, 14 April 2012 (UTC)[reply]

I put that code in {{Hardsmallcaps4}}. Owen, does that work for you? Here's a sample:

{{Hardsmallcaps4}} {{Hardsmallcaps4}} (compare LORD)

Telpardec, does your proposal also work for the {{LORD}} template, so that we can have a single place for formatting all smallcaps on WP?

Also, did you mean put it in monobook.css? I tried that, and it makes no difference at all. — kwami (talk) 23:28, 14 April 2012 (UTC)[reply]

(Telpardec now says his proposal does not work. — kwami (talk) 22:52, 23 April 2012 (UTC))[reply]

Changes needed from results of TfD (part 2)

How are we going to resolve this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:10, 30 July 2012 (UTC)[reply]

I just added the class="smallcaps" to the template. That provides a class name to modify any part of the inner class stuff. See the sample CSS above for one way to implement an override.
—Telpardec TALK 03:30, 3 August 2012 (UTC)[reply]

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Since TemplateStyles is introduced, this can be done by copying following codes:

<templatestyles src="smallcaps/styles.css"/><span class="smallcaps">{{#if:{{{2|}}}|{{uc:{{{1}}}}}}}<span style="text-transform:lowercase;">{{{2|{{{1}}}}}}</span></span><noinclude>
{{Documentation}}</noinclude>

Then the template will calling TemplateStyles to produce small caps variant. --Great Brightstar (talk) 16:30, 5 January 2019 (UTC)[reply]

Not done the referenced style does not exist (Template:Smallcaps all/styles.css). Please create the appropriate support pages first, also test in sandbox prior to reactivating the edit request. — xaosflux ^Talk 13:14, 7 January 2019 (UTC)[reply]

I saw another solution is using existed template:

{{smallcaps|1={{#if:{{{2|}}}|{{uc:{{{1}}}}}}}<span style="text-transform:lowercase;">{{{2|{{{1}}}}}}</span>}}<noinclude>
{{Documentation}}</noinclude>

Then this template will having the referenced style directly, don't need to create a new one.--Great Brightstar (talk) 21:24, 13 January 2019 (UTC)[reply]

Please use the sandbox and testcases page. No errors with this change? (I've put your code in the sandbox). -DePiep (talk) 10:19, 15 January 2019 (UTC)[reply]

Yes, the new source code is works the same as current template while I saw the test cases. Also, the new source code is already tested and passed in Chinese Wikipedia. --Great Brightstar (talk) 13:20, 15 January 2019 (UTC)[reply]

Done -- /Alex/₂₁ 13:06, 20 January 2019 (UTC)[reply]

Revert

The recent change seems to have introduced unintended formatting changes. In all articles I looked at which used this template, the first letter was lowercase. Also, in Beta-Hydroxy beta-methylbutyric acid#Biosynthesis, it introduced line breaks before and after where the template was used in 2 places. Seppi333 (Insert 2¢) 18:27, 27 January 2019 (UTC)[reply]

Changes needed from results of TfD (part 3)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

I made a new implementation in the sandbox, which rely on new TemplateStyles created for this template, please review it. --Great Brightstar (talk) 12:53, 7 September 2019 (UTC)[reply]

Technical note: I temporally suspended this request as I have edited the sandbox afterwards. I suggest Great Brightstar reverts to their proposed sandbox version in there. -DePiep (talk) 12:58, 7 September 2019 (UTC)[reply]

And this is my review of the proposal: not a good idea to implement an unresolved TfD from 2012 seven years later.

Functionally, as documentation shows the template tries to cover too many situations, some of them explicitly not applicable for this wiki.

The templates needs a redesign for its functionalities, and simplified both technically and re usage. Maybe a merge with {{Smallcaps2}} is feasible. (tbh, the intricacies as described in the documentation are extremely difficult to get -- by simple editors and by experienced typogtraphy editors). -DePiep (talk) 13:03, 7 September 2019 (UTC)[reply]

OK I fixed that, please review again. --Great Brightstar (talk) 13:57, 7 September 2019 (UTC)[reply]

Cancelled edit request: no consensus

re Great Brightstar: I cancelled the (good faith) editrequest because there is no consensus.

To be clear: before posting an editrequest like this, one is expected to gain consensus re the change. Above, I already explicitly objected to the change. I wrote not a good idea to implement an unresolved TfD from 2012 seven years later (the documentation i.e. editor's approach page is toooo complicated).

I propose to redesign all {{smallcaps}} templates from scratch. First decide on the documentation (= functions to be provided to editors, and easily so), then simplify the set (recode, merge). Do we really need three smallcaps templates? And all their options? -DePiep (talk) 19:26, 7 September 2019 (UTC)[reply]

Span nesting

(repositioned into new section DePiep (talk) 12:56, 7 September 2019 (UTC))[reply]

Current version produces

 UNESCO

i.e. span twice.

Propose changing to {{Smallcaps all/sandbox}}. -DePiep (talk) 12:48, 7 September 2019 (UTC)[reply]

Template-protected edit request on 30 September 2019

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

I made a new implamentation in the sandbox page, the new source codes doesn't affect the visual apperance, but has more improves, first, if the second parameter is used, it would allow some exceptions for "DiCaprio", "McDonald" etc., second, it doesn't permanently change upper- or mixed-case data, as all letters are transformed with CSS properties instead of parser function, relys on the TemplateStyles differ from {{Smallcaps}}. If you have any problem, feel free to talk. Great Brightstar (talk) 13:50, 30 September 2019 (UTC)[reply]

(ec)In Template:Smallcaps_all/testcases, the DiCaprio testcase differs, new McDonald's is also weird. I still don't get what the two parameters aim to achieve. Why not a single template with option |uc=all or ucfirst, and let the editor enter uc/lc in the input as wished. Also, still don't understand why there should be three smallcaps templates. -DePiep (talk) 14:07, 30 September 2019 (UTC)[reply]

I don't think the font-variant is the right way to go: it changes the font'. Typographically (visual design), rarely acceptable. -DePiep (talk) 14:11, 30 September 2019 (UTC)[reply]

@DePiep: Regarding merging into a single template, why? Merging those would require a lot of bot work and 3 distinct templates work just as well as 1 multi-purpose template. It would also require regular users of these templates to learn what parameters values to use for their intended use (currently, none are required); changing the implementation of programming functions (e.g.,, templates/modules on WP) tends to annoy end-users for that reason.

I can’t comment on the edit request right now since I’m currently limited to editing on my iPhone (which I hate using for this purpose) for the next 24 hours due to a borked laptop AC adapter. Seppi333 (Insert 2¢) 20:04, 30 September 2019 (UTC)[reply]

The problem is that this template cannot even describe its own job. The /doc is useless, outdated, and horrible. Let alone the diff with the other two. Why at all do we need this one? And again, changing font is not a good idea here. (Sure the mess cleanup would take a lot. A cleanup it is). -DePiep (talk) 20:11, 30 September 2019 (UTC)[reply]

The documentation of all 3 templates might be poorly written (in which case, the documentation should be updated, not the template code); but, that doesn’t change the fact that they all display text differently. Just look at how the first letter renders with sc, sc2, and smallcaps all (respectively): L L L. Seppi333 (Insert 2¢) 20:20, 30 September 2019 (UTC)[reply]

"Just look how ..." -- that is exactly the problem. Not me investigating, the /doc should say that beforehand and explicitly. It's not poorly written, the /doc is disfunctional. Even now I cannot grasp what this template does or says it does, and I refuse (having) to research it myself. How can I check the changes proposed? Against what functional promis? -DePiep (talk) 20:32, 30 September 2019 (UTC)[reply]

The edit, in wider context, is disputed so I pause the edit request for now ("answ=yes"). -DePiep (talk) 20:36, 30 September 2019 (UTC)[reply]

The acceptable uses of the smallcaps templates is covered in MOS:SMALLCAPS. Also, I honestly think the table in the documentation is pretty clear about the distinctions between sc, sc2, and smallcaps all. Seppi333 (Insert 2¢) 21:04, 30 September 2019 (UTC)[reply]

Ayway, I object to this proposed change because the DiCaprio test fails. -DePiep (talk) 21:08, 30 September 2019 (UTC)[reply]

@Seppi333: I tested again at the test cases, the DiCaprio test succeed if I insert the pipe after capital letters, and all capital letters were included in the first parameter, so I suggest the documentation can be updated if the new source code is accepted at the main template. --Great Brightstar (talk) 09:56, 2 October 2019 (UTC)[reply]

I don't have any objections at present. Unless DePiep has an actionable objection, I'm fine with implementation. Seppi333 (Insert 2¢) 10:28, 2 October 2019 (UTC)[reply]

Go ahead as you please, It's just that in the future a full redesign might still be done (i.e., no prejuduce in this change). -DePiep (talk) 11:34, 2 October 2019 (UTC)[reply]

Mothly error report available

BTW, I have added Templatedata. So for the October 1 wikipedia database, a full usage overview' of this template will be available shortly (listing mainspace instances, and their parameter use). See the link "monthly error report". Available ~Oct 5. -DePiep (talk) 11:38, 2 October 2019 (UTC)[reply]

@DePiep: I viewed the mothly error report, there are only 21 articles uses this templates with all two paremeters, and all of them using one letter at the first paremeters. I also reviewed all these pages with their source codes. So I can conclude it's safe to update the template. --Great Brightstar (talk) 05:18, 4 October 2019 (UTC)[reply]

Nice. -DePiep (talk) 06:40, 4 October 2019 (UTC)[reply]

Deprecated Status

Should this template’s deprecation entail delinking references to it from other template pages? It seems like it ought not be promoted under “See Also” sections of other templates like smallcaps. Pedantical (talk) 01:32, 10 April 2023 (UTC)[reply]

Support such removals. I stil have not found any use or MOS-reference for this forms (mixed case in smallcaps?). Does TfD require prior MOS discussion? DePiep (talk) 05:10, 10 April 2023 (UTC)[reply]