Template talk:SIC

This template is more succinct than that in the main wikipedia.

Bad word may be more understandable. Tabletop (talk) 13:13, 24 June 2017 (UTC)

Unfortunately when the text is copied, "Bad word" is what is picked up rather than "Good word". I think it would be better to display "Good word", if available, as is done in the French version of the template. The typical reader is not interested in all the printing faults, and the typical copy and paste is probably not either. Library Guy (talk) 15:39, 30 March 2020 (UTC) On reflection, I have to acknowledge that the present behavior is the behavior of "sic" usage in the printed world, but in that situation, the correct information is not supplied. So maybe the solution is an alternative template based on fr:Modèle:Corr. Library Guy (talk) 14:34, 3 August 2020 (UTC)

The purpose of the template is not to correct the work, instead to identify that the word(s) are displayed as per the published work. It is a philosophical difference. A correction is an annotation. Noting that the second parameter is optional, and many of us don't use it. — billinghurst sDrewth 04:56, 4 August 2020 (UTC)

I agree it would make more sense to display the corrected word and show the original mistake in the tooltip. — Omegatron (talk) 19:45, 3 August 2024 (UTC)

Default to Invisible?

Complete interloper here, but wouldn't it be preferable to change the behavior of this template so that if no parameters are supplied, it does not display {{{1}}} but is instead invisible to the end reader (a la the {{Sic}} template)?

If so, I believe this could be achieved by just adding a vertical bar in the final invocation of the first parameter:

. . . <!-- else -->|{{tooltip|{{{target|{{{1|}}}}}}}}| . . .

The full version of the template code would then be:

<includeonly>{{#ifeq:{{SUBPAGENAME}}|Modern|{{{texttip|{{{2}}}}}}|<!-- -->{{#if:{{{texttip|{{{2|}}}}}}<!-- then -->|{{tooltip|{{{target|{{{1}}}}}}|[sic] '{{{texttip|{{{2}}}}}}'|nodash={{{nodash|{{{3|}}}}}}}}<!-- else -->|{{tooltip|{{{target|{{{1|}}}}}}}}|[sic]}}|nodash={{{nodash|{{{3|}}}}}}}}<!-- -->}}</includeonly><noinclude> {{documentation}} </noinclude>

Hope I'm not suggesting something that has already been debated and decided against, but my opinion is that eliminating the chance of getting an ugly {{{1}}} in the middle of a text would be a good idea. Biggins (talk) 23:31, 3 August 2020 (UTC)

@Biggins: The purpose of {{SIC}} is to wrap the word and display that the word is as presented per the text, rather than being a poor transcription. We had situations where people were opening and correcting words that were presented as per the text; we also had situations where you went to correct words only to find out that it was per text, and not needing correction. If you wish for a silent presentation, then please utilise {{sic}}. There is no value in using SIC without parameters, so having it display nicely when incorrectly used doesn't seem to be of value. Of course, I could be misunderstanding what you are asking. — billinghurst sDrewth 04:13, 4 August 2020 (UTC)

@Billinghurst: ah, that makes sense. I think I was coming at it more from the point of view of a relatively new editor who might not know the difference, or would have to look it up a bunch of times to remember. To minimize visible errors (and new editor confusion), I do think it would make sense for an instance of the {{SIC}} template that mistakenly doesn't have parameters to basically act the same as {{sic}}. And while I agree that to the extent that we don't think the learning curve is that steep then the issue is moot, my personal preference would still be to just have a single sic template that acts like the {{sic}} template if it doesn't have any parameters, or allows for wrapping like the {{SIC}} template if it has one or two. But your comment helps me understand why it makes sense to keep them distinct, too. Thanks for clarifying! Biggins (talk) 04:44, 4 August 2020 (UTC)

@Biggins: I have emphasised in the documentation that one parameter is mandatory. — billinghurst sDrewth 05:06, 4 August 2020 (UTC)

Long S template support

I've just found out the template doesn't support the use of the long s template in the second parameter. The first one does support it.

tset, but tset Treebitt (talk) 08:04, 2 July 2024 (UTC)

The problem is that {{ls}} outputs a long S wrapped in a span, and it doesn't work to put spans inside the title element. {{SIC|t{{ls}}et|test}} expands to

<templatestyles src="Template:Tooltip/styles.css" /><span class="wst-tooltip wst-tooltip-dash " title="[sic]&#32;'test'">t<span class="typographic-long-s">s</span>et</span>

and {{SIC|t{{ls}}et|te{{ls}}t}} expands to

<templatestyles src="Template:Tooltip/styles.css" /><span class="wst-tooltip wst-tooltip-dash " title="[sic]&#32;'te<span class=&quot;typographic-long-s&quot;>s</span>t'">t<span class="typographic-long-s">s</span>et</span>

(or the equivalent with ſ in pagespace). —CalendulaAsteraceae (talk • contribs) 16:54, 2 August 2024 (UTC)

That makes a lot of sense, thank you! Treebitt (talk) 17:09, 2 August 2024 (UTC)

I think perhaps I am having a similar problem with trying to put {{sc}} inside {{SIC}}. I need to do this at Page:An_Exposition_of_the_Old_and_New_Testament_(1828)_vol_1.djvu/99 for the word "Lord" in verse 16. This should read Lord as it represents YHWH/Jehovah in the original Hebrew - and the previous edition [1] from which this one is drawn, displays it so in this particular verse, as do KJV Bibles (and various other translations such as RSV, NKJV, ESV, NIV). But {{SIC|Lord|{{sc|Lord}}}} does not work. PeterR2 (talk) 12:27, 19 October 2024 (UTC)

@Jonesey95: Since the last modification there is regression. {{SIC|,|;}} does not work inside {{Ppoem}} (2nd parameter = semicolon).

test<span class="wst-tooltip wst-tooltip-dash " title="[sic] '
;'">,

// M-le-mot-dit (talk) 11:24, 21 November 2024 (UTC)

Yes, that's a common problem explained at this en.WP Help page. The semicolon, now that it is not surrounded by other markup, is interpreted as a new line by the parser. I don't think I can work around it in the SIC template, since any nowiki tags that I insert are passed to the title parameter of the tooltip and output garbage. One workaround is to use {{;}}, like this:

Foo, bar

Someone else may have a better fix for the template, or a different workaround. It may also be possible to fix this problem within {{Ppoem}}, which is beyond my programming skills. That template is inserting a bunch of code that it inserts for new lines, which is understandable but wrong. Jonesey95 (talk) 14:46, 21 November 2024 (UTC)

Thanks for this workaround, simple and efficient. M-le-mot-dit (talk) 17:03, 21 November 2024 (UTC)

It seems that since this comment this has been fixed. Though not fully, as the long S preference gadget setting does not affect the characters inside tooltips, the glyph chosen currently only depends on the namespace, but still. Also, can the same fix be done to the hws/hwe templates, where the same issue is present? Treebitt (talk) 11:54, 21 November 2024 (UTC)

Yes, neither the Long S nor the Small Capitals display in the floating text ("Tooltip"). On the other hand the template no longer rejects them, it just doesn't do what we are trying to achieve with them :( . PeterR2 (talk) 13:43, 21 November 2024 (UTC)

Yes, though I would like to reiterate, that it does show the long S in the page namespace. Without the gadget, this would be fine, but with the gadget it should by all means display according to the setting in the sidebar. Treebitt (talk) 13:50, 21 November 2024 (UTC)

Underlining

The template stopped underlining the included words with dots, which I believe is an error caused by some recent changes. Pinging CalendulaAsteraceae. -- Jan Kameníček (talk) 23:24, 1 August 2024 (UTC)

I still see dots, and do not see any recent changes either to this template or to {{tooltip}}. Could you post an example? —CalendulaAsteraceae (talk • contribs) 16:50, 2 August 2024 (UTC)

For example here: Page:The Czechoslovak Review, vol3, 1919.djvu/310. The "C." in Ledbetter's name is marked with SIC, but there are no dots. I also considered the possibility that it is because of the combination with the link, so I experimented at Special:PermanentLink/14381496 where I marked the word "Broadway" in the first line with SIC (just for the sake of the experiment), and it is not underlined with dots either. --Jan Kameníček (talk) 21:53, 2 August 2024 (UTC)

Ohhh, this is the bug where when a stylesheet is first included inside a link, it doesn't work properly. —CalendulaAsteraceae (talk • contribs) 22:15, 2 August 2024 (UTC)