# Wikisource:Scriptorium/Help

## Interwiki to Translation namespace not appearing

According to https://www.wikidata.org/wiki/Q2898441, the page Translation:Tikunei_Zohar is linked to its source language he:s: page https://he.wikipedia.org/wiki/%D7%AA%D7%99%D7%A7%D7%95%D7%A0%D7%99_%D7%94%D7%96%D7%95%D7%94%D7%A8 However, althought the link appears in the he: page, it does not appear on the en: page. unsigned comment by Nissimnanach (talk) 16:18, 12 February 2021.

## Guidance on sic/SIC

Last night in relation to a page of potentially "duplicated words" in Page: namespace content I checked what sic and SIC currently did.

As a result of this, I found that {{sic}} doesn't display anything (meaning that any parameters supplied to it are ignored.), whereas SIC does.

In follow-up to this , I used AWB to update a considerable number of usages from {{sic}} to {{SIC}}, with the intent to review every single edit thus made against the relevant scanned page. I'm starting to review the 500 or so edits made as a result of that usage update this morning.

In reviewing the first few pages where the usage was updated , I am finding that where I am seeing the hi-res scans (thanks to a script User:inductiveload provided, that the nominal SIC did not exist in the hi-res version, (suggesting some of them are not actually present in the original scans and are an artefact of the coversion/display process for PDF /Djvu etc.)

In places has been used to add transcriber comments, I've generally attempted to avoid updating those usages in error, (and will be checking for situations where this may have happened by mistake on my part.)

However before continuing , I'd like some feedback...

1. Is the consensus to leave words duplciated in (printer) error as printed but marked {{sic}}, or place the duplicated word inside {{sic}} to suppress their appearance?
2. Should sic or SIC that do not appear to be present when better or higher quality scans are used, compared to when the Page: was originally proofread or validated, be updated or removed?
3. Where a SIC has been provided without a correction, but a contributor can suggest an obvious one, should such as correction be added? ( I am aware that certain other sorts of annotations are discouraged.)?

ShakespeareFan00 (talk) 07:28, 8 July 2021 (UTC)

1–3 no. CYGNIS INSIGNIS 14:24, 8 July 2021 (UTC)
1) Words that are duplicated in the scan should be duplicated in the transcription. You should not put the second word inside {{sic}} to suppress its appearance, but you can put {{sic}} next to it or do something like {{SIC|the the|the}}. 2) if the scan is updated and there is no longer any error in the scanned text then the transcription should be updated to match the scan; since the error is thus removed, {{sic}} or {{SIC}} should also be removed to avoid confusion. 3) Yeah, go for it (while being mindful of WS:ANN and maintaining consistency throughout the transcription) —Beleg Tâl (talk) 21:38, 8 July 2021 (UTC)
Thanks, that concurs with the approach I had been taking. Of course checking over 10,000 uses of SIC against scans may take a while.ShakespeareFan00 (talk) 23:18, 8 July 2021 (UTC)
I will also note on one or two entries I converted from sic to SIC recently, that the SIC appeared to be a British vs American spelling, so NOT a SIC as such, but a correct spelling, typsetting for a UK vs US edition. :) ShakespeareFan00 (talk) 23:18, 8 July 2021 (UTC)
Note that I tried adding some SICs on duplicated words and they were undone with the message of basically "don't touch validated texts" and so I basically decided to stick away from doing anything besides obvious errors on validated texts ¯\_(ツ)_/¯. MarkLSteadman (talk) 20:41, 9 July 2021 (UTC)
I've seen {{SIC}} used on obsolete spellings as well. I personally would remove {{SIC}} from such places where it is a deliberate use of an alternate or unusual spelling, rather than a typo. But you don't need to do that if you don't want to. —Beleg Tâl (talk) 00:59, 10 July 2021 (UTC)
Comment Further to Beleg Tâl's commentary
• {{sic}} is the old old form that existed for when we did not have proofread page where it was clearly needed to indicate that the produced error was replicating the produced work where no scan existed.
• With ProofreadPage, the use of {{SIC}} is more indicative than normative and it is to basically indicate "don't bother ..." We have no compulsion to its use. It should only ever be used to indicate clear errors. It should never be used when they are variations in spelling, or ye olde forms of reproduced text. It should only be used to show outliers, if a word is used repeatedly in a way in a work, then it should be bleeding obvious that it is not an error. If someone has chosen to not use it, then I would generally not then start using it. If someone is using it, then I would generally leave it in. If someone has only one parameter, I would leave it that way, if the word is obvious to you, it is obvious to the other person. Remember that it is to indicate an error for proofreading purposes.
I think that it would be an absolute waste of time to specifically go and check the usage of each. They will be checked and reviewed during proofreading, and that should be sufficient. Their use is a nicety, and of low value to prioritise. — billinghurst sDrewth 07:19, 10 July 2021 (UTC)
Re what Beleg Tal said, if it was "deliberate" but could use clarification by way of annotation, {{SIC}} is the wrong template, the comment should be in a {{tooltip}}, {{definition}}, {{abbr}}, or in a reference with {{user annotation}}. Sic is rather, by definition of the term, specifically to indicate that the text isn't a transcription error (made by us), but instead we are copying verbatim what appears to be an error in the source document being transcribed. And yeah, often {{SIC}} itself is the error, it's just a variant spelling. Jarnsax (talk) 17:00, 29 July 2021 (UTC)
IOW, if the source document says "robbed the teh bank", the reader should see "robbed the teh bank", with an indication (from {{SIC}}) that the apparent mistake is not our error. (theoretically, the same could apply if the text said something so nonsensical a reader would assume it's our mistake). Jarnsax (talk) 17:15, 29 July 2021 (UTC)
I only use the hidden {{sic}} indicating to subsequent editors that the anomaly was noted.— Ineuw (talk) 19:33, 21 August 2021 (UTC)

## Just wondering ...

Understanding there already is a page dedicated to this particular book, I had hoped to inquire how I might, or even if it were possible, to submit a different edition of the same. I am presently in the progress of compiling with a few minor edits Gaston Leroux's « Le fantôme de l'opéra » from the original newspaper serials, and had hoped to share both these, and my future translation with the site, as indeed there are some slight differences in the story between the serials and the later book-form of the story.

## How to handle major printing error (swapped lines)

I was proofreading Page:Left-Wing Communism.djvu/39 and was struck by how nonsensical the sentence in the first paragraph starting "Probably some members of the Dutch Communist..." was. And then I realized there's a major printing error here - the second and third lines of this sentence are pretty obviously swapped. Is there any leeway around here for fixing this? My main concern here is that, unlike a normal misspelling typo, this error renders the sentence pretty well unintelligible as written. — Dcsohl (talk)
(contribs)
15:11, 17 August 2021 (UTC)

To clarify: The paragraph beginning "On the one hand, men …" has sentence 3 [When, in face of …] and 4 [Probably some members …]. It is suggested that this translation of [logical defying diatribe] by Vlad [Hecatombs] Lenin has inadvertently reversed sentences 3 and 4? CYGNIS INSIGNIS 17:25, 17 August 2021 (UTC)
@Dcsohl: Please see my solution at diff. I prefer solutions that reproduce what the text ideally should look like in the case of printing/typographical errors because I have a feeling it helps certain kinds of readers/scripts process the information properly. PseudoSkull (talk) 17:33, 17 August 2021 (UTC)
Yeah, that's not bad - I just wish {{SIC}} worked better in e-readers. (In my experience you get the underline with no way of seeing what the "corrected" text is.) — Dcsohl (talk)
(contribs)
17:39, 17 August 2021 (UTC)
No, sorry, I can see I was unclear. I'm suggesting that the 10th and 11th lines in the scan (which start with "into traditions and conditions" and "Party who had the misfortune") should have been swapped. In other words, that the sentence as a whole should read "Probably some members of the Dutch Communist Party who had the misfortune to be born in a small country, into traditions and conditions of particularly privileged and stable legality, who have not known at all what it means ....." — Dcsohl (talk)
(contribs)
17:35, 17 August 2021 (UTC)
Page:Nytimes autosforfrenchrace 1906.png has a similar issue, where a couple lines of a sentence were inserted into the next paragraph (in the middle of a word, even!). My solution was to comment those lines out where they appear on the printed page, add comments delineating the insertion in the correct location, and add a footnote explaining the error. —CalendulaAsteraceae (talk | contribs) 18:26, 21 August 2021 (UTC)
I'd say I disagree with this decision, because I think our general consensus here has been to include all typos or errors in a given text, unless it is due strictly to a technical limitation that was faced in the printing industry, which would make it not erroneous on the publisher's part. Technical limitations would include, for instance, the use of a black and white, low-quality facsimile version of a painting rather than presenting it in color, in order to save money, etc. (Example: Resurrection Rock (1920)) Another example would be using the letter "f" instead of "ſ" when quoting from older texts, because of a lack of typewriter that could produce said symbol. (Example: Southern Antiques)
Inserting text in the wrong place, however, isn't due to a technical limitation like the examples above—it's a legitimate mistake. But it's not really a big deal, so I digress. PseudoSkull (talk) 18:45, 21 August 2021 (UTC)
That makes sense, and it is a meaningful distinction. With a little more thought, I figured out a way to make the {{SIC}} approach work in this case. —CalendulaAsteraceae (talk | contribs) 20:31, 21 August 2021 (UTC)
@PseudoSkull … and this is precisely the sort of thing I was thinking when I first came across this error. It’s clearly not the author’s intent, and much as we don’t strive to reproduce printer’s marks (as an artifact of printing rather than the author’s output), I’d expect one could make an argument to fix obvious mistakes that arose from printing, like here. But of course then come the blurred lines and the places where maybe the intent isn’t crystal-clear, so I can also appreciate the argument for just leaving as is and using {{SIC}}… hence my intent in starting the discussion. — Dcsohl (talk)
(contribs)
20:37, 21 August 2021 (UTC)

## Greek with popup romanization?

Working from scanned text where the OCR (?) dropped the Greek characters but helpfully substituted a romanized transcription of some Greek characters. It gave me:

... and so received the title "[Books of] the Omitted Acts" ([Greek: paraleipomenôn]) or "the Omitted Acts of the Kings (or Reigns) of Judah."

I first substituted {{greek|παραλειπομένων}} to get παραλειπομένων.

Then I thought it'd be nice to somehow keep that phoneticization "paraleipomenôn". Using {{polytonic|παραλειπομένων|yes}} gets me a link to a wiktionary entry with romanization παραλειπομένων (but not a good link - wait and let it redirect from the semi-bad URL)

It would be 'nice' if there was a template that'd allow displaying the Greek with a popup with the romanization, something like

{{greektweek|Καλημέρα|Kaliméra}}

that would result in something like Καλημέρα.

Anyone know of something like this? Shenme (talk) 22:32, 23 August 2021 (UTC)

I just read that recently and messed with one today. The polytonic template recommends wrapping it into a span. <span title="romanized word">{{polytonic|greekish}}</span>, this span, however, conflicts with setting polytonic to yes for the wikitionary, and wikttionary wins.
After I saw the wiktionary link in polytonic, I started to remove polytonic from math problems. I have been also thinking about using entities &pi; for instance (or TeX's \pi because, I am pretty sure that the entity was made for math and not for the Greek alphabet and math shouldn't ever be linking to wiktionary. Is this considered to be wrong in any way?--RaboKarbakian (talk) 22:51, 23 August 2021 (UTC)
I would definitely try to dissociate math from {{polytonic}} or {{greek}}.
Using the HTML entities is likely best. The HTML entities like &Gamma; Γ will resolve to the Unicode range for plain Greek characters. This then is simply reusing the plain Greek characters for math.
Entirely separately there is a Unicode block for Mathematical Alphanumeric Symbols block which is assigned to one of the newer Unicode blocks. Well, new as in assigned in Unicode version 3.1 (2001). Current is version 13 so these ought to be safe to use everywhere now. (maybe)
But there are no entity names for these so...
• &#x0393; Γ (from the original Greek char block)
• &#x1D6AA; 𝚪
• &#x1D6E4; 𝛤
• &#x1D71E; 𝜞
• &#x1D758; 𝝘
• &#x1D792; 𝞒
That's pretty icky, so start out with plain entities &omega; ω until something else forces a change? Shenme (talk) 04:04, 24 August 2021 (UTC)
I'm not sure I understand what you mean. The plain entities reference the characters from the plain Greek text block, which are the ones to be used for plain characters in mathematics. There's no need to use the entity names instead of just the plain characters.--Prosfilaes (talk) 10:15, 24 August 2021 (UTC)
I think it should be that unicode references the entities, at least some of them; they existed when unicode was just a good idea. And that they were first made for computers as math characters is the reason that they need to be eh, "told when to behave like letters of words". The main reason that I use entities (with the exception of the dashes) is ease. &pi or \pi can be created from a simple keyboard, reducing the "hunt and peck" nature of unicodish. And, if your browser is configured for unicode, they are unicode. If your browser is configured for something else, they are π or ${\displaystyle \pi }$. Unicode won some correctness wars and we now have a plethora of moody smilies for the win of that war. Anyways, I agree with @Shenme: to not use the {{polytonic}} for math in electronic documents, as math usage is the reason they render so badly for language usage.--RaboKarbakian (talk) 13:52, 24 August 2021 (UTC)
Unicode's first release was in 1991; HTML's was in 1993. HTML has been defined in terms of Unicode since RFC 2070 in 1997, and MediaWiki doesn't support any browser before 2011. If you can access and use Wikisource, Unicode text and the entities will appear exactly the same.--Prosfilaes (talk) 16:21, 24 August 2021 (UTC)
Initial mention was in reference to using {{polytonic}} for simple Greek characters. I'm agreeing that that shouldn't be done for math (unless you like that font). Above I was mainly intrigued with the existence of a math-specific Unicode block, thinking Unicode was wanting to indicate math usage, but they don't include/duplicate the plain Greek characters.
"Mathematical Alphanumeric Symbols is a Unicode block comprising styled forms of Latin and Greek letters and decimal digits that enable mathematicians to denote different notions with different letter styles."
So you are correct that &Omicron; == "ω", so they are interchangeable. If you don't want the 'styled' variants for math symbols, ignore Unicode's Greek emojis. They've gone overboard again on Greek, like I did above. Shenme (talk) 13:13, 24 August 2021 (UTC)
A pop-up romanisation would be an annotation, so only to be done on an annotated version—which assumes that we have a complete unannotated version already. In terms of tooltips as a method, these behave badly in ebooks and thus should be used sparingly—if at all. Beeswaxcandle (talk) 23:03, 23 August 2021 (UTC)

## Index:Rambles in Germany and Italy in 1840, 1842, and 1843.djvu

Hello, I need help to Create a pagelist for the source file before commencing proofreading (to verify file is correct). --Stamlou (talk) 16:56, 30 August 2021 (UTC)

Hello. I have noticed that page no. 2 is misplaced in the file (I did not check the rest). There is a file in HathiTrust which looks better. --Jan Kameníček (talk) 19:56, 30 August 2021 (UTC)

## Texts/books etc

I want to create new material but i can't find anything Google books, nothing. Help? Thank you. Lutzbaer0 (talk) 08:25, 4 September 2021 (UTC)

what exactly are you looking for? Wikisource:Sources has a list of places you can search for a book. Or if you let me know what you're looking for I can try to find a copy. Inductiveload 08:38, 4 September 2021 (UTC)
just looking for new texts that ws will accept. I want to find book search etc, sorry if I'm confused you. Lutzbaer0 (talk) 08:40, 4 September 2021 (UTC)
the Internet Archive is usually the easiest source for books. However there are (literally) millions of books there, of basically every type imaginable, so it helps to have an idea of which books you are interested in. If you have a book at the IA, you can upload it with IA-Upload.
There are also books others have requested at Wikisource:Requested texts and there's an monthly collaborative text called the Monthly Challenge.
If you find a text you would like to upload scans for and need help with that, let me know, I'll be happy to help (anything to sucker in new Wikisourcerers! 😈) Inductiveload 09:13, 4 September 2021 (UTC)

## Want to Delete

I carelessly created a topic (ပုသိမ်_ဗကသညီလာခံ_သခင်ကိုယ်တော်မှိုင်း_မိန့်ခွန်း) on en:s although my intention is to create on w:s. I am new in editing and don't know where is the Delete button. Could someone help me to delete that topic? P0rnytail (talk) 16:53, 9 September 2021 (UTC)

Done (you don't have a delete button: only administrators can delete pages). Have fun at myWS, but please come back and edit with us if there are any Myanmar-related works you would like to see! We don't have many right now, and I'll be happy to help: you could even nominate some for our monthly challenge. :-). Inductiveload 17:01, 9 September 2021 (UTC)

## Help with Scores

Index:The book of American Negro spirituals.pdf has about 100 pages of musical scores. Is there anyone who can transcribe them? Languageseeker (talk) 05:31, 11 September 2021 (UTC)

Just mark the pages as {{missing score}} and when and as I have time I'll deal with them. The backlog of scores waiting to be done lives in Category:Texts with missing musical scores. Beeswaxcandle (talk) 05:38, 11 September 2021 (UTC)

## Is it okay?

Hello, did I do this page correctly by not including the chapter title in the header, but in the body? or not? 09:05, 11 September 2021 (UTC)

Yes, that is correct. --Jan Kameníček (talk) 09:16, 11 September 2021 (UTC)
Alright. Thanks. 12:24, 11 September 2021 (UTC)

## Template {{center inline}} not showing up in category "Special effects templates"

One problem with searching for templates is when templates don't show up in categories. Just yesterday I finally noticed template {{Center inline}} is not showing up in Category:Special effects templates. Template {{Center}} does show up.

When I first looked at it {{Center inline/doc}} had

[[:Category:Special effects templates|Template:Center inline]]

which I changed to

[[:Category:Special effects templates|Center inline]]

and since have changed to

[[:Category:Special effects templates|Center]]

Just for reference {{Center/doc}} has

[[Category:Special effects templates|{{PAGENAME}}]]

In addition I've tried various purge dances, and waited half a day and still no mention of Center inline at Special effects templates. Do I need to step up from winged to four-legged sacrifices?

HMMM, this's interesting. It does show up at [[:Category:Span_based_templates]], but _only_ as "Template:Center inline/doc". Unlike almost all others in that category which *also* have the base template listed. Definitely need to add eight-leggeds to the cauldron. Shenme (talk) 18:33, 11 September 2021 (UTC)

It must have been stuck cache or something. I tried purge, hard purge and null edit one after the other and it seems it helped. --Jan Kameníček (talk) 18:51, 11 September 2021 (UTC)
On... which? the template page, the template/doc page, the category page...? The only thing I'd not tried was the null edit. (BTW: thanks!) Shenme (talk) 19:30, 11 September 2021 (UTC)
@Shenme: I tried the category page and when nothing happened I tried the template page. However, I cannot say which of them proved to be the right one: it could have been the category page too, only with some delay. --Jan Kameníček (talk) 19:56, 11 September 2021 (UTC)

## "tag" is not "it" ?

So I'm trying to make sense of the WS templates, a "right of passage" I suppose. I came across a misuse of {{ref}} and so looked up that and {{note}} and then {{tag}} to see what they did. And found that {{tag}} was referenced from a bunch of template docs, which did not make sense.

It seems that {{tag}} is used in multiple docs in an attempt at 'quoting' HTML-like 'tags' like <nowiki> or <code> . Like {{tl}} and {{tlx}} are used for templates. But since {{tag}} is for something else the effect is a strange and unhelpful.

An example of problem converting to using {{tag}} is tlx/doc (look for "{{tag"), where for instance

<code><nowiki><code><nowiki>&lbr;{Anytemplate|arg1=23|size=250px|</nowiki><var>other parameters...</var><nowiki>}}</nowiki></code></nowiki></code>

was changed to

{{tag|code|content={{tag|nowiki|content=<nowiki>{{Anytemplate|arg1=23|size=250px|</nowiki><var>other parameters...</var><nowiki>}}</nowiki>}}}}.

with new display being

code

Oh, a mystery solved: w:Template:Tag, see docs there.   These usages assumed enWiki's template.

I'm wondering:

• could {{tag}} have been changed in some mysterious way after George starting using it?
• is there a template _here_ that will 'quote' HTML-like tags?
• if not, should we copy enWiki's template for use here, and under what name?
• should I go clean up these wrong usages so that the docs look correct again?

Shenme (talk) 19:34, 12 September 2021 (UTC)

## cstyle parameter of the Freeimg template is not working

Please see this page in edit mode. I placed {{Dhr}} above it instead. Page:Africa by Élisée Reclus, Volume 1.djvu/159— Ineuw (talk) 22:16, 12 September 2021 (UTC)

The problem is probably in some edits by Inductiveload, so I am pinging them to have a look at it. BTW, is it necessary to keep moving big parts of templates to modules in lua? The number of contributors who understand the templates gets significantly smaller by that. While I understood the original template’s code quite well, I do not understand the module at all. Are the modules’ advantages really so big? I am quite afraid that we are heading towards the situation when we will be absolutely dependent on only few people understanding the modules who we will have to ask for every triffle, not mentioning the situation when the few people stop contributing or decide to go for a wikiholiday… We are a small project and such a situation is not unimaginable. --Jan Kameníček (talk) 22:42, 12 September 2021 (UTC)
Personally, I have no problems with the template because I grew up with it from it's introduction by George Orwell III. I am sure that Inductiveload has a good reason for the changes.— Ineuw (talk) 22:53, 12 September 2021 (UTC)
I do not see a problem in the fact that you or some other specific person understands/does not understand a code of a specific template. I mentioned the trend to have too many things in lua because it makes the overall number of contributors who understand the codes of templates much smaller. --Jan Kameníček (talk) 23:04, 12 September 2021 (UTC)
I gave a fuller answer before but it got smashed out in an edit conflict. Long and short: template style {{FreedImg/styles.css}} contains existing (line 5) margin-top: 0.40em !important; (and always had going back effectively forever!) so no override may omit its own !important or it will be ignored by the rendering browser. 110.21.131.174 00:20, 13 September 2021 (UTC)
So, what you are saying is that margin-top and bottom are useless? — Ineuw (talk) 01:44, 13 September 2021 (UTC)
@Ineuw: The question is ambiguous. If you mean in analogy to template parameters margin-left and margin-right; the template simply does not have -top or -bottom parameters and a change to this LUA module would be required to add their support.
On the other hand if you are asking how to form a valid cstyle override which will work look no further than this change.
I hope that is what you were looking for? 110.21.131.174 03:19, 13 September 2021 (UTC)

┌─────────────────────────────────┘
Thanks. That is what I was looking for. But there is an anomaly. The template has left and right margin codes without " cstyle = " as in

 | margin-right = .5em
| margin-left  = .5em


But this requires "cstyle = " and which doesn't work without !important

| cstyle       = margin-top:2em; !important


Since margins are external to the container, it should not be restricted to a fixed dimension. Make the old fixed dimension the default, and let users specify any margin. — Ineuw (talk) 03:43, 13 September 2021 (UTC)

Umm. Two things:
• Please note the keyword is exactly "!important" and as such must appear before the semicolon in CSS - so your example should read:
| cstyle       = margin-top:2em !important;

• What you are proposing (about the container margins) makes sense to me but I am not the one you need to convince. Module:FreedImg seems to have concentrated all the logic concerned and the only person to edit that has been friend Inductiveload… Please form an orderly line: a small sacrifice may be appreciated but a humble request might be a good start? (I would not know as I am not they.) 110.21.131.174 04:05, 13 September 2021 (UTC)
I have no intention of making a request. I just thought to mention it. I can live with separate spacing until it will be corrected, when it will be corrected.
On the other hand, you seem to know what you are talking about. If you want to help, then sign up and take an active part please. I would be more than happy to test a simplified version in my namespace if it helps the community. After all, the original version was recommended to me by GO III when I had a lot of problems with floating images and seamless text wrap in PSM.— Ineuw (talk) 05:13, 13 September 2021 (UTC)
@Ineuw: as @110.21.131.174 says, the problem here is the !important on the margin-top rule. This dates right back to when the CSS came from site-wide CSS now archived at here (note that since interface admin rights have been introduced, there original page at Mediawiki/Dynimg.css was editable only interface admins).
I do not have any idea why the !important was specified, but I can only assume it was a "hack" to achieve something so I left it as-is. Thus, it is not related to the "module nature" of the template. But I will have a look and see if I can remove it without exploding anything.
As for the reason {{FI}} got "modulified": the template as-was had two major problems: over-complex HTML that worked badly in some situations, and, much more critically, it loaded the full-resolution image unconditionally, regardless of the image size. The primary "feature" of the module is that it reads the image size and then constructs a reasonable image size to load that is not larger than that. It's not a major concern in this case, as the image is small, but there are examples on Template talk:FreedImg where the images were between 10 and 300 (yes, three hundred) times the size they needed to be. This resulted in things like ~100MB book sizes (both on the web and in exports)
As far as I know, the logic to do this in pure templates is impossible. Even if there was an {{#imgsize}} magic word (or a wrapper template), the logic to derive an appropriate width would be fiendish.
In general, there are a handful of reasons a template gets a module to provide logic:
• The logic is (or would be) very overwrought in template-mode. For example
• {{FI}}'s width logic
• massively complex (and, in places, wrong) constructions in the old {{header}} (which actually still defers to a template {{Header/main block}} for the main layout code which is clearer as a template). {{article link}} is another example where the logic was very complex in template-mode (and I should know, since I wrote the template in the first place!).
• Another example, that I just fixed: Special:Diff/11686847 is in a template that's almost entirely impenetrable and has thus been hiding a typo in the braces for 6 years.
• And while fixing that, I discovered {{Is year}}, which is...interesting.
• when the template has an undefined number of arguments. There is no "for-loop" construct in template-mode, so you have to copy-paste entire blocks n times and hope no-one needs more.
• The template needs access to Wikidata and also needs to make decisions based on what it finds (so {{#statement}} will not cut it. E.g. {{authority control}}
• Template mode is substantially more expensive to render and starts hitting limits: E.g. {{ts}}
• The template needs access to Lua or JSON data (e.g. much of the Monthly Challenge infrastructure reads from data tables to construct the statistics).
• The template duplicates logic that a template provides - a template can call a module easily with invoke, but a module has to pass a frame object to a call to expandTemplate, so it's sometimes much easier if the logic lives in a module that can just be imported.
There are actually not that many general templates that have module logic. Certainly, if a template is simple enough, it should indeed stay as a template if it can. Inductiveload 06:30, 13 September 2021 (UTC)
@Ineuw: I have removed the !important from Template:FreedImg/styles.css. I don't see any obvious breakage (or a way it could obviously break), but please do let me know if you see anything wrong.
Also note that if you want the same formatting for all {{FI}}s in a work, you can now also use:
.wst-freedimg {
margin-top:4em;
}

in the index styles.css subpage and it will automatically apply to all {{FI}}s therein. Inductiveload 08:30, 13 September 2021 (UTC)

Again, thanks. I noticed it. — Ineuw (talk) 17:37, 15 September 2021 (UTC)