Commons:Created by… templates

Commons contains more than 100 templates dedicated to indicating how images were generated, displaying that information in file descriptions and categorizing the pages accordingly. As of October 2024, most of the work behind these pages was done by Sarang (talk · contribs · count · global contribs), a contributor who was extraordinarily prolific on Commons until he left this world in 2023.😔 Although Sarang put enormous efforts on documenting, Dieter was German and his English skills were rather limited to write technical documentation. Moreover, his talent/experience in template functional architecture and/or for designing accessible user experience/interfaces was limited when he started his journey here and he largely worked on his own here. Even though his MediaWiki/Wikitext technical skills were great, his code was at times "impressively complicated" (a fact in which he may have found some pride)🙄. His constant use of cryptic edit summaries (as in this change adding a whole section promoting one of his templates, which he nevertheless marked as a minor edit) also made collaboration particularly hard.

As a result of his characteristics, of his willingness to serve contributors regardless of their languages, of his willingness to provide very powerful tools, the limited help he got and his death, and the high level of authorization we require to modify many of the problematic pages, Commons is left with a large number of interrelated (sometimes redundant) templates, many complex (not to say cryptic), which may resemble a passed on puzzle. The templates are difficult to understand for artists (regular contributors), even harder for template designers, and can even puzzle end-users (simple readers). Even page names contribute a lot to confusion.

I have already done over 200 edits to fix and clarify parts, and will do my best to help with the particular problem I stumbled upon, but I feel this is just the peak of the iceberg and this situation will endure for a long time since I am not a regular here, don't master template syntax and don't have the permissions required to work efficiently and the effort needed would be massive. As I was just coming here to get a Netscape logo and already spent weeks opening this can of worms, I rather briefly (update: somewhat🙄) document what I found to ease the path for others. --Chealer (talk) 2024

SVG validity

Sarang spent huge efforts to document the validity of SVG files, to identify invalid files. He notably changed Created with... templates to show information about SVG validity by default. Confronted with pushback, he gave several reasons for this emphasis, some good, and the situation persists as of October 2024.

Scope

1. The ~80 tool-specific SVG created with ... templates, such as {{Created with Inkscape}} and their corresponding categories
   1. {{I18n/othertool}}
2. Created with ... I18nTemplates (~59 templates such as {{Created with .../en}})
3. Created with:I18nTemplates (~54 templates such as {{Created with/en}})
4. {{Created with ...}} (dummy template)
5. {{Created with}}
   1. {{Created with/layout}}
6. {{SVG created with/doc}} (meta-template for generating documentation for the templates in #1)
7. The cryptic {{Image generation}} and its numerous subtemplates
   1. {{File generation description}}, the clear wrapper around it
   2. Module:Igenmod
   3. Module:IgenCoa
   4. {{COAInformation}} (which Sarang did not create but seriously complicated)
   5. The cleanup and simpleSVGcheck scripts
8. SVG validity material
   1. {{SVGvalid}}
      1. {{InvalidSVG}}
         1. {{Valid SVG}} and {{Invalid SVG}} (this is no mistake; all of these templates are actually different)
   2. Several images with information on validity (including some quite unclear, like File:Inkscape-ws.svg)
   3. {{ValiCat}}
9. The Anti vector graphics program logos category and its few tens of files
10. SVG "simplification" material
    1. SVG simplification techniques and its numerous sub-pseudo-categories
    2. A few made-up images purely created to illustrate these techniques, like File:SVG example Z.svg, used in SVG simplification by elimination
    3. SVG Simplified and its numerous sub-categories
    4. Large SVG files (and sub-categories)
    5. {{SimplSVG}} and {{SimplSVG-st}}
       1. {{Created with Text Editor}}
       2. {{Redrawn with Text Editor}}

Sarang suggested merging #2 and #3.

More of Sarang's templates

Some of the secrets

A few partial and rough maps of this maze:

• Category talk:Created_with ... I18nTemplates
• Template talk:Created with (introduction)

The best way to document the architecture would be a diagram, but for want of that, here is a list of templates used when calling―for example―{{Created with Inkscape}} in English:

1. {{Created with Inkscape}}
2. {{Autotranslate}} (and therefore Module:Autotranslate)
3. {{Created with .../en}}
4. {{Created with/en}}
5. {{Created with}}
6. {{Created with/layout}}

In parallel, some tool templates, including {{Created with Inkscape}}, call {{SVGvalid}}, which itself conditionally calls {{Valid SVG}} or {{Invalid SVG}}.

Discussion

So far, the issues with these pages were mostly reported/discussed in:

• Template talk:Created with
• Template talk:Created with Inkscape (the most important tool)

Visibility of unimportant things (e.g. code golfing templates, hidden categories)

Code golfing templates on a vector file, telling the user how efficient this hand-written code is, and not to overwrite it with a mere Inkscape SVG

There are many templates and categories that serve the special interests of a small number of SVG enthusiasts - mostly @Sarang. The quest of these contributors is to improve the code of SVG files - which does not correspond to any improvement of general interest. There is nothing wrong with that, but it should happen under the radar of everyone who does not care. Commons is a repository for media files, and not for code. Nothing should be demanded from users, to achieve aims that are not the aims of the project. Demanding too much attention is bad enough. But I find it even worse to discourage actual improvements using Inkscape. (If File:Wappen Leinfelden-Echterdingen.svg can be improved, then it should be improved - no matter if that increases the file size.)
In May I have brought up a similar topic: LOUD TEMPLATES (red, bold, big, warning symbols) (archived) --Watchduck (quack) 19:01, 12 September 2021 (UTC)

There are also categories for these special interests. (E.g. Valid SVG created with Inkscape-hand:Flags and SVG simplified flags in the normal category SVG flags.) They are a distraction from the normal subcategories. That is a general design fault of hidden categories. They appear separate and small on the categorized page (e.g. an image), but not in the list of subcategories. I suggest to fix that, so that all hidden subcategories appear small at the end of the list. They are hidden for a reason, after all. --Watchduck (quack) 19:57, 16 September 2021 (UTC) (copied and tweaked by Chealer)

I very much agree. Sarang's goal may have been noble, but the noise he generated trying to achieve it beggars belief. This should certainly not display except perhaps for editors.

I assumed the situation couldn't remain as bad as it was in that screenshot, but 3 years later, it is actually worse (although that's an accident resulting from a fix). And I just stumbled on an even worse case. The worst part here (instruction not to replace) is generated by {{Igen/sni}}, which is based on a much older template by User:Kingofthedead, {{NoInkscape}}.

To my surprise though, I found out that sarang himself held the same opinion to a certain degree. --Chealer (talk), October 2024 (UTC)

Action plan

SVG simplification techniques categories

The SVG simplification techniques meta-category and its numerous sub-pseudo-categories require considerable work. The first task is to decide whether that content should be kept on Wikimedia Commons or not. The techniques documented are definitely relevant for Commons, but in no way specific. The English Wikipedia (among other editions) does have an article about computer program optimization, which links to an extensive book on Wikibooks, but treating SVG optimization in such detail on Wikimedia Commons is unique. Do we have the manpower to fix and maintain these documents on Wikibooks, on Wikiversity, or in any Wikimedia project?

If this was to be kept on Wikimedia Commons, we should:

1. For each sub-(pseudo-)category:
   1. The category page should be converted into a regular page (at something like Commons:SVG simplification/subpage)
   2. The examples should be integrated into the page (using a gallery or a list)
   3. The pseudo-category should be removed from the categories parameter in Template:SimplSVG/doc
   4. The categorized images should be decategorized (unless 1.1 already does that).
2. Convert the meta-category into a regular page (something like Commons:SVG simplification)
3. Scrap the {{SimplSVG}} parameter(s) to categorize in these pseudo-categories
4. Delete the User:Sarang/SVG optimization pseudo-categories warning

The current approach to categorize files as examples is very hard to follow. For example, File:Flag colors of France -Template.svg was optimized in Sarang's September 2013 revision, whereas File:10x10 checkered board transparent.svg has a single―optimal―revision. Readers need to carefully check to notice that the Source field refers to a different page which contains the original, suboptimal page.

Even worse, readers have no specific information on how the file was optimized and/or which parts of the initial file were suboptimal. To use the first example from the first sub-(pseudo-)category as example, how the optimization of the checkered board constitutes an example of "simplification by avoidance" is far from clear. I find it just as hard to figure out how the same file optimization would constitute an example of "simplification by viewBox".

Perhaps the very first thing to do is to determine what all of these categories are about. Are their primary objective to bring attention to the issue and provide credits to the thankless and otherwise invisible work Sarang and a few others did/do? Or are these pages genuinely worth their bytes? --Chealer (talk) 6 October 2024 (UTC)