User talk:Sarang/Archive/2021

Errors

Sarang, can you look into File:7-segment dg.svg and File:7-segment efg.svg which use {{#invoke:Sarang/sandbox|led_segm|{{PAGENAME}}}}, which is not working right? --Jarekt (talk) 17:57, 3 January 2021 (UTC)

 Done :This section was archived on a request by: -- sarang♥사랑 09:34, 7 January 2021 (UTC)

mehrzeilliger text, zeilenhöhe, schriftgröße

hi: COVID-19 Health care limit.svg
gibts eine möglichkeit die zeilenhöhe (hier 36) als variable zu übernehmen?
usecase: schriftgöße wird nachträglich geändert und die zeilenhöhe der texte ändert sich automatisch mit
gefahr: komplizierterer code
ist das möglich und wenn ja ratsam? gesehen hab ich sowas noch nie --Mrmw (talk) 09:56, 7 January 2021 (UTC)

hoffentlich habe ich deine frage richtig verstanden - ​du meinst individuelle textattribute?

in deinem beispiel sind font-family und font-size als gruppeneigenschaft definiert. in jeder <text- oder <tspan-anweisung konnen attribute definiert werden, die nur lokal gelten; auch das uberschreiben von parentattributen ist moglich.

siehe als beispiel dafur Gerrit patchset 25838 test.svg, da musste ich bei langen farbnamen solche anpassungen vornehmen.

es ist hingegen nicht moglich, irgendwelche modifikationen des SVG-code von aussen in des angezeigte bild zu machen. wenn das ginge, waren viele images uberflussig, die zb nur verschiedene farben variieren. es ist die rede, dass irgendwann ein SVG-renderer im HTMLcode realisiert werden konnte, doch das ist zukunftsmusik.

eine anderung der monitorgrosse, zb zooming, andert auch die bildgrossen, und zwar alles darin proportional. anweisungen zur anderung der fontgrosse auf der seite haben keinen einfluss auf die angezeigten bilder. -- sarang♥사랑 10:20, 7 January 2021 (UTC)

nein das meinte ich nicht - ich meinte eine zuweisung der schriftgröße als variable im svg: fontsize = 36 - und in den späteren textbausteinen schreibe ich nicht y=36 oder y=72 sondern y=fontsize oder y=2*fontsize

ich habe oben beim igen-template im oberen abschnitt noch eine frage gestellt - das hast du übersehen? --Mrmw (talk) 14:17, 7 January 2021 (UTC)

{{Atelier graphique}}? habe ich noch nicht ganz hinbekommen

solche abkurzungen bzw vereinbarungen sind bis zu einem eingeschrankten umfang in SVG moglich; aber berechnng wie 2*variable geht sicher nicht. ich muss nachsehen, ich habe das noch nie angewandt. -- sarang♥사랑 16:47, 7 January 2021 (UTC):This section was archived on a request by: -- sarang♥사랑 09:32, 12 January 2021 (UTC)

Category:Superseded_SVG

Category:Superseded_SVG has been listed at Commons:Categories for discussion so that the community can discuss ways in which it should be changed. We would appreciate it if you could go to voice your opinion about this at its entry. If you created this category, please note that the fact that it has been proposed for discussion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it. If the category is up for deletion because it has been superseded, consider the notion that although the category may be deleted, your hard work (which we all greatly appreciate) lives on in the new category. In all cases, please do not take the category discussion personally. It is never intended as such. Thank you!

𝟙𝟤𝟯𝟺𝐪𝑤𝒆𝓇𝟷𝟮𝟥𝟜𝓺𝔴𝕖𝖗𝟰 (𝗍𝗮𝘭𝙠) 15:56, 10 January 2021 (UTC):This section was archived on a request by: -- sarang♥사랑 09:32, 12 January 2021 (UTC)

Supranational European Bodies-de.svg

hi, zum jahreswechsel und brexit wurde die datei aktualisiert und die beschreibungsseite über die anderen dateien hinweg ordentlich gepimped
bei den other versions steht im quelltext folgender kommentar

See https://commons.wikimedia.org/wiki/Module:Multilingual_description/sort for sort order

ich weiss mit solchen modulen eigtl. nichts anzufangen - wie mache ich mir dieses modul zu nutze, wie kann ich es anwenden? - gruß und danke --Mrmw (talk) 21:31, 10 January 2021 (UTC)

damit weiss ich auch nichts rechtes anzufangen. aber in Module talk:Multilingual description/sort/testcases sind bei der sprachliste die fallbacks angegeben, wir hatten davon unlangst.

auch wenn es nur ein kommentar ist, die schreibweise sollte lauten [[Module:Multilingual description/sort|for sort order]], fur zeugs im wiki sollte nicht die url-schreibung verwendet werden. -- sarang♥사랑 17:13, 11 January 2021 (UTC):This section was archived on a request by: -- sarang♥사랑 09:32, 12 January 2021 (UTC)

Template:T4/doc

Template:T4/doc has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry. If you created this template, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it. Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

IN (talk) 03:51, 11 January 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 09:32, 12 January 2021 (UTC)

font-weight

Brosen plimsoll line en.svg
hi, kannst du mir sagen ob es möglich u/o ratsam ist, eine schrift noch stärker als bold auszuzeichnen? ich glaub ich hab mal sowas mit font-weight gesehen mit prozentangaben - aber ob das dann mit dem wiki-renderer kompatibel ist - kennst du dich damit aus?
im editor passt die stärke, in der vorschau, speziell in der kleinen ist die schrift zu leicht - danke und gruß --Mrmw (talk) 18:22, 20 January 2021 (UTC)

ich glaube ich habe das mal gemacht, oder erfolgreich probiert. allerdings tendiere ich eher dazu moglichst mit standardformatierungen zu arbeiten - wenn damit sinnvoll machbar ist was ich brauche. sehr selten stelle ich eigene textgrossen ein. font-weight ist css-sache und hat mit dem renderer nix zu tun.
wenn du es aber im svg-code verwenden willst kann das schiefgehen, der renderer hat so seine probleme mit textformatierungen, da wird es wohl nicht machbar sein. -- sarang♥사랑 18:36, 20 January 2021 (UTC)

Hallo @Mrmw: , ich hab es auch mal versucht, mit Plimsoll line es.svg. Dabei musste ich sehen, dass Tabulation und/oder Spaces zur Einruckung sich auf die Textposition auswirken konnen - ich musste eine korrigierte Version hochladen. Den Unterschied kannst du deutlich sehen.

Sonst habe ich statt der bei diesem einfachen Diagramm vollkommen sinnlosen Genauigkeiten auf hundertstel px (sogar tausendstel bei stroke-width="11.947") sinnhafte Werte genommen, und einige Schiefheiten und Ausser-Mittigkeiten begradigt. Ich finde dass der knappe SVGcode ausreichend gut lesbar ist,

Es wird auch die Gruppierung verwendet, aber statt mit expliziten <g statements teils global, teils mittels <tspan. -- sarang♥사랑 07:50, 25 January 2021 (UTC)

ja verstehe - beim thema einrückung sind wir eben unterschiedlicher meinung - ich finde schade, dass manche sachen, wie auch diese hier, nur bei kleinen auflösungen, also in den vorschaubildern in den artikeln sichtbar sind - bei diesem bild ist in großansicht zwischen den versionen absolut kein unterschied erkennbar

wieso fügst du den svg-code in die beschreibung ein?

habe ich das eigentlich richtig verstanden??? die einrückung am zeilenanfang bei identischem code wirkt sich auf die anzeige aus? wie kann das sein? sowas würde ich als bug bezeichnen --Mrmw (talk) 11:30, 25 January 2021 (UTC)

Das ist kein bug und nur bei einer solchen speziellen konstellation der fall: in der vor-version stand in zeile 8 y="111">T aber alles bis zum nachsten statement wurde als text genommen, d.h. der tab am beginn von zeile 9 kam dazu. das machte in zeile 12/13 kein problem, aber in 8/9 wegen text-anchor="end" erfolgte eine verschiebung, weil der tab als letztes zeichen rechtsbundig reinkam. wenn ich wegen der lesbarkeit den code in einzelne zeilen mache statt in einer langen zeile zu schreiben, wird dieser tab (oder was auch immer den SVG code einruckt) sichtbar. ganz klar und logisch, vom rendering her richtig, muss nur berucksichtigt werden. ich habe in diesem fall eine neuversion ohne einruckungen erstellt. -- sarang♥사랑 11:56, 25 January 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 07:44, 28 January 2021 (UTC)

File:鷄-order.gif

File:鷄-order.gif has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry. If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues. Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

FanNihongo (talk) 05:15, 25 January 2021 (UTC) :This section was archived on a request by: -- sarang♥사랑 07:44, 28 January 2021 (UTC)

Category:Coats of arms from Haus der Bayerischen Geschichte

Jetzt meinst Du es aber zu gut mit mir. Zusätzlich zur

• Category:Coats of arms from Haus der Bayerischen Geschichte gibt es jetzt die
• Category:Coats of arms from Haus der Bayerischen Geschichten. Nanü? -- MaxxL - talk 18:41, 12 January 2021 (UTC)

das habe ich versucht ​dir ausfuhrlich zu erklaren oben in #Category:🍺; ist temporar, zur einfacheren Wartung -- sarang♥사랑 05:36, 13 January 2021 (UTC)

Langsam kapiere selbst ich es. ;-)

Die Wandlung vom hdbg link zum template ist genial. -- MaxxL - talk 10:13, 13 January 2021 (UTC)

Das “template hdbg” ist immer references niemals source. Es kommt häufig vor, dass die Gemeinde eine andere Version des Wappens zeigt, die nicht mit dem Bild wohl aber mit der Blasonierung übereinstimmt.  MaxxL - talk 10:51, 13 January 2021 (UTC)

references gibts aber nur von COAI, nicht bei Info; hochstens mit |Other fields 1={{InFi|References|{{hdbg|...}}}} ist das machbar. oder stellst du generell um?

es sind noch viele umzustellen; maschinell geht das kaum, weil die angaben so unterschiedlich sind. manuell geht es recht rasch, auch wenn der rschl erst gesucht werden muss. -- sarang♥사랑 11:29, 13 January 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 07:30, 7 February 2021 (UTC)

Igen-script

Wenn ich das script über File:Meuble sanglier - heraldic figure boar.svg laufen lasse, so geht das gf verloren. Ist das ein feature oder ein bug? -- MaxxL - talk 13:02, 14 January 2021 (UTC)

das script ist (noch) nicht imstande, parameter aus bestehende Igen-angaben zu ubernehmen, es wird neu ermittelt. weil es auch nicht image= erkennt, macht es auch da alles neu. vielleicht bekomme ich das irgendwann hin, einstweilen muss das gf noch manuell wieder-eingepflegt werden. sorry -- sarang♥사랑 13:18, 14 January 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 07:30, 7 February 2021 (UTC)

igen - lange version

hi - hier scheint das script zu funktionieren - aber wieso wird die langversion eingefügt?

|other fields={{File generation description
 | SVG tool = Text Editor
 | Text embedded = yes
 | Text as path = 
 | Topic = structural formula}}

--Mrmw (talk) 18:07, 15 January 2021 (UTC)

nachtrag aka 2.:

hier hat das script auch probleme - die igen-vorlage wird bei mir außerhalb der beschreibungsbox angelegt - ich könnte das dann schon iwie händisch zusammenbasteln - aber du hast explicit nach testung gefragt --Mrmw (talk) 18:53, 15 January 2021 (UTC)

1. es gibt einen benutzer der verabscheut das igen als "zu kryptisch". leyo hat vor allem mit chemischen formeln zu tun. eigens wegen ihm habe ich das FGD erfunden, und das wird vom script automatisch genommen wenn formeln erkannt werden. aber obwohl es nun wirklich sehr ausfuhrlich ist und uberhaupt ohne kryptische kurzzeichen und -parameter auskommt wird es von ihm auch nicht verwendet
2. ich weiss von diesem fehler, wenn {{Uploaded with derivativeFX}} vorkommt hatte perhelion probleme das richtige loch fur das igen zu finden. passiert nicht immer aber oft. ich hab versucht herauszufinden woran es liegt, und abhilfe zu schaffen - aber leider verstehe ich viel zuwenig javascript. bis auf weiteres musst du in solchen fallen das igen manuell nah oben ubertragen.
3. du bist ja schon sehr versiert mit text switch. vielleicht interessiert dich Ogden semiotic triangle.svg, da gibt es fast gar keinen SVG code (nur zwei striche) aber jede menge text. es waren noch mehrere sprachen einzupflegen, aber speziell arabisch und hebraisch ist mir praktisch unbekannt, da braucht es ubersetzungshilfe von muttersprachlichen fachleuten. die anzusprechen ist erfahrungsgemass unergiebig. -- sarang♥사랑 07:48, 16 January 2021 (UTC)
4. ​ gerade habe ich nachgesehen, die archvierung tut jetzt auch bei dir - gratulation !

danke für die erklärungen

ich habe dazu noch andere und weiterführende und neue fragen:

1. Ogden semiotic triangle.svg: a) was ist genau deine botschaft? es gut oder schlecht die svgs sprachlich zu erweitern? du rätst davon ab arabische sprachen einzupflegen?

nein, ich rate nicht ab, aber ich lasse die finger davon, weil ich nicht arabisch kann. und in russisch, hebraisch, koreanisch weiss ich zuwenig von den grammatischen feinheiten um da sinnvolle ubersetzungen hinzubekommen. im semiotischen dreieck hat es nicht nur einzelne substantiva sondern satzteile, da sind die anspruche hoher.

b) wieso ist Semiotischesdreieck.jpg nicht mit dem entsprechenden vva versehen und mit dem svg ersetzt wo doch deutsch eingepflegt ist?

weil das eigentlich eine andere datei ist als das triangle. naturlich kann man mit vva darauf hinweisen.

2. archivierung: ich habe versucht auf meiner de-wiki-diskpage deinen archivierungs-edit von commons zu adaptieren - scheint dort jedoch nicht zu funktionieren - kannst du das korrigieren?

werde ich mir gelegentlich ansehen

3. ladezeiten: mir kommt es so vor als bräuchten die de-wiki-seiten speziell bei mir immer lange zu laden - darüber hinaus habe ich öfter 'browser-freezes', häufig wenn ich mehrere tabs gleichzeitig offen habe und die seiten im edit-mode sind, dabei ist der browser an sich ansprechbar, aber das inhaltsfenster ist entweder eingefroren oder komplett weiss - nach einigen sekunden is die seite wieder ansprechbar - nach einem fensterwechsel wiederholt sich der freeze, ich weiss nicht wo und wie ich da aufräumen muss, ob das problem im browser oder woanders liegt

zur zeit habe ich auch ewige wartezeiten, ich werde mal meinen rechner neu hochfahren

4. a) svg-fonts: ich habe die noto-fonts von google entdeckt und wollte für m:SVG fonts eine übersicht erstellen welche dieser unterschriftarten für welche sprache gedacht sind - rätst du davon ab?

b) man kann/sollte? in svgs für die schriftart hierachisch absteigend alternativen angeben - machst du das? wie sollte das aussehen?

font-family="Noto Sans Ethiopic, DejaVu Sans, sans-serif"

ich weiss auch nicht ob und wo ich hier das einfache anführungszeichen ' brauche

wenn du es style="...font-family:xxxx ..." schreibst scheint das ' notwendig zu sein, aber da weiss ich zuwenig, ich muss das ausprobieren. ist bei uns ja auch eine sache des librsvg. ich glaube wenn du f-families, die namen aus mehreren wortern haben, generell in anfuhrungszeichen setzt bist du auf der sicheren seite. ​(hier "hp" kleingeschrieben)

5. {{Hp}} muss man großschreiben damit es funktioniert glaub ich

nach meiner efahrung ist das egal

--Mrmw (talk) 11:20, 16 January 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 07:30, 7 February 2021 (UTC)

Help needed

File:Golden Gate Bridge jumpers by year.svg is somehow broken. It shows only some of the blocks, but if click the image, it shows all. What's wrong? This started to happen after last update. Can U take a look?--RicHard-59 (talk) 11:12, 1 February 2021 (UTC)

@RicHard-59: As I can see from the file upload history, it is broken from the very beginning (May 2013); it is a really bad mixture from embedded raster and SVG code, obviously too complicated for our renderer. The only solution I can suggest is to write it completely new, which can easily be done using a text editor - but then it should never again be modified with a tool like Inkscape! Can you agree with that restriction? -- sarang♥사랑 11:25, 1 February 2021 (UTC)

@RicHard-59: I made it by hand, it looks good; but I entered only the first twenty years from 37 to 60, and then all ten years. When you will enter the years from 1960 to 2020 (it is easy!) it will be ready within ten minutes. -- sarang♥사랑 13:26, 1 February 2021 (UTC)

Thks. Remade the svg. Now it is easy to adjust. --RicHard-59 (talk) 13:31, 1 February 2021 (UTC)

@RicHard-59: I cannnot agree. It is still a BAD SVG containing useless raster image, but now it exceeded drastically in size. Bad SVGs should be replaced, and I will do it. -- sarang♥사랑 13:36, 1 February 2021 (UTC)

With the new code the size went down from 1 MB to 1.8 KB; with the code lines for 60 more years it will then be 3.6 KB. And the simple code will be easy to maintain. Either you will complete it, or make it within the next days - it is easy work for ten or twenty minutes. -- sarang♥사랑

Plse fix however U can.--RicHard-59 (talk) 14:42, 1 February 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 07:30, 7 February 2021 (UTC)

Most popular edition of Wikipedia by country Jan 2021.svg

hi, hier bin ich mir nicht sicher ob ich die doppelten schließenden geschweiften klammern vergessen hatte oder das script - ich habe einzelne legends eingefügt die das script zu einer legtab macht - da das ganze innerhalb einer en-description ist, ist vielleicht was schiefgelaufen - vielleicht kannst du was rekonstruieren - wenn nicht, auch nicht schlimm --Mrmw (talk) 21:13, 6 February 2021 (UTC)

ich weiss dass das script unter bestimmten umstanden probleme hat die richtge position zu finden; das scheint auch hier der fall gewesen zu sein, um 21:05 wurde das other fields falsch eingefugt. Relativ oft kommt das vor wenn {{Uploaded with derivativeFX}} vorhanden ist. ich kann viel zuwenig JS um zu verstehen wie Perhelion die stelle zum einfugen ermittelt. solche fehler mussen b.a.w. manuell behoben werden. danke fur die nachricht @Mrmw: , einstweilen kann ich da leider nicht abhelfen. -- sarang♥사랑 07:25, 7 February 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 07:30, 7 February 2021 (UTC)

File:EURion 오만원.jpg

File:EURion 오만원.jpg has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry. If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues. Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

Ox1997cow (talk) 04:18, 13 February 2021 (UTC) :This section was archived on a request by: -- sarang♥사랑 08:20, 13 February 2021 (UTC)

marker - Neural network.svg

hi, gibts eine möglichkeit den marker hier zu vereinfachen? oder wie hälts du es mit pfeilen in svgs? kannst mir beispiele zeigen von dir? --Mrmw (talk) 21:40, 2 January 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 18:18, 23 February 2021 (UTC)

vorlagen handarbeit

hi, du hattest doch mal vorlagen auf svgs platziert um handarbeit zu kennzeichnen und davon abzuraten mit inkscape zu überspeichern - welche waren das?

• {{NoInkscape}}

du meinst wie du das tag setzt? das kann im Igen erfolgen mit 10=S- wenn auch das kennzeichen %s gestzt ist wird auch noch vor toolforge gewarnt.

und es gab noch eins für simple-svgs oder? - ab wann ist denn ein svg simple? --Mrmw (talk) 21:47, 2 January 2021 (UTC)

simple SVG sind fur mich handgezeichnete, die ein toolgezeichnetes ersetzen, und kategoriisert habe ich sie anfangs automatisch wenn sie kleiner als 5% wurden; weil das zu viele wurden, habe ich wegen der ubersichtlichkeit nur die ca. 64 interessantesten und drastischsten optimierungen aufgenommen, und biete in SVG simplification techniques spezialisierte information an. 🎇 -- sarang♥사랑 09:34, 3 January 2021 (UTC)

wieder gefunden auf Carbon cycle-cute diagram.svg

 

Please do not replace the simplified code by another version created with a vector graphics editor and do not translate it with Toolforge!  

gibts das auch kürzer als vorlage? --Mrmw (talk) 08:58, 7 January 2021 (UTC)

JA. ​das von dir gefundene beispiel war ein versuch im sommer - habe ich kurz daraufhin als vorlage realisiert:

• wenn im Igen der parameter 10=S angegeben wird, kommt auch diese zeile (immer, keine unterdruckung vorgesehen),
• mit oder ohne toolforge, je nachdem ob %s vorkommt oder nicht

im obigen beispiel ist es nun durch das 10=S ersetzt. -- sarang♥사랑 09:34, 7 January 2021 (UTC)

cool - {{Igen|%s|10=S}} erzeugt kein toolforge - hab ich was falsch verstanden? --Mrmw (talk) 09:50, 7 January 2021 (UTC)

das meinte ich, es funktioniert nicht so wie ich verstanden habe

ohne angabe eines tools ist es falsch, da kannst du​ nicht erwarten dass es funktioniert!

hier ist noch ein energischer hinweis zur bearbeitung --Mrmw (talk) 08:15, 8 January 2021 (UTC)

ja, sehr energisch; aber antonsusi hat dabei das igen entfernt - ich hab es wieder reingemacht -- sarang♥사랑 08:33, 8 January 2021 (UTC) :This section was archived on a request by: -- sarang♥사랑 18:18, 23 February 2021 (UTC)

{{Created with code}} - "source-code" in toc

{{Created with code}} erzeugt im inhaltsverzeichnis einträge ohne einrückung - ist das so gewollt?
User_talk:Mrmw#toc
--Mrmw (talk) 09:20, 3 January 2021 (UTC)

nein, das ist ein fehler. repariere ich gelegentlich mal. 👾 -- sarang♥사랑 09:23, 3 January 2021 (UTC) :This section was archived on a request by: -- sarang♥사랑 18:18, 23 February 2021 (UTC)

Category:🍺

Guten Morgen - ich glaub, ich hab es schon wieder vergessen. Was bitte qualifiziert die Dateien für diese Kategorie? -- MaxxL - talk 08:40, 12 January 2021 (UTC)

dass sie bayrische Gemeinden sind -- sarang♥사랑

... und woran erkennt die mediawiki das? Was ist der Trigger? -- MaxxL - talk 09:27, 12 January 2021 (UTC)

an der verwendung der vorlage Hdbg. du weisst, diese maintenance-category ist nur temporar

Hallo Manfred, inzwischen finde ich dem Bier-Kategorie nicht sehr brauchbar; es gibt uber 900 Wappen in der Coats of arms from Haus der Bayerischen Geschichte, und ein Teil ist umgestellt, die meisten noch nicht. Ich finde es besser zwei verschiedene Kategorien zu haben: alle mit dem Hdbg kommen in eine temporare eigene Kategorie, da kann dann mit cat-a-lot die uberflussige Orig-Kat entfernt werden, und zum Abschluss wird in hdbg die endgutige Kategorisierung aktiviert. Fur dich und deine Arbeit hat das keine Auswirkungen, hochstens dass auch du leichter sehe kannst was noch umzustellen ist. -- sarang♥사랑 16:02, 12 January 2021 (UTC)

Die ​Vorlage hat noch keine Doku. Deshalb mal hier: der rschl kann 7- oder 8stellig eingegeben werden, Zwischenraume sind erlaubt: 9 1 62 000, 09 1 62 000 sind neben 9162000 und 09162000 erlaubte Eingabeformate (es ist sogar jede Art von Zwischenraum erlaubt, auch nicht sinnvolles wie 9 1 6 2 0 0 0, und jeweils egal ob ein oder mehrere Leerzeichen). -- sarang♥사랑 16:21, 12 January 2021 (UTC) :This section was archived on a request by: -- sarang♥사랑 18:18, 23 February 2021 (UTC)

archive

hallo, könntest du mir bitte helfen? ich würde meine disk-seiten (commons u. de) auch gern auto-archivieren - ich habe dazu schon vor längerer zeit entsprechende vorlagen platziert, aber wie ich das sehe tut sich nichts - weisst du was ich falsch bzw. nicht mache? danke und gruß --Mrmw (talk) 10:44, 12 January 2021 (UTC)

die erlauterungen sind ziemlich unverstandlich, ich blicke da nicht durch. aber ich glaube dass es nur funktioniert wenn eine passende archivseite besteht, und die kann IMHO nur manuell angelegt werden. habe ich mal fur dich gemacht, User talk:Mrmw/Archive/2021. warte mal ab, ob der bot heute nacht archviert! wenn nicht, suchen wir weiter -- sarang♥사랑 10:54, 12 January 2021 (UTC) :This section was archived on a request by: -- sarang♥사랑 18:22, 23 February 2021 (UTC)

ACHTUNG - Überraschung -- MaxxL - talk 08:20, 7 February 2021 (UTC)

Wenns gefällt, bitte den Code simplifizieren. Wenns nicht gefällt, bitte reversieren. -- MaxxL - talk 08:24, 7 February 2021 (UTC)

ist mir recht egal - ist deine Sache! -- sarang♥사랑 08:28, 7 February 2021 (UTC)

aber ich finde die Farbe ist zu knallig: damit wird es zur hervorstechendsten und wichtigsten Aussage der Beschreibung, statt nur eine Information zur Referenz zu sein. Es war vorhin vielleicht eine Spur zu diskret, ​nun erscheint es mir uberproportional betont. -- sarang♥사랑 08:37, 7 February 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 18:18, 23 February 2021 (UTC)

auto-archive

hi, erinnere ich mich richtig, dass du mir auch bei meiner de-wiki-disk-seite beim autoarchivieren helfen wolltest, nachdem es auf commons so gut funktioniert hat? - nur ein freundlicher reminder - wenn du zeit und gleichzeitig lust haben solltest - ich wäre dir sehr verbunden - gruß --Mrmw (talk) 19:49, 10 February 2021 (UTC)

@Mrmw: tut leider noch immer nicht -- sarang♥사랑 11:00, 14 February 2021 (UTC)

wieso immer noch nicht? hast du was verändert? verwechselst du es mit meiner commons-disk? --Mrmw (talk) 06:58, 15 February 2021 (UTC)

hab ich dich verwirrt oder selbst einen denkfehler? --Mrmw (talk) 21:40, 17 February 2021 (UTC)

ich habe es damit versucht dass ich eine erste archivseite angelegt habe; hat nichts genutzt. bei euku habe ich angefragt - aber er ist nur sehr selten aktiv, zuletzt war das am 9. januar. vielleicht gibt as andernorts auskunft? -- sarang♥사랑 09:00, 18 February 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 18:22, 23 February 2021 (UTC)

{{Cat see if}}

@MaxxL: und andere, stets waren in den Kategorien redlinks weil das vorhandene Cat see also mit anderen, aber nicht existenten Kategorien aufgerufen wurde. Deshalb habe ich nun eine Vorlage gebastelt, damit keine redlinks mehr erzeugt werden. Siehe die Doku und als Beispiel die Aufrufe in Symbols from the Landkreis Weilheim-Schongau. Kann ausgebaut werden! -- sarang♥사랑 18:40, 18 February 2021 (UTC) :This section was archived on a request by: -- sarang♥사랑 18:18, 23 February 2021 (UTC)

File:⺦-order.gif

File:⺦-order.gif has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry. If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues. Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

FanNihongo (talk) 04:34, 22 February 2021 (UTC) :This section was archived on a request by: -- sarang♥사랑 07:07, 23 February 2021 (UTC)

{{Tincture}}

Leider kann ich den Unterschied zwischen:

• standard tincture ss=0
• websave tincture ss=WS

nicht verstehen. Wo wurde wann über die Werte für "Websave" diskutiert? LG + PX -- MaxxL - talk 18:32, 22 February 2021 (UTC)

Auf der Seite Wikipedia:WikiProjekt_Wappen/Neuzeichnen#Tinkturen_(Farben) gibt es eine Tabellenzeile "Allg. vk. Durchschn.-Werte (Websichere Farben)" - da wird davon gefaselt. Deshalb habe ich auch diese Palette ubernommen. Ubrigens, fast keine der Tinkturen in dieser Palette ist tatsachlich eine der 'websicheren' Farben. PX -- sarang♥사랑 06:53, 23 February 2021 (UTC)

Was sind denn die wirklichen "websicheren" Farben`? Wo finde ich die? LG -- MaxxL - talk 07:51, 23 February 2021 (UTC)

Auf der Seite Module_talk:Color2dec sind diese Farben auch zusehen - es sind die bold bezeichneten.

This section was archived on a request by: -- sarang♥사랑 18:18, 23 February 2021 (UTC)

Commons talk:Colour palettes#Compare all tincture variations

Hallo Sarang - diese Tabelle ist wohl noch nicht vollendet. Sind die Buchstaben 1. Spalte zu groß oder die Farbfelder zu klein. LG + PX -- MaxxL - talk 18:54, 22 February 2021 (UTC)

@MaxxL: Ich verstehe nicht was du meinst, was dich irritiiert; bei mir sieht es ordentlich aus -- sarang♥사랑 07:07, 23 February 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 07:07, 23 February 2021 (UTC)

File:1 cup con Martí.jpg

File:1 cup con Martí.jpg has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry. If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues. Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

A1Cafel (talk) 05:02, 18 March 2021 (UTC)

Notification about possible deletion

Some contents have been listed at Commons:Deletion requests so that the community can discuss whether they should be kept or not. We would appreciate it if you could go to voice your opinion about this at their entry. If you created these pages, please note that the fact that they have been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with them, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues. Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

Affected:

• File:3 cup con Che.jpg

Yours sincerely, A1Cafel (talk) 05:05, 18 March 2021 (UTC)

multilang nr2 + einbindung

hi, Abdomal organs body.svg
auf userwunsch hin habe ich zu bestehender datei den langcode für 'als' hinzugefügt
mich irritieren mehrere dinge:

• {{Lang gallery}} zieht den 'als'-text für die vorschau korrekt an (irritiert mich nicht)
• in der sprachauswahl auf der dateiseite zum rendern des bildes steht anstatt von 'als' 'gws' (Schweizerdeutsch) zur auswahl
• wenn ich mir den dom-baum zu der auswahlbox ansehe steht dort <option value="als">Schweizerdeutsch (gsw)</option>
• auf als:Magen wird nur der standardtext also 'en' gerendert - (gsw:Magen wird anscheinend intern auf als weitergeleitet)

kannst du helfen?

bei mir zeigt als oder gsw richtig "Maage" an

beim schreiben vom seitenlink (als:Magen) auf 'als' war ich jetzt nochmal verwirrt, wenn auch offtopic:
ich dachte die überschrift eines artikels ist das lemma? und ich dachte das lemma/überschrift kann immer 1:1 für die url verwendet werden oder eben um wiki-links wie hier zu erzeugen
das scheint hier nicht der fall zu sein: Maage <-> Magen
ist das wikispezifisch? --Mrmw (talk) 12:34, 1 January 2021 (UTC) --Mrmw (talk) 12:34, 1 January 2021 (UTC)

Ich verstehe nicht ganz was dich irritiert; mit [[:als:Magen]] wird richtig auf glw:Maage verlinkt.

es gibt irgendwo (muss das suchen) eine grafik welche ersatzsprachen gelten, so muss zb bei fehlendem als oder glw das de genommen werden, oder bei ca das es etc. -- sarang♥사랑 12:46, 1 January 2021 (UTC)

1) auf der ensprechenden seite wurde das bild nun mit langcode eingebunden - so funktioniert es - die frage ist, wieso es ohne angabe des langcodes nicht geht, dann wird nur die ersatzsprache aus dem svg gerendert 2) hat sich jetzt aufgelöst als ich '{{DISPLAYTITLE:Maage}}' entdeckt habe

@Mrmw:

What a mess.

1. Some information about IETF langtags:
   • gsw is the IETF langtag for Swiss German which is also known as Alsatian
   • als is the IETF langtag for Tosk Albanian
2. Browsers should be configured using IETF langtags. If you want your browser to display Swiss German, then it should use gsw and not als. Browsers often let users specify a preference list.
3. Wikipedia predates some langtags and has some odd nonsense:

   WMF mostly uses IETF langtags to identify its Wikipedia languages, but there are some exceptions.

   • sr-EC is an IETF langtag for Serbian (language=sr) as spoken in Ecuador (region=EC, added in 2005). WMF uses "sr-EC" to mean Serbian using the Cyrillic script. The correct langtag would be sr-Cyrl, and WMF is currently fixing MW to use that langtag.
   • sr-EL is an IETF langtag for Serbian (language=sr) as spoken in the unassigned EL region. WMF uses "sr-EL" to mean Serbian using the Latin script. The correct langtag would be sr-Latn, and WMF is currently fixing MW to use that langtag.
   • WMF is probably fixing some other langtag anomalies. It clearly has some workaround for its non-IETF compliance.

4. SVG uses IETF langtags. When you internationalize an SVG file, you should use gsw. Otherwise, browsers and other software will think you are adding Tosk Albanian.
5. Wikipedia Commons does something it probably should not do. If it sees als in an SVG file, it decides that the creator really meant Swiss German (gsw). That's why you see an option with a value of als and a description of "Swiss German (gsw)". I added a single text element with systemLanguage="gsw" attribute to the SVG file on Commons. The language dropdown box now offers two descriptions with "Swiss German (gsw)": one has the value als and the other has gsw.
6. If one specifies a |lang= argument in a multilingual image inclusion for an article, then MW uses that langtag to display the file. If no langtag is specified, then a Wikipedia will check if its language is present in the file. For example, the French Wikipedia will check for an fr langtag; the German Wikipedia will check for a de langtag. If the langtag is found, then the Wikipedia will use that langtag. If the langtag is not found, then the Wikipedia will default to some other langtag.
7. The default language for als.Wikipedia.org is gsw; that Wikipedia does not look for als. That is why you had to specify |lang=als to get your als language to display. After I added the gsw langtag, I did not need to use the |lang= argument to get my gsw version to display.

Bottom line: use gsw.

Glrx (talk) 23:31, 14 March 2021 (UTC)

@Glrx: thanks a lot - really good to know to have experts here in wikimedia --Mrmw (talk) 06:52, 15 March 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 15:18, 4 April 2021 (UTC)

JavaScript API

Hallo, ich frag einfach mal auf gut Glück, vielleicht kennst du dich aus. Ich habe in der Technikwerkstatt bereits eine Frage gestellt. Dort konnte mir allerdings niemand zur Lösung helfen. Weisst du darüber was oder kennst jemand den ich persönlich anschreiben könnte?
de:Wikipedia:Technik/Werkstatt#API-Anfragen_Limits_LogIn
Danke und Gruß --Mrmw (talk) 19:52, 27 February 2021 (UTC)

Ich hab noch nie von sowas gehort. Total neu fur mich, ich weiss nichts daruber, muss bedauern -- sarang♥사랑 05:36, 28 February 2021 (UTC) :This section was archived on a request by: -- sarang♥사랑 15:18, 4 April 2021 (UTC)

archive

hi, immer noch die archive, aber nun mit fortschritt - danke für deine anfrage bei 'Euku' - das war der entscheidende hinweis mit der vorlage - danke dir dafür
der archivierer arbeitet nun, allerdings passt der pfad nicht:
Benutzer Diskussion:Mrmw/Archive/((year))
weisst du was man da anpassen muss? --Mrmw (talk) 09:40, 2 March 2021 (UTC)

hi, ich bin verwirrt - du hast zwar meine talk-page bearbeitet (de:special:diff/209314426/209366098) aber nicht zum archiv sondern zu einem alten thema? --Mrmw (talk) 07:37, 3 March 2021 (UTC)

trotz suche konnte ich noch nicht herausfinden wo es nun klemmt. zumindest wird jetzt uberhaupt archiviert - ist ja schon ein gewisser fortschritt ! -- sarang♥사랑 07:49, 3 March 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 15:18, 4 April 2021 (UTC)

igen

hi, mit welchen parametern kann ich z.b. hier File:TCI.svg den warntext ändern zu texten aus Template talk:NoInkscape, zb. fände ich '+' besser --Mrmw (talk) 09:06, 14 March 2021 (UTC)

der parameter fur den deutlicheren block-hinweis ist "←", in der gesamtreferenz sind die verschiedenen moglichkeiten der parametrierung beschrieben; der parameter "S" fur den sanfteren hinweis kann dann ev. weggelassen werden.

im fall von TCI.svg ist wohl am besten ←s=0 zu nehmen - falls du es noch knalliger willst auch ←s=0h. ​-- sarang♥사랑 09:16, 14 March 2021 (UTC)

danke - das werde ich beim nächsten file mit text ausprobieren

kannst du mal hier (File:Map of the United States with flags.svg) schauen? hier schreibt igen in den license-abschnitt - ist das so gewollt? --Mrmw (talk) 21:31, 14 March 2021 (UTC)

​in manchen, zum gluck seltenen konstellationen findet das script nicht die richtige stelle sondern fugt das igen bei der license oder der upload-info ein. leider konnte ich diesen fehler noch nicht lokalisieren, also auch nicht beheben. -- sarang♥사랑 08:39, 15 March 2021 (UTC) :This section was archived on a request by: -- sarang♥사랑 15:18, 4 April 2021 (UTC)

File:⺿-order.gif

File:⺿-order.gif has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry. If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues. Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

FanNihongo (talk) 05:27, 16 March 2021 (UTC) :This section was archived on a request by: -- sarang♥사랑 15:18, 4 April 2021 (UTC)

Sarangbot

Hello Sarang, I will come with some elegant stuff by end of next week. Do you have git, nodejs, npm on your computer ? If not, do you have a linux or else ?
Second point, please check this up, set it up on svgsJa : this project priority order is Hans > Ja > Hant.
Third, Commons:Village_pump#Fonts_license's_template. Cheers ! Yug (talk) 17:20, 28 March 2021 (UTC)

It seems that I have none of the tools; I looked now for Github (which I do not know) but I am asked to registrate, which let me hesitate and avoid to continue.

The other tools I do not know, too. The only help I am using is the editor Notepad++ which gave me severe and unsovable troubles in the last days.

You see, I am not so much a developer; may be that I can learn something new, if it's eneough interesting. -- sarang♥사랑 06:12, 29 March 2021 (UTC)

I see, thank for the review. Best avenue i guess is to continue as you do, which works. But to request bot status.

I started writing instructions for Linux/Ubuntu. What is your OS ?

If you are not a junior dev the jump from our workflow to mine may be unwanted. Technically, code will be as simple as your current tools. But the environment will be different : shell terminal, require installing git, node, npm, rening those commands. You are not familiar with those tolls so you would need to learn about those, the basics.

Note: git is not github. Github is a website which host git projects. You dont require it to simply use codes from there. Git is a way to keep the history of a directory, and synch changes with an online copy. It will simply helps to download my codes. Node, npm are really needed.

Can you request bot status for Sarangbot (and keep your current workflow) ? Seems the best way to avoid renaming ? Yug (talk) 08:58, 29 March 2021 (UTC)

​When you recommend to try it I will install such tools; until now I had not seen the need for it. My knowledge of JS is very poor, rather not existent, but there is a need to work with it. -- sarang♥사랑 09:06, 29 March 2021 (UTC)

My nodejs workflow is mainly interesting for junior dev who want easy tool which also allow growth, aka cheerful hacking and exploring new js codes. If you plan an easy peasy usage, your workflow is ok, my nodejs is ok but harder to set up. Yug (talk) 09:13, 29 March 2021 (UTC)

sorry, ​I had not found out how and where to request that bot status. And: now it is a wrong name, then it will be a wrong status? I won't mind too much when that account is moved, removed or blocked, I just will not do any more that work. But of course, I can try that. -- sarang♥사랑 12:09, 29 March 2021 (UTC)

With up to 50k edits per year your account deserves the bot status. Once you have the status you are free.

It allows you to continue as before, reduce or to grow. Up to you. A bot can be inactive as well, all ok.

Check my Commons:Bots/Requests/ShufaBot. From there you can find your way. Yug (talk) 14:43, 29 March 2021 (UTC)

When a ​mass rename is possible with this bot: in which format do you want to get the parameters (old name, new name)? In a list e.g. a textfile, with newlines?

The first example will be Löwenstein, all filenames "Loewenstein" are erroneous, obviously false-written; some names contain additional errors.

I will need a category name and a regex patern such as .replace(/_US_/g,'_USA_'); , ideally.

I will focus on SOP and ACC projects tho. But code could easily be reused. I still need to know you OS system, so i may customize the doc better. Yug (talk) 15:29, 29 March 2021 (UTC)

ok, this seems easy. For the above example ​ category it will be /Loewenstein/g, 'Löwenstein'; the move reason is Criterion 3. Your bot is ready? -- sarang♥사랑 15:35, 29 March 2021 (UTC)

Nearly ready for Ubuntu users. Yug (talk) 23:28, 29 March 2021 (UTC)

Your first bot avenue is your bot request and continuing your current workflow.

Your possible 2nd bot avenue is the accessible JS/Nodejs bot i'm coding. The plan and progresses are expressed there. I expect 1~2 weeks before official publication. Yug (talk) 09:25, 1 April 2021 (UTC)

You can use your bot to rename files this week. It will demo file move so you get that user-right for long term. You can now focus on Commons:Bots/Requests/Sarangbot alone (and drop the other page's file mover section). Yug (talk) 07:28, 2 April 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 15:18, 4 April 2021 (UTC)

Hello Sarang, please engage a bit more in Commons:Bots/Requests/Sarangbot. Also, please test the renaming tool. I think it's the missing piece for your bot request. If you don't have material to rename, you can play with Category:ShufaBot_test:_edit files. I already did my test on them and my bot will soon be approved. Yug (talk) 07:40, 5 April 2021 (UTC)

Criterion 3

Hallo Sarang,

wieso verschiebst du schon seit einiger Zeit immer wieder reichlich Dateien, deren Namen aufgelöste Umlaute enthalten (ae, oe, ue statt ä, ö, ü) mit der Begründung Criterion 3? Criterion 3 ist “To correct obvious errors in filenames, including misspelled proper nouns, incorrect dates, and misidentified objects or organisms.” Aufgelöste Umlaute sind kein Fehler, sondern eine je nach den Umständen durchaus korrekte Form. Bei Dateinamen war es lange Zeit durchaus üblich, die so zu schreiben wegen möglichen Kodierungsproblemen auf manchen Zielsystemen, die Umlaute zu irgendwelchen mehr oder minder seltsamen Sonderzeichen verhackstückt haben. Ja, ich weiß, dass WP & Co. schon seit vielen Jahren Unicode nutzen und Umlaute in Dateinamen zulässig sind. Das heißt aber nicht, dass aufgelöste Umlaute deswegen falsch sind (“errors”, “misspelled”), und Criterion 3 ist keine zutreffende Begründung, um massenhaft Dateien dieser Art zu verschieben. Mit deinen Verschiebereien erzeugst du letztlich nur viele unnötige Edits, Boteinsätze, Einträge in Beobachtungslisten usw. Was bezweckst du damit? Gruß --Rosenzweig τ 11:25, 31 March 2021 (UTC)

Und gleich hinterher, weil ich oben auch Criterion 4 sehe: “To harmonize the names of a set of images so that only one part of all names differs” heißt nicht, dass ein bestimmtes Wort in allen Dateien einer Kategorie gleich geschrieben sein muss. Wie anhand des Beispiels ersichtlich, bezieht sich das auf bspw. auf irgendwelche Iconsätze, die in Streckenvorlagen o. ä. benutzt werden. Steht auch in der Anmerkung: “Just because images share a category does not mean that they are part of a set. There are two scenarios that this criterion is designed for. First, certain complex templates (such as those that use BSicons or that display football kits) assume that the images used in them will follow a specific naming convention. Wikisource also uses a specific naming convention for the source files they transcribe. Second, files that form parts of a whole (such as scans from the same book or large images that are divided into smaller portions due to Commons’ upload size restriction) should follow the same naming convention so that they appear together, in order, in categories and lists.” Gruß --Rosenzweig τ

11:31, 31 March 2021 (UTC)

Hallo @Rosenzweig: "Criterion 4" (oben) war ein Fehler, ich meinte 3, jetzt ist es in meiner talk page oberhalb korrigiert. Wenn ich files move dann entweder wegen

• crit.4, bei einigen usern hat die Vektorisierung einen anderen Namen (den .png-namen plus einen suffix wie 'vector'), damit wird die automatische Referenz verhindert weil sie nur bei gleichen Namen von Vektor- und Rasterversion möglich ist
• crit.3, bei definitiven Falschschreibungen wie du es gerne gemacht hast: wenn der Ort Löwenstein heisst dann ist Loewenstein als "aufgelöster Umlaut" eine inkorrekte Schreibung, ein "obvious error in filename", und eine Bruecke ist nicht dasselbe wie Brücke sondern "misspelled". Da kann ich deine Meinung nicht teilen! Wenn das in der description irgendwie anders oder falsch geschrieben wird soll es mir recht sein - aber gerade da ist es richtig, nur der Dateiname ist verhunzt. Ich tendiere dazu zu respektieren was andere gemacht haben - nur offensichtliche Fehler erlaube ich mir auszubessern. -- sarang♥사랑 12:17, 31 March 2021 (UTC)

Hallo Sarang,

da wir hier offensichtlich verschiedener Ansicht sind, was eine Falschschreibung ist und was nicht, ist der tatsächliche oder vermeintliche Fehler eben weder “obvious” noch so „definitiv“, wie es von dir dargestellt wird. Die Grundeinstellung zum Verschieben ist eher, es so wenig wie möglich zu machen. Du hast hingegen anscheinend botgestützte Massenumbenennungen vor. Bei einem nicht offensichtlich Fall wie diesem (ich habe begründet, warum es keiner ist) sollte vorher eine Diskussion stattfinden, ob so etwas wirklich gewünscht wird. Bspw. entweder auf der Diskussionsseite der Umbenennungs-Hilfeseite oder evtl. Commons:Forum, weil da vermutlich mehr Deutschsprachige mitlesen. Gruß --Rosenzweig τ 13:20, 31 March 2021 (UTC)

Gerne, lass und das einem erweiterten Forum vortragen, und sehen was andere meinen. IMHO ist es nicht eine Frage deren Beantwortung der Deutschsprachigkeit bedarf, es ist viel allgemeiner - aber mag sein dass von dieser Seite mehr Meinungen geäußert werden. Ich werde dort fragen, wir werden unsere Diskussion dort fortsetzen. -- sarang♥사랑 14:44, 31 March 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 15:18, 4 April 2021 (UTC)

Noch eine Frage

Wieso ist der Breitenauer See im Winter (die von dir neu angelegte Category:Breitenauer See im Winter) automatisch ein “frozen lake” (von dir in die Category:Frozen lakes of Baden-Württemberg eingeordnet)? Besagter See ist im Winter eher selten zugefroren, vielleicht 2x in 10 Jahren oder so. Gruß --Rosenzweig τ 11:37, 31 March 2021 (UTC)

Seit langem versuche ich Kategorisierungen zu verbessern, richtigzustellen, ggf. aufzuteilen wenn sie zu voll sind; letzteres erschien mitr beim See der Fall zu sein, deshalb habe ich die vielen Winterbilder subkategorisiert. Und weil besagte Winterbilder alle eine Eisdecke zeigen habe ich noch unter die Frozen lakes eingeordnet. Wenn es Winterbilder gibt ohne Eisdecke, muss das natürlich anders gemacht werden. -- sarang♥사랑 12:17, 31 March 2021 (UTC)

Und warum machst du es nicht gleich richtig? Bilder des besagten Sees vom Jahresende 2020, ohne Eis, kann ich ggf. beisteuern. Gruß --Rosenzweig τ 13:22, 31 March 2021 (UTC)

Deine Bilder sind immer eine Bereicherung der Wikimedia - ​her damit! Wie soll es richtig gemacht werden? Die Subkategorisierung rückgängig, oder statt dessen zwei Subkats: Winter normal und Winter zugefroren? Meine Kategorisierung ist als Anregung gedacht, wenn sie durch Besseres ersetzt werden kann, oder der Ergänzung bedarf, sollte es gemacht werden. Da es deine Bilder sind, sollte es deinen Intentionen entsprechen. -- sarang♥사랑 14:44, 31 March 2021 (UTC)

OK, die Bilder von Ende 2020 sind hochgeladen. Es wird wohl auf zwei getrennte Kategorien hinauslaufen: Eine als Unterkategorie von Category:Frozen lakes of Baden-Württemberg, analog zu Category:Frozen Lake Constance. Kategorienamen sollten auf Englisch sein, also wäre m. E. Category:Frozen Breitenauer See der Name. Klingt ziemlich komisch, aber das kommt heraus, wenn man deutsche Eigennamen in englischen Kategorien verwurstet. Die andere Kategorie müsste unterhalb von Category:Categories by season zu finden sein, vielleicht noch mit einer Zwischenkategorie Category:Lakes by season (analog zu bspw. Category:Forests by season). Und der Kategoriename sollte auch hier englisch sein, also eher Category:Breitenauer See in winter als Category:Breitenauer See im Winter (zum Glück kann man seit einiger Zeit auch Kategorien verschieben). Gruß --Rosenzweig τ 17:35, 31 March 2021 (UTC)

Hallo zusammen. Ich bin auf diese Diskussion aufmerksam geworden. Solch einen Fall für einen See nach Jahreszeiten habe ich nur in Category:Seasons in Lake Chuzenji gefunden. Das scheint aber unvollständig kategorisiert zu sein. Selbst bei größeren Seen im englischsprachigen Raum (mit vielen Commons Nutzern) bisher nichts nach Jahreszeiten gefunden.

Category:Winter in Landkreis Heilbronn habe ich mal noch ergänzt.

In Category:Frozen lakes of Germany gab es außer in BW nur noch in Meck-Pomm eine Unterkategorie mit Category:Frozen Dümmersee in February 2012.

Gruß Triplec85 (talk) 01:00, 1 April 2021 (UTC)

Anders als im Deutschen ist im Englischen das Winter üblicherweise vorne, wie bei Category:Winter in Landkreis Heilbronn, Category:Winter in Rocky Mountain National Park, ... also könnte

1. auf Category:Winter in Breitenauer See verschoben werden, wie auch Category:Winter in Lake Chuzenji.
2. diese Category vorerst in Category:Breitenauer See, Category:Winter in Landkreis Heilbronn und Category:Seasons in Landkreis Heilbronn einsortiert werden, solange es keine Jahreszeiten nach Seen Category gibt. Wobei eine Stufe höher gedacht Seasons in bodies of water, oder Bodies of water by season (statt Lake) zunächst aufgebaut werden könnte).
3. Category:Frozen Breitenauer See erstellen, analog zu Category:Frozen Lake Constance, Category:Frozen Dümmersee in February 2012, etc. und dort nur die Bilder mit zugefrorenem See einordnen.

Was meint ihr dazu?

Gruß Triplec85 (talk) 07:27, 1 April 2021 (UTC)

Winter in geht im Englischen bei einem Land, einer Stadt usw., nicht bei einem See. Ist wie im Deutschen auch: Winter in Deutschland geht, Winter im Bodensee geht nicht. Siehe auch die Unterkategorien von Category:Forests by season und Category:Leaves by season: Forests in spring‎, Forests in summer, Forests in autumn, Forests in winter usw. --Rosenzweig τ 08:01, 1 April 2021 (UTC)

@Rosenzweig: Danke für die Info. @Sarang: Ich habe mal verschoben auf Category:Breitenauer See in winter und die 107 Dateien dorthin verschoben sowie die deutschsprachige Category gelöscht. Gruß Triplec85 (talk) 19:47, 1 April 2021 (UTC)

P.S. habe noch 9 weitere Category's erstellt und die Bilder rund um den See nach Themen oder Jahreszeiten einsortiert, sowie eine Wikidata-Verknüpfung per Infobox hergestellt, siehe Category:Breitenauer See Triplec85 (talk) 20:39, 1 April 2021 (UTC)

P.P.S. Weil es dazu gepasst hat und die Bilder immer mehr wurden, habe ich die Category:Winter in Landkreis Heilbronn nach Jahren unterteilt. So können zukünftig problemlos weitere Bilder in großer Anzahl dazukommen. Und man behält den Überblick. Gruß Triplec85 (talk) 20:41, 2 April 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 15:18, 4 April 2021 (UTC)

File:Davisson-Germer experiment.svg

hi und hi auch hi @JoKalliauer: - im zusammenhang zu dem file hätte ich ein paar fragen - ich kenne zwei vilidatoren bzw. drei:

• code: https://validator.w3.org/
• darstellung 1: http://tools.wmflabs.org/svgcheck/
• darstellung 2: https://commons.wikimedia.org/wiki/Commons:Commons SVG Checker

die beiden validatoren stellen das file unterschiedlich dar - wenn man z.b. 'electron beam' betrachtet, da frage ich mich nun welches der beiden ist sinnvoller zu bewerten um im zweifel korrekturen vorzunehmen?

@Mrmw: die verschiedenen validatoren haben nicht nur unterschiedliche historien, mit jeweils eigenen unzukommlichkeiten, sie liefern auch oft unterschiedliche ergebnisse/fehlerzahlen, weil sie ihre eigenen ansichten haben was noch valide ist und was nicht mehr. das vom script verwendete tool kann manchmal eine vollkommen andere fehleranzahl - mehr oder auch weniger - finden als das tool des W3C-link vom Igen. und naturlich stellen sie das validationsergebnis unterschiedlich dar -- sarang♥사랑 10:13, 2 April 2021 (UTC)

die zweite frage bezieht sich auf den schrifttyp 'condensed' - bei beschriftungen ist häufig bedarf an schmalen schriften - oft findet man files mit dem attribut 'condensed' bzw. 'semi-condensed' - ist das valide? kann das vom wiki-renderer korrekt verarbeitet werden? - was ist hierbei die allgemeine empfehlung? - vielen dank im voraus --Mrmw (talk) 08:02, 2 April 2021 (UTC)

@Mrmw: Das PNG auf File:Davisson-Germer_experiment.svg sowie :Commons:Commons:Commons SVG Checker verwenden Liberation Sans, hingegen https://svgcheck.toolforge.org/index.php verwendet eine andere Schrift. Ich verwende immer c:Commons:Commons SVG Checker, weil er auch relevante librsvg-Warnungen/Font-warnungen anzeigt. https://svgcheck.toolforge.org/index.php hingegen schafft größere Dateien ohne Anzustürzen.

@Jarry1250 and Glrx: do you know why https://svgcheck.toolforge.org/index.php does render https://commons.wikimedia.org/wiki/File:Liberation-fonts.svg with imho "DejaVu Sans" and "DejaVu Serif"?

 — Johannes Kalliauer - Talk | Contributions 09:08, 2 April 2021 (UTC)

@JoKalliauer: I do not know, but I will guess.

The source for svgcheck is at GitHub. The source indicates a copy of /usr/bin/rsvg-convert builds the PNG. It is possible that the fonts available and the font substitution rules on ToolForge.org are different than the fonts and rules on WMF image servers. Both hosts are apparently aware of Liberation Sans; if I display the SVG locally on my machine, the fonts all become Times New Roman (no serif/sans-serif/monotype).

IIRC, when WMF was working on SVGTranslate, it had the WMF image servers paint the SVG, so its rendering uses the production font information rather than an approximation to it. Glrx (talk) 22:31, 2 April 2021 (UTC)

@Glrx: Thanks for checking the source, however till shortly (not any more) c:Commons:Commons_SVG_Checker and svgcheck used 2.40.16, so c:Commons:Commons_SVG_Checker should also run on ToolForge.org not on WMF servers.

@TilmannR: However File:Identify_renderer.svg is now rendered with a newer rsvg-version (earlier, with 2.40.16, it showed "SVG Checker"), and svgcheck declares now it uses 2.40.21.

https://apt-browser.toolforge.org/stretch-wikimedia/component/thumbor/ declares to use 2.40.20-3, which is imo the WMF server-version, also the website is on toolforge?

 — Johannes Kalliauer - Talk | Contributions 09:20, 3 April 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 15:18, 4 April 2021 (UTC)

File:Acht-trigramme.svg

hi, 1) mir ist aufgefallen, dass die linejoins außen nicht sauber ineinander übergehen
2) wieso ein weisser hintergrund? gibt es hierfür eine notwendigkeit? gibt es irgendwo in der wikipedia oder commons schriftliche hinweise und oder empfehlungen hierfür? danke --Mrmw (talk) 18:45, 3 April 2021 (UTC)

das scheint ja ein ziemlicher ​murks zu sein. dabei ware es eine recht einfache grafik, unproblematisch zu zeichnen.

weissen bg habe ich offensichtlich vom vorganger ubernommen, der wohl keinen grund hatte den plotzlich einzufuhren.

ich werde es mir nochmals ansehen. danke fur deine aufmerksamkeit! -- sarang♥사랑 20:10, 3 April 2021 (UTC)

bez. des weissen hintergrundes sollte unterschieden werden

• partiell, hier also nur das achteck, bei anderen zeichnungen wie z.b. wappen nur der schild
• das komplette bild.

es kommt wohl darauf an ob die weisse farbe ein wesentlicher bestandteil ist, zB bei fahnen, oder bei der (uberwiegenden) verwendung des bildes sinnvoll ist - wenn es also generell in andere Umgebungen eingebettet wird, wie es bei logos der fall sein kann. das gilt sicher nicht fur die meisten zeichnungen, zB diagramme, chem. strukturformeln etc.

IMHO sollte immer transparenz bevorzugt werden, wenn nicht ein gewichtiger grund anderes gebietet. da bedarf es keiner allgemeinen empfehlung, und jeder kann es letztlich so halten wie er meint. das gegenstandliche achteck sollte transparent ausgefuhrt werden. -- sarang♥사랑 06:01, 4 April 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 15:18, 4 April 2021 (UTC)

durch zufall entdeckt ...

... und dich als autor entdeckt - was macht diese vorlage und wieso hat sie keine doku? {{Source thumb}} --Mrmw (talk) 08:38, 5 April 2021 (UTC)

autor? naja, bisschen rumgepopelt hab ich dran. ​jetzt mit cat+doc(-verweis) ausreichend dokumentiert. :This section was archived on a request by: -- sarang♥사랑 09:04, 5 April 2021 (UTC)

SVG Code

Hi @Sarang: , could you help me for svg code? --Siirski (talk) 12:03, 7 April 2021 (UTC)

@Siirski: Tell me where you need help. But I must tell you that that I mainly draw simple graphics; when they are more complicated e.g. with difficult curved shapes, others my help you better. -- sarang♥사랑 12:32, 7 April 2021 (UTC)

@Sarang: , https://commons.wikimedia.org/wiki/File:Somaliland_National_Army_Emblem.svg in this file can you help me for svg code, If not, did you know someone can help me? Many Thanks --Siirski (talk) 12:48, 7 April 2021 (UTC)

Too complicated for me. But try at Commons:Graphics village pump -- sarang♥사랑 13:03, 7 April 2021 (UTC)  :This section was archived on a request by: -- sarang♥사랑 13:04, 7 April 2021 (UTC)

File:Cartesian coordinate system handedness.svg

hi, ich hab hier versucht perspektive einzubauen, das ist mit inkscape und manuellem konstruieren unter zuhilfenahme von erweiterungen möglich - findest du so ein aufwand lohnt sich generell? --Mrmw (talk) 12:57, 10 April 2021 (UTC)

gleiches gilt für File:FlaecheAlsVektor.svg --Mrmw (talk) 15:37, 10 April 2021 (UTC)

ob es sich generell lohnt? ich glaube nicht dass das generell entschieden werden kann; es sieht zweifellos besser aus, und wer wert darauf legt gute grafiken hochzuladen kann die perspektive berucksichtigen. es ist aber auch eine frage des aufwandes; einfache diagramme sollten nicht allzu aufwendig gezeichnet sein - in den beiden beispielen ist es sicher einfach per textediting machbar, ohne grosse berechnungen.​

Die FlaecheAlsVektor.svg sehe ich mit zwiepalt: einerseits sollte eine vektorisierung immer denselben namen haben wie das rasterbild. andrerseits den unglucksnamen weiterzufuhren statt "Fläche als Vektor" zu nehmen ist auch nicht so gut. vielleicht sollte in solchen fallen von schlechten namen die rasterversion renamed werden, um dann die vva-autoreferenzierung anzuwenden? -- sarang♥사랑 14:39, 12 April 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 19:10, 17 April 2021 (UTC)

File:Flag of FLAMA.svg

Greetings. Your recent disgarbaging of the file appears to have made a mistake. The shields now have 4 bezants instead of 5. Fry1989 ^eh? 16:51, 15 April 2021 (UTC)

Thanx for the info! ​It's a librsvg bug, in some sizes. I tried a workaround - should now be fine in all sizes. -- sarang♥사랑 17:28, 15 April 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 19:10, 17 April 2021 (UTC)

Cleanup

Gestern Belize, heute Albanien, keine Ahnung, ob noch mehr Dateien davon betroffen sind, aber deine Skripte arbeiten nicht korrekt und machen unnötige Arbeit. NNW 08:16, 17 May 2021 (UTC)

​Danke fur die Info, das Script ist nun korrigiert -- sarang♥사랑 15:46, 17 May 2021 (UTC)

Und korrigierst du auch die Dateibeschreibungsseiten, die noch nicht in Ordnung sind? Bei Stichproben sind mir auf die Schnelle drei aufgefallen, die noch fehlerhaft sind. NNW 15:47, 18 May 2021 (UTC)

Offensichtlich nicht. Ich werde mich ab jetzt entsprechend verhalten. NNW 17:02, 20 May 2021 (UTC)

:This section was archived on a request by: -- sarang♥사랑 12:45, 27 May 2021 (UTC)

File:Screening for skin cancer in NZ.jpg

File:Screening for skin cancer in NZ.jpg has been marked as a possible copyright violation. Wikimedia Commons only accepts free content—that is, images and other media files that can be used by anyone, for any purpose. Traditional copyright law does not grant these freedoms, and unless noted otherwise, everything you find on the web is copyrighted and not permitted here. For details on what is acceptable, please read Commons:Licensing. You may also find Commons:Copyright rules useful, or you can ask questions about Commons policies at the Commons:Help desk. If you are the copyright holder and the creator of the file, please read Commons:But it's my own work! for tips on how to provide evidence of that. The file you added has been deleted. If you have written permission from the copyright holder, please have them send us a free license release via COM:VRT. If you believe that the deletion was not in accordance with policy, you may request undeletion. (It is not necessary to request undeletion if using VRT; the file will be automatically restored at the conclusion of the process.) This file is a copyright violation for the following reason: Copyrighted poster Warning: Wikimedia Commons takes copyright violations very seriously and persistent violators will be blocked from editing.

 

A1Cafel (talk) 02:59, 8 April 2021 (UTC)

Ich fürchte, dass das gem. Commons:Derivative_works/de gelöscht werden muss, außer man macht es so: File:The_Dark_Knight_movie_poster_-_censored_copyright.jpg. Commons:De_minimis ist auch nicht anwendbar, da zentral im Bild. Hatte vor kurzem den gleichen Fehler auch mal gemacht, bei einem Poster vom Roten Kreutz, das auf einem Kleinderkontainer im Freien war, leider gilt hier nicht COM:FOP.  — Johannes Kalliauer - Talk | Contributions 21:47, 13 April 2021 (UTC)

Schade. ​Ich hatte gedacht es sei ein essentieller Beitrag zu downunder skin cancer prevention, und interessant gestaltet als eyecatcher. Ich bin da auch naiv, weil ich denke es sei doch der Sinn eine Plakats eine moglichst grosse Offentlichkeit zu finden - an C_protection denke ich da zuletzt. Naja, wenn das nicht sein darf muss es eben wieder weg -- sarang♥사랑 14:08, 14 April 2021 (UTC)

Du kannst versuchen nach den Rechten anzufragen. Ich gehe davon aus, dass Sie daran interessiert sind, dass es verbreitet wird, ob sie explizit&unwiederuflich die Rechte hergeben wollen, mag sein. Einige wollen kommerzielle Nutzung ausschließen (z.B. dass man die Frau als eine Werbung für ein Sonnenstudio verwendet), andere wollen nicht dass es bearbeitet werden darf (Veräppelung des Plakates). In meiner Erfahrung als Anfragender scheitert es meistens an Formalien (oft nicht an den Rechten), z.B: dass der Rechteinhaber es nicht dir (selbst für mich als Lizens-Reviewer gilt das gleiche), sondern an permissions-commons@wikimedia.org schicken muss, siehe Commons:Email_templates und denen das eine E-Mail mehr (wo dann alles drinnen stehen muss) dann oftmals zu viel ist. Alternativ sie veröffentlichen es selbst z.B. unter CC-BY-SA (auf ihrer Webseite), dann wäre alles einfacher.  — Johannes Kalliauer - Talk | Contributions 17:28, 14 April 2021 (UTC)
:This section was archived on a request by: -- sarang♥사랑 05:27, 29 May 2021 (UTC)

User:JoKalliauer/SVG_test_suites

Ich mag phab:40010 angehen und habe dazu User:JoKalliauer/SVG_test_suites erstellt. Da du einer der SVG-Experten bist würde ich mich über dein Feedback freuen. Ich würde gerne wissen was noch fehlt, was man noch ausarbeiten sollte, bzw wie man zu einer Entscheidung über den Renderer kommen könnte. Mein Favourit ist resvg.  — Johannes Kalliauer - Talk | Contributions 21:54, 13 April 2021 (UTC)

@JoKalliauer: Dazu fällt mir so adhoc kein zusätzliches Anliegen ein. Sehr wichtig erscheint mir das Funktionieren des text path, der phabT11420. -- sarang♥사랑 08:13, 14 April 2021 (UTC)

Das SVG hat den Pfeil in die flasche Richtung: w:de:Wikipedia:Grafikwerkstatt/Archiv/2017/Juni#Änderungen an Manfeild Autocourse track map

Also es gibt keinen Renderer und keinen Browser (zumindest weder Chrome noch Firefox) der textPath vollumfänglich unterstützt.

1. librsvg untersützt textpath gar nicht
2. resvg unterstützt TextLenght nicht bei textpath
3. Inkscape untersützt negative Offsets falsch
4. batit stürtzt tw. ab, da ist es schwerer herauszufinden, was ihn stört.

Also die w:de:Eierlegende Wollmilchsau, die alles kann gibt es nicht, aber fast alles (außer wxSVG/QtSVG) ist besser als als librsvg, insbesondere was textpath betrifft. (SVG.NET untersützt zwar kaum textpath, aber ist sonst schlechter als librsvg und wäre auch für Linux (WMF-Servers) nicht optimal.)

zu phab:T11420 gibt es bereits einige Files in den Test-suites: User:JoKalliauer/SVG_test_suites/textPath

weiß...undefiniert/ungenau

grün...richtig

rot...falsch (nicht immer im Bezug auf textpath)

schwarz...abgestürtzt

Ich kann dir also leider nicht eine Ja-Nein-Antwort geben, nur dass wxSVG/QtSVG/librsvg textPath gar nicht unterstützen und SVG.NET kaum und daher wxSVG/QtSVG/SVG.NET augeschlossen werden sollten.

Ich hoffe ich konnte deine Frage dennoch zufriedenstellend beantworten? (Auch wenn die in der Antwort geschilderten Situation vl. nicht zufriedenstellend ist.)

 — Johannes Kalliauer - Talk | Contributions 22:59, 14 April 2021 (UTC)

Hallo Johannes, ​eben hatte ich einen librsvg bug von dem ich noch nichts wusste: die Version von 15. April 12:01 der Datei Flag of FLAMA.svg zeigt in einigen Größen ein fehlerhaftes rendering, meist aber stimmt es. Gut, ich habe wieder mal SVG ausgereizt bis an die Grenzen - aber bisher hat genau das (dasharray mit 0) immer gut funktioniert. Als bug erscheint mir dass verschiedene Größen unterschiedlich rendern - wenn es immer so oder so gerendert würde wäre das weniger schlimm.

Soll ich das beschreiben, eine phabricator-Meldung loslassen? Erst mal prüfe ich weitere Dateien, ob die ähnliche Probleme zeigen. -- sarang♥사랑 05:30, 16 April 2021 (UTC)

Wenn man einen Fehler meldet, sollte man ein minimal working example machen, also ein Beispiel auf das man es reduzieren kann. Also entweder mit Commons:Commons SVG Checker (mit viewBox und einer width="..." height="..." so dass das Problem auftritt) oder mit File:Test.svg.

Kannst du mir sagen bei welcher Auflösung? (am besten mit Link z.B.: https://upload.wikimedia.org/wikipedia/commons/thumb/archive/5/58/20210415172344%21Flag_of_FLAMA.svg/800px-Flag_of_FLAMA.svg.png )

Eine phabricator-Meldung wird wenig bringen, da es entweder phab:T193352(update librsvg) ist oder es ist ein Upstream-Bug . Also schlussendlich ist phab diesbezüglich ein schwarzes Diskussionsloch. Wenn es zu den Entwicklern kommen soll muss man es auf https://gitlab.gnome.org/GNOME/librsvg/-/issues melden.

 — Johannes Kalliauer - Talk | Contributions 15:15, 17 April 2021 (UTC)

Den Fehler konnte ich soweit lokalisieren, dass er nur einmal vorkam, beim thumb-format. IMHO ist es ein bug weil er bei anderen Größen richtig rendert; aber schuld war eigentlich eine fehlerhafte Codierung, es bedurfte also gar nicht eines workaround sondern nur der richtigen Schreibung. Wenn der librsvg bei blöden Angaben ins Straucheln gerät will ich ihm das nicht anlasten, und die Jungs in Ruhe lassen - die sollen ernsthafte Fehler beheben und sich nicht mit solchem Kleinkram belasten müssen. TYI: es geht um einen Sonderfall von Pfaden der Länge null, das ist ohnehin nicht eindeutig definiert - aber es funktioniert, mit linecap lassen sich Quadrate oder Kreise zeichnen, zusammen mit dasharray sogar Serien davon. Ich glaube also, dass es nicht dafürsteht da grosses Aufhebens zu machen. Danke für deine Hinweise, aber wir wollen es vergessen, es ist ja keine Behinderung bei der Arbeit wenn der librsvg hier nicht mehr kann. -- sarang♥사랑 15:45, 17 April 2021 (UTC)
:This section was archived on a request by: -- sarang♥사랑 05:27, 29 May 2021 (UTC)

Kategorien - Sets

Hi, hast du gesehen dass ich dich hier angepingt habe? --Mrmw (talk) 12:43, 14 April 2021 (UTC)

Hi, bist du beschäftigt oder hast du keine Zeit? Überlesen oder vergessen? Nicht verstanden oder nicht zuständig? Danke im Voraus für deine Rückmeldung --Mrmw (talk) 05:29, 16 April 2021 (UTC)

Hi @Mrmw: du hast da eine sehr interessante Arbeit gemacht, und auch eine interessante Losung dafur gefunden. Mein Ansatz ware ein anderer gewesen - ein Eck zu zeichnen, und das mittels Klonen zu vervielfachen; so gesehen ist zB BlueGear3.svg ein durch Kaskadenkloning erzeugtes 32eck. Die Winkel werden naturlich oft sehr unrund, fur zB ein 35eck 360/35 = 10,285714... und fur alle 33- bis 48ecke werden 6 Klonings benotigt.

Deine Sammlung ist eine (wie gesagt: interessante) Studie, wobei ich Angaben zu deinem Herstellungsprozess und dem Algorithmus vermisse; das konnte noch in der Kategorie eingetragen werden? Eine Verwendbarkeit erscheint mir eher nicht gegeben, falls du eine Vorstellung hast wer das wofur brauchen konnte solltest du auch das erwahnen.

Deine SVG-Zeichnungen sind noch nicht igenisiert, ich habe das nur fur Polygons n07.svg gemacht, exemplarisch. -- sarang♥사랑 17:22, 16 April 2021 (UTC)

Hi, danke für Rückmeldung - ich habe bewusst auf cloning verzichtet - ich wollte einfach ein Set erstellen von gleich aufgebauten und gestalteten Vielecken - wie kommst du darauf dass ich einen Algorithmus verwendet hätte? Jedes Vieleck ist per Hand gezeichnet in Inkscape - mittels Winkeltransformation hab ich mir die roten Strahlsterne erzeugt (s. Polygons n41.svg oben) - und von denen ausgehend durch abzählen der Strahlen jedes Polygon gezeichnet

Dann werde ich die igenisierung demnächst mal durchführen - ich habe die Dateien nicht für eine unmittelbare Verwendung erstellt - aber vielleicht hat jemand mal Bedarf an so einem Set

Anmerkung was mir beim igen-Script aufgefallen ist: aus {{en|1=Vieleck n=12}} wird {{en|Vieleck n=12}} was zu einem Fehler führt wegen dem = --Mrmw (talk) 10:09, 17 April 2021 (UTC)

Danke - ​ja, ich weiss, es war eine Abwagung dass =-Zeichem sehr selten sind in der description, aber immer das |1= erzeugt wird. Falls man nicht von vornherein darauf achtet, zeigt spatestens der preview wenn das 1= bleiben muss.

Ich werde sehen ob ich eine Prufung auf das Vorkommen von = im Text hinbekomme, dann ware damit dieser Arger behoben. -- sarang♥사랑 10:35, 17 April 2021 (UTC)

Hallo @Mrmw: ich glaube ich habe es geschafft; wenn du es versuchen willst, mit und ohne = im Text, jetzt sollte es richtig sein. Gruss -- sarang♥사랑 19:10, 17 April 2021 (UTC)

:This section was archived on a request by: -- sarang♥사랑 05:27, 29 May 2021 (UTC)

SarangPet

Hi there, since the bot request is stale, it may be faster to rename it as Sarang{somethingCool}. The bot request's staling will protect you against later accusation of running undeclared bot :) You could take a legendary animal as suffix to replace "bot". Yug (talk) 12:55, 24 April 2021 (UTC)

@Yug: How about Sarangyug ? 🐉🐛🐜🐝 As long as I won't get more troubles I'll keep the present name; it is not forbidden! Just possibly irritating. All was because I wanted file mover rights; I had them for 1 week, not longer. But thank you for your concerns, Sarang🕎 or Sarang📸 would be fine user names, too 💣👾 🕋

I must admit the current management of bots make me laugh now. We are spending lot of energy to circle around while we would all gain to just play it cool and accept already active bots or users. 🤷🏻‍♂️😬💃🏻 Yug (talk) 19:56, 24 April 2021 (UTC)
:This section was archived on a request by: -- sarang♥사랑 05:27, 29 May 2021 (UTC)

Template:Derived

Template:Derived has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry. If you created this template, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it. Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

A1Cafel (talk) 02:47, 3 May 2021 (UTC)

File:⺝-order.gif

File:⺝-order.gif has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry. If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues. Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

FanNihongo (talk) 03:22, 16 May 2021 (UTC)
:This section was archived on a request by: -- sarang♥사랑 05:27, 29 May 2021 (UTC)

File:Intel Little-Endian.svg

Bei der obigen Grafik stimmt das SVG-Orginal nach dem Hochladen noch. Den PNG-Kopien fehlt aber ein bisschen etwas an den linken und rechten Rändern, rechts sogar ein Buchstabe. (S.a. Notiz!) Was läuft da falsch? Gruß, –Nomen4Omen (talk) 08:11, 19 May 2021 (UTC)

Hallo @Nomen4Omen: es ist ein wohlbekanntes Problem -mit dem wir alle leben mussen- dass unser SVG renderer seine Schwieigkeiten mit eingebettem Text hat. Text kann sowohl was den verwendeten Font betrifft, als auch bezuglich Grosse und Position von verschiedenen Renderen unterschiedlich angezeigt werden. Viele Benutzer werfen angesichts der standigen Probleme damit das Handtuch - und konvertieren den Text zu Pfaden; nach meiner Ansicht nicht die richtige Entscheidung! Ich halte auch nicht Inkscape fur das richtige Werkzeug um eine derart einfache Grafik zu erstellen; die paar Striche und Texte lassen sich schnell in paar Minuten mit einem Texteditor zusammenstellen, und die Datei ist dann eher im Bereich von einigen hundert statt 40000 Bytes gross.

Um deine Datei zu "reparieren" = vom renderer richtig anzeigen zu lassen kannst du entweder den horizontalen Pfeil und den Text "Bit offset" ein paar px nach links versetzen, oder du musst die Datei ein klein wenig breiter machen, vielleicht 766px. Beides lasst sich mit Rillkes SVGedit (der renderings des librsvg und des Browsers zeigt) leicht und schnell interaktiv ausprobieren und zurechtrucken, um es dann wenn es passt zuruckzuschreiben. Es ist lediglich deswegen ein wenig kompliziert weil im vielen Inkscape-Mull die richtigen Stellen gesucht werden mussen; der Text wird in Zeile 389 positioniert mit x="145.76666", aber der Pfeil ist in dem verworrenen und widerspruchlichen Inkscape-Code schwerer zu finden. Auf die Schnelle hilft da die Verbreiterung -- sarang♥사랑 09:04, 19 May 2021 (UTC)
:This section was archived on a request by: -- sarang♥사랑 05:27, 29 May 2021 (UTC)

File:DEU Duisburg COA.svg

Hello Sarang!

I saw that you moved the file File:DEU Duisburg OA.svg to that current name today. Is it possible that the letter "C" for COA is missing?

Best regards, Koreanovsky (talk) 12:51, 28 May 2021 (UTC)
@Koreanovsky: This typo happened, and the last hour I am trying to repair it. Thanx for your concerns -- sarang♥사랑 12:57, 28 May 2021 (UTC)

Thank you for your fast reply! :-) Best wishes, Koreanovsky (talk) 12:59, 28 May 2021 (UTC)

​Hat wegen des Fehlers lange gedauert, aber ist jetzt in Ordnung PX -- sarang♥사랑 14:16, 28 May 2021 (UTC)

Danke,​ das ging ja jetzt wirklich sehr schnell! --Jürgen Krause (talk) 14:44, 28 May 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 05:27, 29 May 2021 (UTC)

Category:CZrequest

CZrequest has been listed at Commons:Categories for discussion so that the community can discuss ways in which it should be changed. We would appreciate it if you could go to voice your opinion about this at its entry. If you created this category, please note that the fact that it has been proposed for discussion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it. If the category is up for deletion because it has been superseded, consider the notion that although the category may be deleted, your hard work (which we all greatly appreciate) lives on in the new category. In all cases, please do not take the category discussion personally. It is never intended as such. Thank you!

FanNihongo (talk) 02:26, 30 May 2021 (UTC)

 Support :This section was archived on a request by: -- sarang♥사랑 06:43, 30 May 2021 (UTC)

imgen c4= (nowiki missing?)

<!--Created with Inkscape (http://www.inkscape.org/)--> scheint bei Special:Diff/565424077 in der Anzeige zu fehlen, ich vermute da fehlt irgendwo ein <nowiki>  — Johannes Kalliauer - Talk | Contributions 20:04, 29 May 2021 (UTC)

Den Code hatte ich ohne jeden Zusatz reinkopiert, deswegen ging der Kommentar verloren. Es ist ein vergleichbares Problem mit Code (von Python etc) der pipes und brackets enthalt, der muss (auch) zur Anzeige modifiziert werden -- sarang♥사랑 06:43, 30 May 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 15:43, 5 June 2021 (UTC)

Frage zu Rechte bezüglich Konstruktionen

Servus Sarang,

ich bräuchte deine Hilfe bezüglich Rechte auf Dateien.

Bitte vergleiche die beiden Bilder File:01-Siebzehneck-1822-2.svg und File:Siebzehneck-Paucker.svg. Wenn man genau hinsieht, ist zu erkennen, die Bezeichnungen der Punkte sind in auffallend ähnlicher Position, auch die Größen der SVG-Dateien (777 × 600 Pixel) sind gleich.

Meinen Fragen:

1. Kann es sein, dass die Datei Siebzehneck-Paucker.svg von 01-Siebzehneck-1822-2.svg kopiert, Linien weggelassen und nur die rot gepunkteten Linien ergänzt wurden?
2. Wäre dies zulässig, ohne Bezug auf den „Urheber“ der Datei 01-Siebzehneck-1822-2.svg?
3. Ist darin der Eintrag George Paucker in „Quelle“ und „Urheber“ korrekt?

In der Beschreibung der Datei 01-Siebzehneck-1822-2.svg habe ich mich in „Quelle“ und „Urheber“ eingetragen, da ich die Datei erstellt habe, nach dem Muster von Georg Paucker; dies ist auch in der Beschreibung verlinkt.

4. Ist mein Eintrag in „Quelle“ und „Urheber“ korrekt?

Für deine Bemühungen ein Dankeschön im Voraus! Viele Grüße--Petrus3743 (talk) 08:28, 2 June 2021 (UTC)

Servus Petrus, beide von dir genannten Dateien beruhen auf den Paucker-1822 Zeichnungen. in deiner Datei fānde ich ein |source={{based|[https://de.wikipedia.org/wiki/Magnus_Georg_Paucker Magnus Georg Paucker]}} richtiger statt deines Own work - aber des Pauckers wird von dir ausführlich aaO Erwähnung getan. Statt als 'Autor' könnte man dich auch als 'Vektorisierer' ansehen, also |author={{AutVec|..Paucker|Petrus3743}} schreiben. Die andere Zeichnung sieht sehr nach einer Kopie der deinigen aus; wenn das der Fall ist wǎre eine diesbezgl. Erwãhnung angebracht - aber nicht obligat. Dazu kommt: wenn deine Zeichnung variert worden ist, ist ausserdem der Code von 59K auf 7K verkleinert worden, so daß kaum von lediglich Kopie gesprochen werden kann. Und das Buch von 1822 ist ohnehin gemeinfrei, ebenso wie praktisch alles sobald es nach Wikimedia hochgeladen ist.

Es besteht die begründete Vermutung dass aus deiner Datei unter Verwendung eines unbekannten Tools die andere erzeugt worden ist, sodass die Namensnennung nett gewesen wäre. Was mir als fehlend erscheint ist die Anzeige deiner Datei als other version: |other versions={{G|01-Siebzehneck-1822-2.svg}}, das kann von jedem (dir, mir, ...) nachgetragen werden. -- sarang♥사랑 09:11, 2 June 2021 (UTC)

Sarang danke, in diesem Fall könntest du mir helfen, wenn du „other versions=“ einträgst.

• Ich war immer der Meinung dass ich mich als Autor nennen darf, da diese Datei von mir erstellt wurde, das Darstellung des Originals aus dem Jahr 1822 stammt, noch dazu mit einer Weiterführung der Konstruktion von mir (vergleiche mit Original) bis zum fertigen 17-Eck, die Georg Paucker nicht dargestellt hat?--Petrus3743 (talk) 10:05, 2 June 2021 (UTC)

Du darfst dich Autor nennen, es bleibt dir überlassen ob du das detailierter einordnen willst, und den Paucker als Autor oder Ideengeber siehst und dich als Vektorisierer, Co-Autor oder Autor. Manche Benutzer machen das extrem kompliziert (bevor ich das {{Own based}} und das {{AutVec}} erstellt habe ging es auch nicht so einfach wie jetzt). ​ Ok, ich werde die o_v eintragen. -- sarang♥사랑 10:34, 2 June 2021 (UTC)

Sarang danke, dein Hinweis ist mir wichtig, denn ich möchte mich nicht Mit fremden Federn schmücken...Viele Grüße--Petrus3743 (talk) 10:44, 2 June 2021 (UTC)

Die Grenzen sind da ziemlich fließend, selten ist was ausschließlich auf dem eigenen Mist gewachsen. Es bleibt dir überlassen, wie du es formulierst, dass auch jemand anderer was beigesteuert hat. Am einfachsten ist es wenn eine in der Wiki bereits bestehende Rastergrafik ohne Änderung, also ohne jeden eigenen Beitrag, vektorisiert wird, dann können mit AutVec die beiden Wiki-User (auch wenn es wegen Identitāt derselbe ist) genannt werden. In diesem Fall ist es ein wenig komplizierter, und mehr Sache deiner Ansicht wie du es beschreiben willst. Eine Möglichkeit habe ich dir oben aufgezeigt, aber wie du es gemacht hast ist es durchaus ok. ​Und wie immer, kann jemand anderer dazu eine ganz andere Meinung haben... -- sarang♥사랑 11:58, 2 June 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 15:43, 5 June 2021 (UTC)

Category:Fake SVGs by Pierre cb

Hi:

I have seen that you have removed from this category all my uploaded images and renamed it, leaving a redirection. I would appreciate that you demand the deletion of "Category:Fake SVGs by Pierre cb" as I do not like such a category associated to my user name. Pierre cb (talk) 14:03, 5 June 2021 (UTC)

It was a fault, I wanted to remove that category from your user name. Soon it will be deleted. ​Thanx for your information! -- sarang♥사랑 15:43, 5 June 2021 (UTC)

Thanks. Pierre cb (talk) 17:15, 5 June 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 15:43, 5 June 2021 (UTC)

Template:Derived from

There is a problem with Template:Derived from that I describe at Template talk:Derived from#Broken – not automatically setting files to category. I bring it to your attention because the history shows you have some familiarity with the technical aspects of it. Thank you. Senator2029 12:51, 15 June 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 13:35, 15 June 2021 (UTC)

{{CJK-fonts}}

See also User:Yug/templates

Hello Sarang, could you help ? I just created {{CJK-fonts}}, with its bunch of parameters. Family and License2 are optional, so I want the white space before them to be optional as well. The solution I came up to is inelegant (see template's code). Do you know of a quick fix ? Note: it works as of now, so I'am just checking. No need to dig too much. Yug (talk) 17:22, 7 April 2021 (UTC)

@Yug: I am not sure whether I understood you; I tried to change the code, pls give it a look. When I misunderstood, explain more -- sarang♥사랑 17:42, 7 April 2021 (UTC)

Sarang hello, I come back to you because you are my local template expert.

I would like to add a condition based on the extension

• The license of the CJK-font will always be displayed.
• If .png, then display {{PD-font}}
• If .svg, then don't (therefor refert to font's license.s)

Is there a magic word to pick the filename's suffix (extension) ? Or should I rather add a template parameter such as |style=kaishu|suffix=png ?

I lean toward adding parameters... mainly because I don't know magic words which parse the filename so we may extract the zi, style, and extension. Yug (talk) 12:51, 8 April 2021 (UTC)

As I understand, the template should be used by a file, which can be either PNG or not? Then the code will be {{#ifeq:{{F|*|X}}|png|... otherwise use the parameter, as {{{1|}}} instead of the *. ​Is that the answer? -- sarang♥사랑 13:04, 8 April 2021 (UTC)

Parsing of a filename won't be possible without a short module sequence. That I can make as well, when I know what you need.

Yes. I can convert fonts into separate images for each characters. They can be either *-kaishu.svg or *-kaishu.png.

On style, it depends on the source font. Could be -kaishu, -songti, -mingti, -lishu, -xinshu, -caoshu, -xiaozhuan (but I won't use those which are not historically accurate, such as -xiaozhuan, nor those who are for-profit fonts).

Vector files on Commons must carry the copyright of the font, while Raster don't have to due to {{PD-font}}.

I will test your formula. Yug (talk) 13:15, 8 April 2021 (UTC)

Parsing: ​When there is a system, as e.g. after a prefix (or character?) always: a minus, one of: song, ming, li, xin, ... (the table can be very long) and then either ti or shu or ... followed by dot and valid extension,

parsing will be easy. Otherwise the filename can be split into tokens and returned as a table.

That is just a first thought. -- sarang♥사랑 15:41, 8 April 2021 (UTC)

Thank you. Yug (talk) 16:17, 8 April 2021 (UTC)

Message moved to Commons:Village_pump/Technical#Templates_:_how_to_pass_parameter_down_?. Yug (talk) 18:12, 8 April 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 08:42, 1 July 2021 (UTC)

Templates : how to pass parameter down ?

I try to copy {{PD-font}} structure, I now have :

• {{CJK-fonts}}
  • {{CJK-fonts/layout}}
  • {{CJK-fonts/doc}}
  • {{CJK-fonts/en}}

But I fail to pass down the parameters so the #if don't work as I wish. If you know about that, help is welcome. Yug (talk) 17:11, 8 April 2021 (UTC)

Hi @Yug: , I removed it back - such a simple problem is IMHO not worth to be asked at the village pump: the parameters can either be passed, one after the other, via Autotranslate to all the following subtemplates; or they can be passed to a module (when it is necessary to use one for solving e.g. string operations) by using the "parent" functionality. I know well about both.
AFAIK until now, the template needs some informations from the file name and other informations from parameters, using them for categorizing and licensing. That is not a difficult problem! When you want we can make all of it together, today. -- sarang♥사랑 07:27, 9 April 2021 (UTC)

Until now I understand:

• CJK-fonts/en needs: extension, family, font (all required); what about the Unicode codepoint?
• CJK-fonts/en passes: text, text1 (all obligate)

|extension= [required] is (always because the template is always transcluded from a file) an accessable property
|family= [optional] and |font= [optional]: are they a (always accessable) property of the file name, or both parameter values?
How can the filename be parsed, what information does it bear? When I know more I can develop the templates. -- sarang♥사랑 07:50, 9 April 2021 (UTC)

I edited your text above with required and optional status. Files will always have a file format. (But not always be based upon fonts, I plan to add this "created from other source" later, when I understand how things work). Yug (talk) 08:36, 9 April 2021 (UTC)

|extension=svg is only needed when an example should be shown for SVG. When the template is used in a file description the extension of that file is used for the decision whether SVG or not-SVG should be treated. Because this parameter is used only for the template documentation it is not decribed like the other parameters.

​It can be used, then neither the check for namespace nor the access to the filenmame will occur; but saving from this additional template work will not be an advantage – while abstention from the automatism for extension check is a disadvantage. -- sarang♥사랑 09:50, 10 April 2021 (UTC)

Sarang. I think i found a balance for this issue and associated templates. 👍🏻 I will continue minor improvement in coming weeks. Thank you for the help. Yug (talk) 23:13, 15 April 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 08:42, 1 July 2021 (UTC)

Superb minimisation work

Hi Sarang,

As a long-time hand-crafted SVG maker, I'm incredibly impressed with your ability to minimise SVG file size especially on File:Agar_(jeu_de_la_vie).svg and File:TriSquare36.svg. Do you do it manually or with specialised software? Would you have a guide on techniques you use? I must learn from you!

Cheers,
cmɢʟee ⋅τaʟκ 21:59, 27 April 2021 (UTC)

Hi @Cmglee: this is all done by hand; the good news: it can be learned. I am doing it since ten years, in the meantime I can see immediately where simplification can occur. Many examples are stored in the Category:SVG Simplified, with a lot of helpful subcategories, and the different techniques are collected in SVG simplification techniques. In all these categories the images are sorted, the most simplified are the first. Many verbal explanations are given within the categories, so I am thinking that it will be possible to get all the knowledge from there. If you need an additional hint, just ask me! Good success -- sarang♥사랑 04:37, 28 April 2021 (UTC)

@Cmglee:

Sarang's clever tricks to compress SVG files are impressive. That said, some ultra compression tricks are more suited to puzzle challenges rather than production SVG. I like fill patterns, but I dislike stroke-dasharray hacks for items that are not normally lines.

• File:TriSquare36.svg might be a difficult fill, but even 72 use elements would not make an overly large SVG file.
• File:Chess Board.svg is more sensible as a fill pattern or recursive decomposition.
• File:Aspecto do sinal nº 9 de tempestade tropical de Macau em noite.svg is more sensible as one symbol copied 3 times.

I like to see small SVG files, but I want those files to be easily understandable and easily editable by others. What if someone wanted to replace the simple objects in TriSquare36 with colored billiard balls that have specular highlights?

SVG files in the ten kilobyte range are reasonably sized. All Commons SVG files should have metadata elements that identify the creator, the license, and point back to Commons; that information takes about a kilobyte uncompressed.

Simplifying files is good. Especially if we want WMF to start serving them directly.

• File:Scheme sodium-potassium pump-en.svg had path text and copies instead of symbols. 192 kB → 26 kB (compressed size is 8.8 kB). It still has a lot of nonsense in it (e.g., multidigit coordinates), but it is no longer bloated.

I hope to see more clever tricks from Sarang, but all things in moderation.

Glrx (talk) 21:05, 28 April 2021 (UTC)

Thanks, Sarang. Your categories were insightful. I had previously simplified File:Sierpinski_carpet_6,_white_on_black.svg and wonder if you know of a better method. In case it's useful to you, I found that, where you use something like <path fill="#0F0" d="m0,0h16v10H0"/>, using <circle r="<enough 9s>" fill="<some colour>"/> is an easy way to fill the background. The viewBox clips excess pixels without problem. Pity <svg ... fill="<colour>"> doesn't set SVG background colour directly.

@Glrx: Guess I was a bit carried away by the cleverness of the dasharray trick and started seeing minimisation as a challenge. I'll try to be more sensible going forward. Re dasharray, I suppose it's ok for these purposes: File:Chain_hoist.svg (chain and gear teeth) and File:String_girdling_Earth.svg?

Cheers, cmɢʟee ⋅τaʟκ 21:54, 29 April 2021 (UTC)

P.S. I learnt of another clever use of dasharray to render weaves as in File:Vanisaac_tartan_shading.svg. I think that should be fine, right? — Preceding unsigned comment added by Cmglee (talk • contribs) 22:02, 29. Apr. 2021 (UTC)

@Cmglee: Regarding File:Vanisaac_tartan_shading.svg: Be aware of phab:T32033 (use comma , as separators in stroke-dasharray), that can be e.g. repaired by https://svgworkaroundbot.toolforge.org/ .  — Johannes Kalliauer - Talk | Contributions 16:12, 30 April 2021 (UTC)

@Glrx: @JoKalliauer: Looks like we're having a small SVG conference here! Might anyone be interested in a virtual SVG meetup to meet one another and share ideas? If there's any interest, I'll ask the regulars to w:Wikipedia:SVG_help.

Thanks for attempting to fix the file. I think that was an experiment by Vanisaac. I brought it up to highlight a novel use of stroke-dasharray – don't know if this technique is used in "production". Cheers, cmɢʟee ⋅τaʟκ 20:47, 30 April 2021 (UTC)

e/c @Cmglee: Minimisation is a challenge, and it is OK to use clever tricks. The chain and string are fine, and the tartan is amazing. Making the image is the important part of the problem; the particular methods employed are much less important. I like seeing clever tricks, and I do not want to discourage that endeavor. My comments were only that optimizations may have other consequences and that there may be limiting returns.

I am confused about the tartan. I converted a #text node to a comment, but then the old version displayed a good thumbnail rather than the bland pattern I edited. However, if I display the SVG for the old thumbnail, it only displays half the pattern. I wonder if I edited the previous rather than the current SVG. Glrx (talk) 20:53, 30 April 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 08:42, 1 July 2021 (UTC)

How is {{W|World Prison Brief}} better?

See diff.

{{W|World Prison Brief}} and [[w:World Prison Brief|]]

Both produce the same result:

World Prison Brief and World Prison Brief

But one doesn't burden the Mediawiki software with a template.

Unless you can tell me why the template is better please stop "correcting" the normal linking method.

I am reverting your edit. Feel free to put back the SVG edit, etc.. --Timeshifter (talk) 16:50, 25 June 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 08:42, 1 July 2021 (UTC)

How is {{Date|2021|05|15}} better?

See diff.

|date=2021-05-15

It shows up spelled out in English (15 May 2021) when I look at the file page. See this version:

• https://commons.wikimedia.org/w/index.php?title=File:World_map_of_prison_population_rates_from_World_Prison_Brief.svg&oldid=571301747

Same as {{Date|2021|05|15}} shows up spelled out in English (15 May 2021) in this version of the file page:

• https://commons.wikimedia.org/w/index.php?title=File:World_map_of_prison_population_rates_from_World_Prison_Brief.svg&oldid=571294435

Unless you can tell me why the template is better please stop "correcting" the normal dating method of YYYY-MM-DD. You are adding an additional template burden to the Mediawiki software.

I believe Mediawiki software spells out the date in the language of the editor, according to their preferences. --Timeshifter (talk) 17:04, 25 June 2021 (UTC)

For a long time, it made troubles when a date in ISO 8601 was followed by any text. So Perhelion's script checked for that and replaced it with a tranclusion of Template:{{Date}}. Since the Module:ISOdate has been expanded, text following the date does not any longer disturb; after some difficulties to locate where is occurs, I disabled Perhelion's date changes. As a consequence, mediawiki now does not need first to solve the Date template before treating the date with other templates and modules.

@Timeshifter: Thank you for caring Mediawiki software's burdening by templates. But your concerns are not necessary, templates (and modules) are a fine method to have things under control. When you give it a look, even the simplest file description may use cascades of hundreds of templates, which are only performed when the files are looked at. Most templates are well written and swift to perform, the "expensive" uses - e.g. existence checks - are a seldom exception only when the need exists.

Depending link templates as {{ W | World Prison Brief }}, resolving the template is much less "burden" than the link itself; and it is shorter text and easier to read than [[w:World Prison Brief|World Prison Brief]]. Furthermore, the template performs a lot of other duties, when needed: as an example, it unifies the many many different (and partly illogic!) writing forms of link templates, and cares for a neat format (e.g. replacing understrokes).

I do not believe that I ought to justify the use of templates; but I kindly ask you to obstain from reversions of my edits. Kind greeatings, -- sarang♥사랑 08:16, 26 June 2021 (UTC)

If I understand correctly what you wrote, then I don't see a substantive advantage to either template.

[[w:World Prison Brief|]] is one character longer than {{W|World Prison Brief}}

Result is same: World Prison Brief. And: World Prison Brief.

And regular linking is easier to remember for most people since it is an interwiki link. Most editors are familiar with interwiki links a lot more than the template.

I guess it comes down to whatever one remembers at the time.

I will be using the linking template.

As for the date template. You basically said the date template no longer serves its original purpose.

The order is the same without the date template: date=YYYY-MM-DD

So I see no advantage at all nowadays to using the dating template.

I doubt I will ever use the dating template. Please give me a reason why I should.

--Timeshifter (talk) 18:35, 26 June 2021 (UTC)

After using the linking template for a bit, and now that I remember it, I like it. Thanks. :) --Timeshifter (talk) 19:36, 26 June 2021 (UTC)

​There are well described linking templates for other namespaces, not only {{W}} for ns 0; there are e.g. {{U}}, {{F}}, {{T}}, {{C}}, {{M}} for ns 2, 6, 10, 14, 828 and they all offer possibilities for additional parametrizing and formatting; as a standard they all (except U) replace understrokes.

So e.g. Timeshifter can also be written Timeshifter (or Timeshifter), or User:Timeshifter, User:Timeshifter, User:Timeshifter.

[[w:World Prison Brief|]] is not just one character longer than {{W|World Prison Brief}}, because it is always expanded to a duplicate [[w:World Prison Brief|World Prison Brief]].

About the Date, it is now not longer necessary when a date in the information block is followed by additional text; but everywhere elsewhere either {{Date}} or {{ISOdate}} has to be used for a correct conversion. When you look at Flag of the United States.svg: it shows three dates; the first one, immediately following the |date=, does not need any more the Date template (but needed it prior to the expansion of the modules); the second and third date won't be correctly formatted and converted to all languages without a template. -- sarang♥사랑 05:15, 27 June 2021 (UTC)

Thanks for the info. --Timeshifter (talk) 16:18, 28 June 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 08:42, 1 July 2021 (UTC)

Umbenennung à la Lowenstein → Löwenstein

Hallo Sarang,

ich habe ganz zufällig Deine Anfrage zu Umbennungen via Bot gelesen. In einem Fall wie diesem, wo es darum geht, mehrere in einer Kategorie enthaltene Dateien umzubenennen, deren Namen alle den gleichen Schreibfehler enthalten, bietet sich eine Umbenennung über das MassRename-Script an. Du musst nur einen Admin oder FileMover finden (oder hast Du selbst FileMover-Rechte?), der das Script installiert hat, damit zurecht kommt und die Sache für Dich erledigen will. Und es sollte sich natürlich um einen klaren Fall handeln, der durch unsere doch recht strikten Regeln für das Umbenennen von Dateien erlaubt wird ;–). Im Fall „Loewenstein“ → „Löwenstein“ bin ich mir leider nicht ganz sicher, ob die Regeln die Umbenennung erlauben, sonst würde ich das gleich für Dich mit dem MassRename-Script erledigen. (Muss die Regeln nochmal lesen.) Wenn Du aber einen weiteren, ähnlichen Fall hast, der klar erlaubt ist, dann schreibe mir oder jemand anderem mit FileMover-Rechten, dann kann das mit dem MassRename-Script erledigt werden.

Herzliche Grüße, --Aristeas (talk) 18:16, 13 July 2021 (UTC)

​Danke für dein Hilfsangebot! Ich verwende einige Perhelion-scripts, massrename habe ich noch nicht installiert.

Bezüglich der Namenskorrekturen (Umbennnen von Falschschreibungen) habe ich erfahren dass die Falschschreiber das nicht schätzen - im normalen Leben sagen und schreiben sie "Löwenmühle" aber die Dateien sollen merkwürdigerweise "Loewenmuehle.jpg" heissen; das ist so gewollt! Der Sinn bleibt mir verborgen - vielleicht weil das vor 70 Jahren von der EDV nicht verkraftet werden konnte? Ein krasses Beispiel]

Wenn Korrekturen unerwünscht sind werde ich sie eben unterlassen. Eher selten, als Ausnahme werden von mir Dateien umbenannt, und dann aus anderen Gründen als der merkwürdigen Umlautschreibung. Gruß -- sarang♥사랑 19:32, 13 July 2021 (UTC)

Hallo Sarang, danke für Deine Antwort! Ja, die Leute und ihre heiligen Dateinamen, das ist eine sehr seltsame Sache, über die jeder lachen oder weinen kann. Ich verstehe das auch nicht – ich meine, ich verstehe, rein theoretisch, die Gründe, auf die jene Leute sich berufen, aber ich halte sie eben für falsch bzw. nicht mehr zutreffend. Und „Hoesslinsuelz“ ist wirklich ein herrliches Beispiel dafür, wie unlesbar das Ganze wird ;–). Noch schlimmer sind mMn übrigens diejenigen, die nahezu sinnfreie Dateinamen à la „+1+19April19-Prag-by-RalfSuperman-01323231-.jpg“ vergeben und dann mit allergrößtem Nachdruck darauf beharren, dass diese Dateien nicht umbenannt werden. Aber ich gebe zu, ich habe es auch aufgegeben und benenne keine Dateien mehr um, in denen „RalfR“ und so vorkommt, auch wenn zumindest bei den nahezu sinnfreien Dateinamen eine Zwangs-Umbenennung sinnvoll wäre …

Merke Dir aber trotzdem mal das MassRename-Script vor, denn wenn doch einmal eine Umbenennung im größeren Stil von ähnlich falsch benannten Dateien gewünscht ist, ist dieses Script eine große Erleichterung. Herzliche Grüße, --Aristeas (talk) 08:08, 14 July 2021 (UTC)

​Noch viel schlimmer finde ich Dateinamen, die bis zu 256 Stellen lang sind, wie oft USGov Dateien; und jene auschliesslich in Majuskeln; solche Namen sind unhandlich und viel schwerer zu lesen! Aber in einer offensichtlichen Wikipedia der Individualisten muss jeder damit leben. Ich kann nur für mein Teil versuchen, sinnvolle Namen zu verwenden, die ggf. auch noch die jeweilige Hierarchie abbilden, der sie angehören.

Ralf Roletschek und einige andere, viele auch Fans von Kleinschreibung und Entumlautung, liefern oft sehr gute Bilder; nur die Namen....👾-- sarang♥사랑 14:26, 14 July 2021 (UTC)
 :This section was archived on a request by: -- sarang♥사랑 06:55, 18 July 2021 (UTC)

valid vs invalid

Hallo Sarang.

Ich glaube ich habe dich schon mal irgendwo gefragt und finde den Post nur nicht mehr.

Mich würde deine Meinung interessieren, warum du meinst dass SVGs in valide und invalide getrennt werden sollen (mit Ausnahme von Bildern in Category:Pictures showing a librsvg_bug).

Ich hab Help:SVG_guidelines geschrieben (Glrx hat es etwas überarbeitet), der dem zwar nicht widerspricht, aber trotzdem eine konträre Sichtweise darstellt.

Beispielsweise

• Raster <inkscape:grid und Führungslinien <sodipodi:guide sind praktisch um Objekte in GUI auzurichten, sie beeinflussen das Rendering nicht warum sollte man die entfernen? (Sie stören Personen die per Hand editieren nicht wirklich)
• aria-label= wird verwendet um den Text der in Pfade konvertiert wurde als echten Text mit aria-label zu hinterlegen (dadurch ist es auffindbar). Pfade rendern oft besser als Text (textPath rendert z.B. gar nicht)
• vector-effect= ist ein SVG2.0-feature, wenn es unterstützt wird toll, wenn nicht wird es eh igoriert. (Rust-librsvg-2.50 untersützt teilweise SVG2.0)
• sodipodi:cx=, sodipodi:cy=, sodipodi:rx=, sodipodi:ry=, sodipodi:type="arc" dient um Kreissegmente als kreissegmente und nicht als pfad zu bearbeiten also ich kann z.B. das Zentrum oder den Radisu ändern und inkscape rechnet die Pfaddaten um, es bleibt aber immer ein Elipsenelement und wird nie eine willküliche Figur.
• data-name=, inkscape:label kann man verwenden um z.B. Postleitzahlen hineinzuschreiben, bei id muss es mit einem Buchstaben anfangen und kann auswirkungen aufs rendering haben, ist also imho mehr eine techische Referenz, als eine menschenerklärende Beschreibung, hingegen data-name kann man ändern und das Rendering bleit immer unververändert.

SVG2.0-features sind SVG1.1 invalid, wenn WMF auf rust-librsvg-2.50 updated, dann gibt es invalide Funktionen die korrekt gerendert werden, wenn wir auf Inkscape wechseln dann wird nicht nur SVG2.0 unterstützt sondern es werden sogar inkscape-features unterstützt die in keinem Standard definiert sind, warum sollte man dann so was noch als invalid definieren. Natürlich derzeit unterstützt C-librsvg2.40 keine invaliden Funktionen, aber einige der invaliden Funktionen sind für das rendering ohnehin irrelevant.

 — Johannes Kalliauer - Talk | Contributions 15:36, 27 May 2021 (UTC)

Also, sehr sinnvoll ist die Aufteilung nicht, es war die erste Möglichkeit die so extrem übervollen Kategorien etwas übersichtlicher zu bekommen. Die Sinnhaftigkeit leidet auch darunter dass Valididät von irgendwelchen Instanzen von W3C definiert ist, wobei sich die drei mir bekannten Validatoren uneins sind - eine SVG-Dateien kann von einem Validator als valide befunden werden, der andere findet 13 Syntaxverstöße, und der dritte ein paar hundert. Ganz generell, W3C-errors sagen nichts aus über Qualität einer Grafik, oder über die Anzeigbarkeit (das rendering).

Allerdings ist es interessant dass manche tools besonders zu Syntaxfehlern neigen; und manche immer den- oder dieselben Standard'fehler' produzieren. Auch ist zu beobachten dass viele Zeichner darauf achten, korrekte Syntax hochzuladen, während andere nicht einmal Dinge wie PGF-DATA entfernen (und auch sonst recht schluderig arbeiten...).

Insofern hat die Einteilung, und auch die Fehleranzahl, doch eine (wenn auch geringe) Aussagekraft. Neben in/valide gibt es noch unreferenziert sowie unprüfbar.

Es gibt andere Aufteilungskriterien die mehr Sinn ergeben:

• tool/handgezeichnet
• anzeigbar/übergroß
• Pfadtext/eingebettet/lang_switch

und eine Reihe weiterer solcher Unterscheidungen, wobei die nach Thema (icon, logo, flag, map, ...) ganz sicher die sinnvollste ist.

Insgesamt ergibt sich damit eine komplexe Kategoriestruktur, nach Validität, Größe, Thema, die oft noch weiter unterteilt wird. Hat das deine Frage halbwegs beantwortet? -- sarang♥사랑 16:31, 27 May 2021 (UTC)

Danke für die Antwort, habe gesehen, du hattest das so auch schon auf Template_talk:Created_with#Design_again:_This_template_shows_subordinate_information,_and_should_not_be_highlighted_in_any_way geantwortet.

Ich mag Kategorien mit mehr als 200 Bilder nicht, aber was (wem) bringt es einem wenn man in valide und invalide (mal abgesehen von unprüfbar und unreferenziert) trennt?, man muss immer doppelt in beiden Kategorien nachschauen, das ist meiner Meinung nach kaum übersichtlicher. z.B. wenn ich einem Gnuplot-quellcode schreiben will würde ich in SVG created with Gnuplot code nach Vorlagen nachschauen, was bringt es mir, dass ich es in valide und invalide SVGs getrennt habe, ich würde jenes nehmen was am ähnlichsten an meine Anforderungen ist (strichliert, verschiedene Farben, logaritmische Skala, gedrehte Beschriftung,...).

 — Johannes Kalliauer - Talk | Contributions 20:37, 29 May 2021 (UTC)

Hallo Johannes, um bestimmte Realisierungen zu suchen ist das bestehende System nicht nur hinderlich, es ist insofern wenig brauchbar weil ein (oft wesentlich uberwiegender) Teil gar nicht in diesen Kategorien enthalten ist - nur wenn entweder der Hochlader oder jemand anders es (zB per script o.dgl.) kategorisiert hat; und zwar richtig, und das bei Anderungen ggf. nachgefuhrt wird, ist das der Fall.

Dein Gnuplot-Beispiel: Uber Images including source code in their description kann Created with Gnuplot code gefunden werden, dort sind dann 3 Kategorien, von {{Igen}} erzeugt "PNG..." und "SVG...", die meisten sind noch manuell kategorisiert. Wie oft es sonst noch Gnuplot-Code gibt ist unbekannt! Der Automatismus bei {{Igen}} gewahrleistet ja zumindest, dass es einmal gestimmt hat, aber oft werden neue Versionen hochgeladen und die Beschreibung nicht mitgepflegt: der Code kann inzwischen ein vollkommen anderer sein. .

Deine Suche nach Gnuplot-Code musste sich also auf die drei letzten Kategorien erstrecken, wobei die SVG-Kategorie wieder dreimal unterteilt ist. Naturlich ist es leicht zu machen, dass alle PNG und SVG zusatzlich in die oberste Gnuplot-Code-Kategorie eingemischt werden, die hatte dann gegenwartig zu den 886 Dateien noch 119 + (37 + 0 + 249), also insg. 1291 Dateien, ohne Gewahr dss es alle sind. Damit ware zwar alles in einem grossen Topf - aber ob das die Suche erleichtert?

Wenn die Unterteilung valid/invalid irgendwo hinderlich ist, kann sie entfallen, doch denke ich eher dass sie zwar nicht sehr hilfreich aber doch ein interessantes Kriterium ist. Als ich (vor deiner Zeit) anfing mit dem Versuch ein wenig Ubersicht zu schaffen hatten wir hunderttausende Created with Inkscape und nicht ganz so viele Valid SVG (meist ungepruft, also viele invalide). ​Johannes, wenn du eine Idee hast irgendwas daran besser zu machen, wenn irgendjemand was besseres weiss werde ich das gerne aufgreifen und realisieren. Was wir eigentlich gut brauchen konnten ist eine Kontrolle beim Hochladen zB auf Fake SVG, eine automatische Behandlung wie es das Perhelion-script versucht - nicht nur beim Hochladen sondern vielleicht auch irgendwann auf alle bestehenden Alt-SVGs? Wir wissen dass mit manueller Kategorisierung alles Beliebige gemacht werden kann (auch ein JPG zum validen Chemdraw-SVG), hingegen ist automatische Kategorisierung dann zutreffend wenn der Algorithmus stimmt.

Noch speziell zu deinen obigen Beispielen: genau das habe ich damals gemeint mit meinem Vorschlag, neben "valide" und "invalide" die Qualitat "severe warning" einzufuhren fur lassliche Sunden; das wurde erlauben Dateien die keine ernsthafteren Syntaxverstosse aufweisen entweder nach wie vor als invalid, oder mit zugedruckten Augen dann behelfsmassig als noch valide zu kategorisieren wenn es sinnvoller ist. Zur Zeit werden die "warnings" ja auch ignoriert weil sie uns nicht weiter interessieren. Wenn also W3C zB zu "invalide" die Zusatzinformation vermittelt, dass die Invalididat ausschliesslich wegen dieser endlichen Anzahl von minder schweren Regelverletzungen bzw. Tool-Eigenwilligkeiten besteht, ware so eine flexible Reaktion machbar. Theoretisch konnte auch das script den Validierungsoutput untersuchen, aber das ist sicher viel aufwendiger.

Es liesse sich noch lange daruber philosophieren, ich publiziere dieses "Wort zum Sonntag" mal. -- sarang♥사랑 09:44, 30 May 2021 (UTC)

Hallo @JoKalliauer: ich hatte kein Ping an dich gesetzt, moglicheise hast du es nicht gesehen? -- sarang♥사랑 06:40, 11 June 2021 (UTC)

Ich hab es gesehen. Ich kann nur nichts Konstruktives ergänzen.

Kategorien: Wenn ich einen Beispielcode suche stört mich die Unterkategorisierung etwas, aber es ist auch nicht weiter relevant, weil es sind max 4 Kategorien (Überkategorie+valid+invalid+unidentifizierbar), aber da ich eh nur ein Beispiel brauche, durchsuche ich oft eh nur eine Kategorie. Grundsätlich unterstütze ich eine feinere Kategorisierung in großen Kategorien, und nur weil ich es nicht brauche heißt es nicht, dass es nicht nützlich ist. Daher weiß ich nicht was das Optimium ist.

Fake SVG Wenn ich mir Commons_talk:Overwriting_existing_files#replace_by_file_with_correct_extension vom letzten Monat anschaue, dann sehe ich in der Community keine Einigung etwas aktiv gegen Fake-SVGs zu machen. Solange die Community sich nicht dafür entscheidet sie als "out of scope" zu definieren, ist da nichts zu machen. (Die Entscheidung wird nicht kommen, nicht aus Uninformiertheit sonden weil unterschieldiche Leute eine andere Sichtweise haben. Ich zwinge Leuten Informationen auf, aber keine Sichtweisen, insofern akzeptiere ich was-auch-immer die aktuellen Meinungsmacher der Community entscheiden.)

xml-Syntaxverstosse werden mit einem "Upload-filter" geblockt (ansonsten gäbe es auch nicht phab:T279239 und phab:T279240)

flexible Reaktion: Damit wird es mMn unobjektiver intransparenter und schwerer überprüfbar. Ist SVG2.0-features invalide die von rust-librsvg 2.50 unterstützt werden? Sind informationen die nicht in das Renderverhalten eingreifen (Beschriftungen, Hilfslinien (guides)) invalide, warum sie werden ja richtig gerendert? Schlussendlich gibt es wenige errors (z.B. flowRoot) die wirkliche Relevanz haben, die wichtigsten Checks sind vermutlich auf Commons:Commons_SVG_Checker#Checks gelistet. Also vl. sollte man versuchen Commons:Commons_SVG_Checker#Checks als Bug-checker zu verwenden?

Wort zum Sonntag vermutlich kennst du schon w:de:Wikipedia:Kurier und w:en:Wikipedia:Wikipedia_Signpost, dort kann man mal einen Artikel publizieren.

 — Johannes Kalliauer - Talk | Contributions 13:37, 11 June 2021 (UTC)

​Wieweit der Commons_SVG_Checker im script verwendbar sein konnte kann ich nicht beurteilen, leider kann ich immer noch nicht JS (wenn du in Commons_talk:Overwriting existing files#replace_by_file_with_correct_extension von "Sarang's skript" sprichst ist das zuviel der Ehre, es ist nach wie vor Perhelions script an dem ich rummurkse: ich war in Versuchung das auszubessern - aber es sollen ja nicht die posts von anderen korrigiert werden ich mache es manchmal doch wenn es sich nur um deine Legasthenie handelt Bisher konnte ich keine kompetente Hilfe bei meinen JS-Problemen finden).

Das 'Publizieren des Worts zum Sonntag' war missverstandlich, ich meinte dass ich mit dem Beitrag/der Antwort noch nicht fertig sei aber an diesem Sonntag (30.05.) mal alles bisherige sichern wollte; zwar ist fur "Publish changes" das deutsche Aquivalent "Anderungen veroffentlichen" aber ich habe es mehr wortlich vom 'publish' ubersetzt. Ich habe also nicht vor einen Artikel zu verfassen. Schones Wochenende! -- sarang♥사랑 07:25, 12 June 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 04:43, 25 July 2021 (UTC)

Code issues in User:Sarang/simpleSVGcheck/sandbox.js

Hi Sarang, I am a bored bot (this is kind of a computer program) that is watching the recent changes and tapping buttons like I did now.

Curious about the reason? Possibly not but I will tell you anyway:

1. You edited User:Sarang/simpleSVGcheck/sandbox.js. Glad to see you coding in javascript! Have you ever considered becoming a MediaWiki hacker?
2. Though, that change appears to introduce 10 new jshint issues — the page's status is now having ERRORS. Note that invalid or ambiguous code often has unwanted side effects like breaking other tools for you. If you cannot find out how to fix it, I suggest blanking the page for now.
3. To help you understanding where the issues are, I have aggregated a report here and now. If you have questions, don't hesitate to ask users experienced in javascript writing for help. But do not ask the bot's operators (chronically overwrought) unless you suspect an error of mine. If you prefer not getting spammed by me, you can opt-out reports by adding {{ValidationOptOut|type=all}} to your user page or cmb-opt-out anywhere on your your global user page on Meta. Good luck at Wikimedia Commons and happy hacking!

1. ISSUE: line 568 character 29: Use '===' to compare with 'null'. - Evidence: if (boolres == null) // CommonsMaintenanceBot issue
2. ISSUE: line 1180 character 13: Possible strict violation. - Evidence: this.textTrans = 0; // Logos don't get translated
3. ISSUE: line 1270 character 44: Possible strict violation. - Evidence: toolName = _ucfirst(toolName) || ((this.curSize && this.curSize > 50 && this.curSize < 2000) ? 'T' : 'U');
4. ISSUE: line 1270 character 60: Possible strict violation. - Evidence: toolName = _ucfirst(toolName) || ((this.curSize && this.curSize > 50 && this.curSize < 2000) ? 'T' : 'U');
5. ISSUE: line 1270 character 81: Possible strict violation. - Evidence: toolName = _ucfirst(toolName) || ((this.curSize && this.curSize > 50 && this.curSize < 2000) ? 'T' : 'U');
6. ISSUE: line 1365 character 17: Possible strict violation. - Evidence: this.setIgen(IgenName += (toolName || '×?×') + (err ? '|' + err.toString() : '') + '|+|s=' + s, tempPre);
7. ISSUE: line 1373 character 13: Possible strict violation. - Evidence: if (this.badSVG) {
8. ISSUE: line 1376 character 17: Possible strict violation. - Evidence: if (this.badSVG > 1)
9. ISSUE: line 1381 character 13: Possible strict violation. - Evidence: if (this.curSize > 3407872) // 3407872 = 3.4M; 4194304 = 4M
10. ISSUE: line 1383 character 13: Possible strict violation. - Evidence: if (this.textPath)
11. ISSUE: line 1385 character 13: Possible strict violation. - Evidence: if (this.PGF)
12. ISSUE: line 1387 character 18: Possible strict violation. - Evidence: else if (this.switchTrans)
13. ISSUE: line 1389 character 18: Possible strict violation. - Evidence: else if (this.textTrans && !/\|%/.test(p5) && toolName !== 'Wpdc') // ed_wdh
14. ISSUE: line 1508 character 6: Expected an identifier and instead saw ','. - Evidence: },
15. ISSUE: line 1508 character 7: Missing semicolon. - Evidence: },
16. ISSUE: line 1510 character 20: Label 'addToFileDesc' on function statement. - Evidence: addToFileDesc: function ($textarea, e, warn, toolName) {
17. ISSUE: line 1510 character 29: Missing name in function declaration. - Evidence: addToFileDesc: function ($textarea, e, warn, toolName) {
18. ISSUE: line 1547 character 6: Expected an identifier and instead saw ','. - Evidence: },
19. ISSUE: line 1547 character 7: Missing semicolon. - Evidence: },
20. ISSUE: line 1549 character 17: Label 'addIgenURL' on function statement. - Evidence: addIgenURL: function (err, size, toolName, para) {
21. ISSUE: line 1549 character 26: Missing name in function declaration. - Evidence: addIgenURL: function (err, size, toolName, para) {
22. ISSUE: line 1549 character 26: '{a}' is already defined. - Evidence: addIgenURL: function (err, size, toolName, para) {
23. ISSUE: line 1562 character 6: Expected an identifier and instead saw ','. - Evidence: },
24. ISSUE: line 1562 character 7: Missing semicolon. - Evidence: },
25. ISSUE: line 1570 character 19: Label 'getTempBlock' on function statement. - Evidence: getTempBlock: function (fullStr, start) {
26. ISSUE: line 1570 character 28: Missing name in function declaration. - Evidence: getTempBlock: function (fullStr, start) {
27. ISSUE: line 1570 character 28: '{a}' is already defined. - Evidence: getTempBlock: function (fullStr, start) {
28. ISSUE: line 1585 character 6: Expected an identifier and instead saw ','. - Evidence: },
29. ISSUE: line 1585 character 7: Missing semicolon. - Evidence: },
30. ISSUE: line 1587 character 20: Label 'insertIgenSub' on function statement. - Evidence: insertIgenSub: function () {
31. ISSUE: line 1587 character 29: Missing name in function declaration. - Evidence: insertIgenSub: function () {
32. ISSUE: line 1587 character 29: '{a}' is already defined. - Evidence: insertIgenSub: function () {
33. ISSUE: line 1634 character 6: Expected an identifier and instead saw ','. - Evidence: },
34. ISSUE: line 1634 character 7: Missing semicolon. - Evidence: },
35. ISSUE: line 1636 character 19: Label 'insertAutVec' on function statement. - Evidence: insertAutVec: function ($textarea) {
36. ISSUE: line 1636 character 28: Missing name in function declaration. - Evidence: insertAutVec: function ($textarea) {
37. ISSUE: line 1636 character 28: '{a}' is already defined. - Evidence: insertAutVec: function ($textarea) {
38. ISSUE: line 1664 character 6: Expected an identifier and instead saw ','. - Evidence: },
39. ISSUE: line 1664 character 7: Missing semicolon. - Evidence: },
40. ISSUE: line 1666 character 17: Label 'addButtons' on function statement. - Evidence: addButtons: function ($textarea) {
41. ISSUE: line 1666 character 26: Missing name in function declaration. - Evidence: addButtons: function ($textarea) {
42. ISSUE: line 1666 character 26: '{a}' is already defined. - Evidence: addButtons: function ($textarea) {
43. ISSUE: line 1748 character 6: Expected an identifier and instead saw ','. - Evidence: },
44. ISSUE: line 1748 character 7: Missing semicolon. - Evidence: },
45. ISSUE: line 1749 character 17: Label 'getIgenTop' on function statement. - Evidence: getIgenTop: function () {
46. ISSUE: line 1749 character 26: Missing name in function declaration. - Evidence: getIgenTop: function () {
47. ISSUE: line 1749 character 26: '{a}' is already defined. - Evidence: getIgenTop: function () {
48. ISSUE: line 1861 character 6: Expected an identifier and instead saw ','. - Evidence: },
49. ISSUE: line 1861 character 7: Missing semicolon. - Evidence: },
50. ISSUE: line 1863 character 17: Label 'addToolbar' on function statement. - Evidence: addToolbar: function () {
51. ISSUE: line 1863 character 17: Too many errors. (93% scanned). - Evidence: undefined

Your CommonsMaintenanceBot (talk) at 06:20, 30 July 2021 (UTC).

This section was archived on a request by: -- sarang♥사랑 07:31, 22 August 2021 (UTC)

We need your feedback!

Hello. Apologies if this message is not in your native language: please feel free to respond in the language of your choice. Thank you!

I am writing to you because we are looking for feedback for a new Wikimedia Foundation project, Structured Data Across Wikimedia (SDAW). SDAW is a grant-funded programme that will explore ways to structure content on wikitext pages in a way that will be machine-recognizable and -relatable, in order to make reading, editing, and searching easier and more accessible across projects and on the Internet. We are now focusing on designing and building image suggestion features for experienced users.

We have some questions to ask you about your experience with uploading images here on Wikimedia Commons and then adding them to Wikipedia. You can answer these questions on a specific feedback page on Mediawiki, where we will gather feedback. As I said, these questions are in English, but your answers do not need to be in English! You can also answer in your own language, if you feel more comfortable.

Once the collecting of feedback will be over, we will sum it up and share with you a summary, along with updated mocks that will incorporate your inputs.

Also, if you want to keep in touch with us or you want to know more about the project, you can subscribe to our newsletter.

Hope to hear from you soon! -- Sannita (WMF) (talk to me!) 09:57, 2 August 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 07:31, 22 August 2021 (UTC)

Code issues in User:Sarang/simpleSVGcheck/sandbox.js

Hi Sarang, I am a bored bot (this is kind of a computer program) that is watching the recent changes and tapping buttons like I did now.

Curious about the reason? Possibly not but I will tell you anyway:

1. You edited User:Sarang/simpleSVGcheck/sandbox.js. Glad to see you coding in javascript! Have you ever considered becoming a MediaWiki hacker?
2. Though, that change appears to introduce 1 new jshint issue — the page's status is now having ERRORS. Note that invalid or ambiguous code often has unwanted side effects like breaking other tools for you. If you cannot find out how to fix it, I suggest blanking the page for now.
3. To help you understanding where the issues are, I have aggregated a report here and now. If you have questions, don't hesitate to ask users experienced in javascript writing for help. But do not ask the bot's operators (chronically overwrought) unless you suspect an error of mine. If you prefer not getting spammed by me, you can opt-out reports by adding {{ValidationOptOut|type=all}} to your user page or cmb-opt-out anywhere on your your global user page on Meta. Good luck at Wikimedia Commons and happy hacking!

1. ISSUE: line 574 character 29: Use '===' to compare with 'null'. - Evidence: if (boolres == null) // CommonsMaintenanceBot issue

Your CommonsMaintenanceBot (talk) at 18:58, 6 August 2021 (UTC).

This section was archived on a request by: -- sarang♥사랑 07:31, 22 August 2021 (UTC)

Code issues in User:Sarang/simpleSVGcheck/sandbox.js

Hi Sarang, I am a bored bot (this is kind of a computer program) that is watching the recent changes and tapping buttons like I did now.

Curious about the reason? Possibly not but I will tell you anyway:

1. You edited User:Sarang/simpleSVGcheck/sandbox.js. Glad to see you coding in javascript! Have you ever considered becoming a MediaWiki hacker?
2. Though, that change appears to introduce 41 new jshint issues — the page's status is now having ERRORS. Note that invalid or ambiguous code often has unwanted side effects like breaking other tools for you. If you cannot find out how to fix it, I suggest blanking the page for now.
3. To help you understanding where the issues are, I have aggregated a report here and now. If you have questions, don't hesitate to ask users experienced in javascript writing for help. But do not ask the bot's operators (chronically overwrought) unless you suspect an error of mine. If you prefer not getting spammed by me, you can opt-out reports by adding {{ValidationOptOut|type=all}} to your user page or cmb-opt-out anywhere on your your global user page on Meta. Good luck at Wikimedia Commons and happy hacking!

1. ISSUE: line 543 character 10: Missing semicolon. - Evidence: async function pageexists( pagename ) {
2. ISSUE: line 544 character 10: Missing semicolon. - Evidence: await mw.loader.using( 'mediawiki.api' );
3. ISSUE: line 553 character 13: Expected '(' and instead saw '{'. - Evidence: } catch {
4. ISSUE: line 554 character 16: Expected ')' and instead saw 'null'. - Evidence: return null;
5. ISSUE: line 554 character 20: Expected '{' and instead saw ';'. - Evidence: return null;
6. ISSUE: line 554 character 20: Unnecessary semicolon. - Evidence: return null;
7. ISSUE: line 566 character 9: Expected '}' to match '{' from line 45 and instead saw 'function'. - Evidence: function userexist( username, namespace )
8. ISSUE: line 566 character 17: Missing semicolon. - Evidence: function userexist( username, namespace )
9. ISSUE: line 566 character 50: Missing semicolon. - Evidence: function userexist( username, namespace )
10. ISSUE: line 571 character 29: Use '===' to compare with 'null'. - Evidence: if (boolres == null) // CommonsMaintenanceBot issue
11. ISSUE: line 1519 character 18: Expected ')' to match '(' from line 26 and instead saw ':'. - Evidence: addToFileDesc: function ($textarea, e, warn, toolName) {
12. ISSUE: line 1519 character 19: Missing semicolon. - Evidence: addToFileDesc: function ($textarea, e, warn, toolName) {
13. ISSUE: line 1519 character 29: Missing name in function declaration. - Evidence: addToFileDesc: function ($textarea, e, warn, toolName) {
14. ISSUE: line 1556 character 6: Expected an identifier and instead saw ','. - Evidence: },
15. ISSUE: line 1556 character 7: Missing semicolon. - Evidence: },
16. ISSUE: line 1558 character 17: Label 'addIgenURL' on function statement. - Evidence: addIgenURL: function (err, size, toolName, para) {
17. ISSUE: line 1558 character 26: Missing name in function declaration. - Evidence: addIgenURL: function (err, size, toolName, para) {
18. ISSUE: line 1571 character 6: Expected an identifier and instead saw ','. - Evidence: },
19. ISSUE: line 1571 character 7: Missing semicolon. - Evidence: },
20. ISSUE: line 1579 character 19: Label 'getTempBlock' on function statement. - Evidence: getTempBlock: function (fullStr, start) {
21. ISSUE: line 1579 character 28: Missing name in function declaration. - Evidence: getTempBlock: function (fullStr, start) {
22. ISSUE: line 1594 character 6: Expected an identifier and instead saw ','. - Evidence: },
23. ISSUE: line 1594 character 7: Missing semicolon. - Evidence: },
24. ISSUE: line 1596 character 20: Label 'insertIgenSub' on function statement. - Evidence: insertIgenSub: function () {
25. ISSUE: line 1596 character 29: Missing name in function declaration. - Evidence: insertIgenSub: function () {
26. ISSUE: line 1643 character 6: Expected an identifier and instead saw ','. - Evidence: },
27. ISSUE: line 1643 character 7: Missing semicolon. - Evidence: },
28. ISSUE: line 1645 character 19: Label 'insertAutVec' on function statement. - Evidence: insertAutVec: function ($textarea) {
29. ISSUE: line 1645 character 28: Missing name in function declaration. - Evidence: insertAutVec: function ($textarea) {
30. ISSUE: line 1673 character 6: Expected an identifier and instead saw ','. - Evidence: },
31. ISSUE: line 1673 character 7: Missing semicolon. - Evidence: },
32. ISSUE: line 1675 character 17: Label 'addButtons' on function statement. - Evidence: addButtons: function ($textarea) {
33. ISSUE: line 1675 character 26: Missing name in function declaration. - Evidence: addButtons: function ($textarea) {
34. ISSUE: line 1757 character 6: Expected an identifier and instead saw ','. - Evidence: },
35. ISSUE: line 1757 character 7: Missing semicolon. - Evidence: },
36. ISSUE: line 1758 character 17: Label 'getIgenTop' on function statement. - Evidence: getIgenTop: function () {
37. ISSUE: line 1758 character 26: Missing name in function declaration. - Evidence: getIgenTop: function () {
38. ISSUE: line 1870 character 6: Expected an identifier and instead saw ','. - Evidence: },
39. ISSUE: line 1870 character 7: Missing semicolon. - Evidence: },
40. ISSUE: line 1872 character 17: Label 'addToolbar' on function statement. - Evidence: addToolbar: function () {
41. ISSUE: line 1872 character 26: Missing name in function declaration. - Evidence: addToolbar: function () {
42. ISSUE: line 1924 character 1: Expected '(end)' and instead saw '}'. - Evidence: };

Your CommonsMaintenanceBot (talk) at 19:32, 6 August 2021 (UTC).

This section was archived on a request by: -- sarang♥사랑 07:31, 22 August 2021 (UTC)

Code issues in User:Sarang/simpleSVGcheck/sandbox.js

Hi Sarang, I am a bored bot (this is kind of a computer program) that is watching the recent changes and tapping buttons like I did now.

Curious about the reason? Possibly not but I will tell you anyway:

1. You edited User:Sarang/simpleSVGcheck/sandbox.js. Glad to see you coding in javascript! Have you ever considered becoming a MediaWiki hacker?
2. Though, that change appears to introduce 2 new jshint issues — the page's status is now having ERRORS. Note that invalid or ambiguous code often has unwanted side effects like breaking other tools for you. If you cannot find out how to fix it, I suggest blanking the page for now.
3. To help you understanding where the issues are, I have aggregated a report here and now. If you have questions, don't hesitate to ask users experienced in javascript writing for help. But do not ask the bot's operators (chronically overwrought) unless you suspect an error of mine. If you prefer not getting spammed by me, you can opt-out reports by adding {{ValidationOptOut|type=all}} to your user page or cmb-opt-out anywhere on your your global user page on Meta. Good luck at Wikimedia Commons and happy hacking!

1. ISSUE: line 569 character 14: Missing semicolon. - Evidence: async function userexist( username, namespace )
2. ISSUE: line 571 character 18: Missing semicolon. - Evidence: await pageexists ( username, (boolres) =>
3. ISSUE: line 575 character 29: Use '===' to compare with 'null'. - Evidence: if (boolres == null) // CommonsMaintenanceBot issue

Your CommonsMaintenanceBot (talk) at 06:10, 7 August 2021 (UTC).

This section was archived on a request by: -- sarang♥사랑 07:31, 22 August 2021 (UTC)

Code issues in User:Sarang/simpleSVGcheck/sandbox.js

Hi Sarang, I am a bored bot (this is kind of a computer program) that is watching the recent changes and tapping buttons like I did now.

Curious about the reason? Possibly not but I will tell you anyway:

1. You edited User:Sarang/simpleSVGcheck/sandbox.js. Glad to see you coding in javascript! Have you ever considered becoming a MediaWiki hacker?
2. Though, that change appears to introduce 8 new jshint issues — the page's status is now having ERRORS. Note that invalid or ambiguous code often has unwanted side effects like breaking other tools for you. If you cannot find out how to fix it, I suggest blanking the page for now.
3. To help you understanding where the issues are, I have aggregated a report here and now. If you have questions, don't hesitate to ask users experienced in javascript writing for help. But do not ask the bot's operators (chronically overwrought) unless you suspect an error of mine. If you prefer not getting spammed by me, you can opt-out reports by adding {{ValidationOptOut|type=all}} to your user page or cmb-opt-out anywhere on your your global user page on Meta. Good luck at Wikimedia Commons and happy hacking!

1. ISSUE: line 569 character 14: Missing semicolon. - Evidence: async function userexist( username, namespace )
2. ISSUE: line 575 character 29: Use '===' to compare with 'null'. - Evidence: if (boolres == null) // CommonsMaintenanceBot issue
3. ISSUE: line 1931 character 10: Missing semicolon. - Evidence: async function testexis ( pagename ) {
4. ISSUE: line 1932 character 10: Missing semicolon. - Evidence: await mw.loader.using( 'mediawiki.api' );
5. ISSUE: line 1941 character 13: Expected '(' and instead saw '{'. - Evidence: } catch {
6. ISSUE: line 1942 character 16: Expected ')' and instead saw 'null'. - Evidence: return null;
7. ISSUE: line 1942 character 20: Expected '{' and instead saw ';'. - Evidence: return null;
8. ISSUE: line 1942 character 20: Unnecessary semicolon. - Evidence: return null;
9. ISSUE: line 1955 character 1: Expected ')' to match '(' from line 26 and instead saw 'mw'. - Evidence: mw.libs.simpleSVGcheck = cSVG; // Expose globally
10. ISSUE: line 2032 character 1: Expected '(end)' and instead saw '}'. - Evidence: }

Your CommonsMaintenanceBot (talk) at 06:38, 7 August 2021 (UTC).

This section was archived on a request by: -- sarang♥사랑 07:31, 22 August 2021 (UTC)

File:Flag of England and Northern Ireland, white and gold.svg

File:Flag of England and Northern Ireland, white and gold.svg has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry. If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues. Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

GPinkerton (talk) 15:19, 19 August 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 07:31, 22 August 2021 (UTC)

File:Cuban rainbow flag.svg

File:Cuban rainbow flag.svg has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry. If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues. Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

Veverve (talk) 09:53, 16 August 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 16:13, 23 August 2021 (UTC)

Please do not remove deletion requests

---

Please do not remove deletion request tags from images before an administrator has closed the debate. If you do not agree that the image should be deleted, you can express your opinion on the deletion request page. You can find this page via a link in the deletion request tag or at Commons:Deletion requests. Thank you.

I understand your frustration but allow the process to run--Gbawden (talk) 12:25, 17 August 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 16:13, 23 August 2021 (UTC)

File:양반김.jpg

File:양반김.jpg has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry. If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues. Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

✗plicit 08:28, 5 September 2021 (UTC) :This section was archived on a request by: -- sarang♥사랑 08:12, 6 September 2021 (UTC)

Script error

Please do not remove the 1= parameter from templates such as {{En}}. See the documentation explicitly encouraging its use. —Justin (koavf)❤T☮C☺M☯ 23:14, 21 August 2021 (UTC)

@Koavf: Please would you tell me where you encountered problems with removed 1=; AFAIK you are not a user of the script. If there is any error I will repair it ASAP. -- sarang♥사랑 07:31, 22 August 2021 (UTC)

Now I gave it a look. The script can do lot of cleaning (removing obsolete text, inserting required text, replacing too-complicated specifications); in the mentioned case the 1= is useless and therefore removed. Other lines are also cleaned in that file description. There is not an error!

The documentation is a suggestion for the general use, but not an obligation for each single usage. You need not to concern, until now the script did it well. -- sarang♥사랑 13:54, 22 August 2021 (UTC)

Don't remove 1=, as it helps ensure that whatever text follows it is recognized as the correct parameter. —Justin (koavf)❤T☮C☺M☯ 15:32, 22 August 2021 (UTC)

You're also removing relevant categories. Why are you doing this? —Justin (koavf)❤T☮C☺M☯ 15:36, 22 August 2021 (UTC)

Now an intermediate category is introduced, where the previous categories are still present -- sarang♥사랑 15:53, 22 August 2021 (UTC)

You are removing the location category. You aren't even paying attention to your own edits. —Justin (koavf)❤T☮C☺M☯ 13:39, 23 August 2021 (UTC)

I do not think this is resolved. You are still removing relevant information, e.g. in the author field here: https://commons.wikimedia.org/w/index.php?title=File:Measles_vaccination_coverage_world.svg&diff=prev&oldid=584843809 Why are you doing this? Are you still removing relevant categories and the 1= parameter? —Justin (koavf)❤T☮C☺M☯ 16:21, 23 August 2021 (UTC)

Why are you removing the 1= parameter still, knowing that it is required? —Justin (koavf)❤T☮C☺M☯ 18:12, 23 August 2021 (UTC)

Why are you removing the 1= parameter still, knowing that it is required? —Justin (koavf)❤T☮C☺M☯ 16:57, 6 September 2021 (UTC)

Why did you remove Inkscape as a tool for SVG creation in the information? —Justin (koavf)❤T☮C☺M☯ 18:48, 19 September 2021 (UTC)

Even there you are completely wrong: I did not remove anything, I added the correct tool -- sarang♥사랑 19:16, 19 September 2021 (UTC)

I'd suggest you see the Administrator noticeboard link below. People feel like you are creating an error and if you don't stop and acknowledge it, you may find yourself blocked. -- Ricky81682 (talk) 07:26, 20 September 2021 (UTC)

@Ricky81682: Till report at Commons:Administrators'_noticeboard/User_problems#User_is_making_thousands_of_errors_with_an_automated_script,_refuses_to_discuss I can only see a discussion between User:Koavf and User:Sarang, without any consens. Imho just two people with different opinions. Imho for such an well known template-editor it is too early to threaten with a block. I would have started a general discussion at a less aggressive space like e.g. Template_talk:Internationalization_template_doc, to get a third opinion before reporting.

 — Johannes Kalliauer - Talk | Contributions 08:22, 20 September 2021 (UTC)

"I did not remove anything, I added the correct tool". The file before you edited: "This text-logo was created with Inkscape-default". The file after you edited: "This text-logo was created with an unknown SVG tool." I asked you why you did this and you ignored me. How is "unknown SVG tool" the "correct" tool? —Justin (koavf)❤T☮C☺M☯ 15:05, 20 September 2021 (UTC)

When Inkscape is not the tool, "created with Inkscape" is the wrong tool. When the tool is not identifyable, "created with an unknown SVG tool" is the correct tool. Is that too difficult to understand? When you are not able to understand simple facts: how about just believing me? I got a bit tired always explaining and explaining to you, without success. Would you please allow that I ignore you furthermore? Kind greetings, -- sarang♥사랑 15:19, 20 September 2021 (UTC)

If the graphic was not created with Inkscape and you can somehow know that, then sure. It's easy to explain that. It's still not clear why you think that you should ignore template requirements. Also, don't talk down to me or anyone else on this project. —Justin (koavf)❤T☮C☺M☯ 18:35, 20 September 2021 (UTC)

BTW, neither Davey2010, Prosfilaes, SHB2000 and Bidgee are generating SVG files, which means that I never touched a file of one of them. They are talking about third party misunderstandings and not of any own experience. Unfortunately none of them looked carefully and they are using just the old wrong ignorant arguments of Koavf. -- sarang♥사랑 09:46, 20 September 2021 (UTC)

I looked at {{En}}, and I've used templates like it; if there's a 1=, there's no reason to remove it. But sure, go ahead, antagonize as many other editors as possible, because wise people always do that in a community.--Prosfilaes (talk) 10:01, 20 September 2021 (UTC)

I don't know about the whole SVG thing which is why If you opened your eyes you would've seen I made no mention of it. "Unfortunately none of them looked carefully and they are using just the old wrong ignorant arguments of Koavf" - Wrong, I'm not "using the old wrong ignorant arguments of Koavf" - I looked at your edits and had a problem with one of them. Disagreeing with your edits doesn't mean I'm ignorant or simply being a sheep and agreeing entirely with someone. –Davey2010^Talk 10:11, 20 September 2021 (UTC)

Are you sure? -- sarang♥사랑 10:14, 20 September 2021 (UTC)

Positive. –Davey2010^Talk 10:17, 20 September 2021 (UTC)

Your statement "neither Davey2010, Prosfilaes, SHB2000 and Bidgee are generating SVG files" isn't a valid reason and so is "which means that I never touched a file of one of them". While Davey2010 has already disagreed to the statement "Unfortunately none of them looked carefully and they are using just the old wrong ignorant arguments of Koavf.", I also did the same as Davey2010, and totally agree that disagreeing ≠ being ignorant. SHB2000 (talk) 10:57, 20 September 2021 (UTC)

I never called any of you ignorant - please read my words correctly. I called your arguments ignorant: some of you are ignoring simple facts -- sarang♥사랑 15:33, 20 September 2021 (UTC)

What makes you think I know nothing about SVG? Because you are completely wrong, I have created SVGs in the past, just no longer have the time to spend creating them. Regardless, my comments have been about the lack of description in the edit summary to explain what you are doing and why, rather than having an edit summary of just “ (Script+SVG-template+cleanup)” which explains nothing on any changes your making. Bidgee (talk) 23:01, 20 September 2021 (UTC)

Perhaps reconsider this statement "Unfortunately none of them looked carefully and they are using just the old wrong ignorant arguments of Koavf". Also just an FYI, but I've made svg files before, it's just been a couple of years since I made them, and those weren't for Wikimedia purposes. So... what makes you think that I know nothing about svg files? SHB2000 (talk) 23:50, 20 September 2021 (UTC)

I did not tell that you do not understand SVG – I said that I did not edit SVG files of you, so you are not speaking about changes happened to your files but about third parties claims. -- sarang♥사랑 05:59, 21 September 2021 (UTC)

About the Commons:Stroke Order Project/Graphics guidelines/Bitmap animations

Hi, I will explain the situation: months ago I made a deletion request for the page: Commons:Stroke Order Project/Graphics guidelines/Bitmap animations.
So I wonder if you could go to its nomination page, to discuss whether it should be kept or not, by giving your vote. On this page you will find how to give your vote.
This request is optional, so if you can't or don't want to go, it's OK. FanNihongo (talk) 04:41, 18 October 2021 (UTC)

FanNihongo Thank you for caring about the project. Sorry I did not see your contributions, you should have inserted a "ping"; since years I am not any more on the stroke orders.

I have not at all any knowledge about GIF animation, so I cannt tell whether the page is useful. I just see that many animation requests are still waiting for fulfillment – so I think it's not yet over. -- sarang♥사랑 05:53, 18 October 2021 (UTC)

OK, thank you for your opinion, have a good day. FanNihongo (talk) 08:35, 18 October 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 05:53, 18 October 2021 (UTC)

Browser verändert Quelltext beim öffnen&speichern

Hallo!

Ich bilde mir ein, dass Firefox beim Öffnen und dann speichern (bei gewissen SVGs) einen veränderten SVG-Quelltext speichert, als die auf Commons liegt. Wenn man Ziel speichern unter klickt passiert das nicht. Ich bin mir nicht sicher ob es wirklich Firefox oder doch Google Chrome war bzw. bei welchen SVGs das auftritt. Ich bilde mir ein mit jemanden bereits darüber geredet zu haben und wollte dich fragen ob du weiß welche SVGs davon betroffen sind.

 — Johannes Kalliauer - Talk | Contributions 08:04, 30 July 2021 (UTC)

​ mir ist da nichts derartiges aufgefallen.

Ich lade oft was mit "Ziel speichern unter" runter, eher selten auch indem ich es mit Rillke öffne und von dort kopiere. Du hast da eine dritte Variante? So ganz genau habe ich nicht verstanden was du mit FF machst -- sarang♥사랑 08:15, 30 July 2021 (UTC)

@JoKalliauer:

Do you have an example SVG file that gets changed?

I would not expect the SVG source to change, but there are some possibilities

An SVG file using a less common character encoding may be converted to UTF-8. If the Commons file has encoding="Shift-JIS", then the browser may read the JIS text and convert it to a DOMSTRING (UTF-16). When asked to save the text, it may save it as UTF-8. (Commons now restricts the encodings that may be uploaded.)

I would not expect a browser to reserialize its parsed SVG. If a browser did that, then the entity references would be replaced with their definitions. For example, many Adobe files define entities such as ns_extend and ns_ai; those references would be replaced.

I expect most graphics editors to change the source code. Could that be what happened?

Glrx (talk) 17:37, 30 July 2021 (UTC)

@Sarang: I thought about open a file https://upload.wikimedia.org/wikipedia/commons/0/06/Ways_of_St-2._James_in_Europe.svg and then press Ctrl+s (or alternatively over the menu)

@Glrx: I thought a browser integrated on opening or on saving a entity into the document (displaying the souce-code was correct). This lead to confusion some time ago, cause the saved file did not agree with the source-code in the browser. Some time later I think two people saw different svg-code and discussed it, not knowing about this phenomena, later I explained the reason.

Maybe I have to check/try some svg-codes, to find a pattern causing such differences.

 — Johannes Kalliauer - Talk | Contributions 21:45, 30 July 2021 (UTC)

@Glrx: File found from @Cmglee: : https://upload.wikimedia.org/wikipedia/commons/6/67/USGS_magnitude_8_earthquakes_since_1900.svg

original file: https://upload.wikimedia.org/wikipedia/commons/6/67/USGS_magnitude_8_earthquakes_since_1900.svg

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<svg

if you open https://upload.wikimedia.org/wikipedia/commons/6/67/USGS_magnitude_8_earthquakes_since_1900.svg in Firefox and press Ctrl+s

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg

In this case Firefox

1. replace two line feed (LF) with one line feed, however if you compare line-numbers it can be very annoying/confusing.
2. replace all /> with />, removement of spaces
3. change the file-name from USGS_magnitude_8_earthquakes_since_1900.svg to the svg-title Magnitude 8.0 and greater earthquakes since 1900.svg
4. leading to a file-reduction from 115.058 bytes to 114.591 bytes

I meant more server cases, however I think you can see the Problem

 — Johannes Kalliauer - Talk | Contributions 22:08, 30 July 2021 (UTC)

https://upload.wikimedia.org/wikipedia/commons/b/b3/Chr1_idiogram.svg change from <!DOCTYPE svg PUBLIC '-//W3C//DTD SVG 1.1//EN' 'http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd'> to <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

https://upload.wikimedia.org/wikipedia/commons/f/f9/Nauru-EEZ-fr.svg

<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 11 Build 196, SVG Export Plug-In . SVG Version: 6.0.0 Build 78)  -->
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN"    "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd" [
	<!ENTITY ns_flows "http://ns.adobe.com/Flows/1.0/">
	<!ENTITY ns_extend "http://ns.adobe.com/Extensibility/1.0/">
	<!ENTITY ns_ai "http://ns.adobe.com/AdobeIllustrator/10.0/">
	<!ENTITY ns_graphs "http://ns.adobe.com/Graphs/1.0/">
	<!ENTITY ns_vars "http://ns.adobe.com/Variables/1.0/">
	<!ENTITY ns_imrep "http://ns.adobe.com/ImageReplacement/1.0/">
	<!ENTITY ns_sfw "http://ns.adobe.com/SaveForWeb/1.0/">
	<!ENTITY ns_custom "http://ns.adobe.com/GenericCustomNamespace/1.0/">
	<!ENTITY ns_adobe_xpath "http://ns.adobe.com/XPath/1.0/">
	<!ENTITY ns_svg "http://www.w3.org/2000/svg">
	<!ENTITY ns_xlink "http://www.w3.org/1999/xlink">
]>
<svg 
	 xmlns:x="&ns_extend;" xmlns:i="&ns_ai;" xmlns:graph="&ns_graphs;" i:viewOrigin="127 445" i:rulerOrigin="0 0" i:pageBounds="0 612 792 0"
	 xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" xmlns:a="http://ns.adobe.com/AdobeSVGViewerExtensions/3.0/" width="539" height="277"
	 viewBox="0 0 539 277" overflow="visible" enable-background="new 0 0 539 277" xml:space="preserve">

to

<?xml version="1.0" encoding="UTF-8"?>
<!-- Generator: Adobe Illustrator 11 Build 196, SVG Export Plug-In . SVG Version: 6.0.0 Build 78)  -->
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
<svg xmlns:x="http://ns.adobe.com/Extensibility/1.0/" xmlns:i="http://ns.adobe.com/AdobeIllustrator/10.0/" xmlns:graph="http://ns.adobe.com/Graphs/1.0/" i:viewOrigin="127 445" i:rulerOrigin="0 0" i:pageBounds="0 612 792 0" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:a="http://ns.adobe.com/AdobeSVGViewerExtensions/3.0/" width="539" height="277" viewBox="0 0 539 277" overflow="visible" enable-background="new 0 0 539 277" xml:space="preserve">

 — Johannes Kalliauer - Talk | Contributions 22:17, 30 July 2021 (UTC)

Hi both, I've noticed the change in filename, too, so have made the SVG title the same as its filename without extension. Another change is that HTML ampersand codes e.g. &#176; are replaced with their Unicode equivalents. cmɢʟee ⋅τaʟκ 19:43, 1 August 2021 (UTC)

:This section was archived on a request by: -- sarang♥사랑 08:55, 25 December 2021 (UTC)

Error in Perhelion after Admin moved code over

Hi Sarang. I hope you are doing well! Long time we don't chat!
I see that an ADMIN moved your javascript code to User:Perhelion/simpleSVGcheck.js That's awesome. There is a small error.. now the javascript code has an error when I run it and click on 'Show Preview" before I save the file. I run the javascript, I do Show Preview (before saving file changes), I see error "Unrecognized value for parameter "useskin": modern" BTW, I use the Chrome browser --The Eloquent Peasant (talk) 20:33, 31 July 2021 (UTC)

Thank you for telling me​. There are so many possibilities, impossible to test each combination, that sure the script contain errors. I can do something only when somebody let me know.

I am using the skin "MonoBook", and the Perhelion-script myself with Firefox as well as Chrom. I have no idea where the mentioned error comes from, may be that you can give me more information? Where it occurs, whether it is reproduceable; how much it disturbs your work. -- sarang♥사랑 04:54, 1 August 2021 (UTC)

It does not disturb my work too much. Step 1, run the script, file is in edit mode, Step 2, click on the button that says "Show Preview", error message is seen at top of page - Error message = "Unrecognized value for parameter "useskin": modern" -Step 3 After the error message, I can Publish Changes (save the file no problem and it updates correctly). --> Summary- I save the file anyway. There is no error when I save the file. The only problem is I can not "Show Preview" of file changes before clicking "Publish changes" button. No big deal, I think. Take care! --The Eloquent Peasant (talk) 04:59, 1 August 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 08:47, 25 December 2021 (UTC)

File:American continent proposed flag.svg

File:American continent proposed flag.svg has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry. If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues. Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

GPinkerton (talk) 21:56, 26 August 2021 (UTC) :This section was archived on a request by: -- sarang♥사랑 08:55, 25 December 2021 (UTC)

Difference Between Derived From and Extracted From Templates

Since I see you are fairly active in maintaining them, could you explain what the difference is between Template:Derived from and Template:Extracted from. I want to make sure I am using them correctly. –Noha307 (talk) 01:50, 31 August 2021 (UTC)

@Noha307: As far as I see it, there is not much difference, and taking the "wrong" one will not be too bad. But "extracted" means that a part of the former picture is physically copied to make the new one, as a cropping; with or without some ameliorations (contrast, color adaption, reparation of failures).

"Derived" means that rather ideas of the former one are developped.

There are also Attrib, esp. in heraldry, and AutVec for mere vectorizations.

When the new image is a mixture of extraction and derivation, use Attrib - or a verbal explanation. -- sarang♥사랑 06:56, 31 August 2021 (UTC)

Thanks! I tend to be anal-retentive about this type of stuff, so I appreciate it. Is that worth explaining in better detail on the templates themselves? –Noha307 (talk) 00:36, 1 September 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 08:47, 25 December 2021 (UTC)

Request to upload SVG.

• Mitu Kouhone (No background and Black color drawing).svg

https://kamon-db.net/portfolio/mitsukouhone https://irohakamon.com/kamon/koubone/mitsukoubone.html

Japanese Crest Mitu Kouhone.svg:  The version without the base of . Gameposo (talk) 11:50, 8 September 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 08:47, 25 December 2021 (UTC)

beard?

Re this edit, I think it might just be a beard? HLHJ (talk) 22:50, 12 September 2021 (UTC) :This section was archived on a request by: -- sarang♥사랑 08:47, 25 December 2021 (UTC)

Notification about possible deletion

Some contents have been listed at Commons:Deletion requests so that the community can discuss whether they should be kept or not. We would appreciate it if you could go to voice your opinion about this at their entry. If you created these pages, please note that the fact that they have been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with them, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues. Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

Affected:

• File:No FFP2.jpg

And also:

• File:Not yet FFP2.jpg

Yours sincerely, Tokfo (talk) 07:30, 18 September 2021 (UTC) :This section was archived on a request by: -- sarang♥사랑 08:55, 25 December 2021 (UTC)

COM:AN/U

---

Hello. This message is being sent to inform you that there is currently a discussion at Commons:Administrators' noticeboard/User problems#User is making thousands of errors with an automated script, refuses to discuss. This is in relation to an issue with which you may have been involved.

  — Jeff G. ツ _{please ping or talk to me} 22:40, 19 September 2021 (UTC)

Hi Sarang, könntest du dort bitte mal Stellung nehmen. --Túrelio (talk) 07:28, 20 September 2021 (UTC)

@Túrelio: danke, ich bin gerade dabei ausfuhrlich Stellung zu beziehen. ​-- sarang♥사랑 07:31, 20 September 2021 (UTC)

@Túrelio: Ich selbst verwende das Skript auch und mir war die Problematik/Strittigkeit von 1= nicht bewusst, ich sah es als eine gewünschte Syntaxvereinfachung an.

User_talk:Sarang#Script_error stellt meines Erachtens eine Einzelmeinung von User:Koavf dar.

Template:Internationalization_template_doc#Verwendung steht zwar da dass man 1= hinzufügen soll, aber die Begründung ist für Sarang's edits nicht zutreffend und somit ist es meines Erachtens nicht definiert.

Die Entfernung von 1= wurde wenn ich Sarang richtig verstehe von User:Perhelion vor etlichen Jahren zum Skript hinzugefügt und war meines Wissens bis jetzt unstrittig.

 — Johannes Kalliauer - Talk | Contributions 08:10, 20 September 2021 (UTC)

Erklärung der Meinungen

Gem. Commons:Guide_to_adminship/de#Mehrsprachigkeit versuche ich die Meinungen bezüglich 1= zu erklären (die anderen Punkte zu Igen sind meines Erachtens Nebenbemerkungen).

für 1=	gegen 1=
Wenn jemand zu dem Text ein "=" hinzufügt funktioniert die Syntax noch immer (Beispielsweise "{{de|Das Diagram zeigt eine Gleichung}}" würde bei Änderung in "{{de|Das Diagram zeigt die Gleichung 1+1=2"}} Probleme machen	Wenn jemand eine Pipe am Ende hinzufügt funktioniert die Syntax noch immer, also "{{de|1=Beschreibung}}" würde bei Änderung in "{{de|1=Beschreibung|}}" Probleme machen.
es ist klarer was das 1.Argument ist	Es ist eine einfachere Syntax

Hier ist es, anders als bei anderen Vorlagen, dass üblicherweise ein längerer Text folgt, der auch (selten aber vermutlich doch immer wieder) ein Gleichheitszeichen beinhaltet.

Es gibt meines Erachtens kein Richtig und kein Falsch, es sind verschiedene Wertigkeiten was man bevorzugen sollte, und auch wenn ich die Meldung auf Commons:Administrators' noticeboard/User problems/Archive 94#User_is_making_thousands_of_errors_with_an_automated_script,_refuses_to_discuss als verfrüht finde und ich verstehe, dass es dich aufbringt, ist es das wichtigste kühlen Kopf zu bewahren, langsam durchzuatmen und Wörter wie "ignorant" mit Bedacht zu verwenden, sie würden nur dich in ein schlechtes Licht rücken und deine Position schwächen. Ich würde die Meinung über andere Personen dem Leser überlassen.

Diese Nachricht sagt nichts aus wer was falsch gemacht hat, es soll nur ein Vermittlungsversuch sein.

 — Johannes Kalliauer - Talk | Contributions 10:19, 20 September 2021 (UTC)

Nachtrag

Vom Script wird gepruft ob der Text mindestens ein "freies" Gleichheitszeichen enthält - in diesem Fall wird das 1= natürlich belassen. Gleichheitszeichen innerhalb einer Vorlage haben nicht diese Wirkung. -- sarang♥사랑 10:32, 20 September 2021 (UTC) :This section was archived on a request by: -- sarang♥사랑 08:55, 25 December 2021 (UTC)

Your recent archival of a thread

In Special:Diff/592556188, you archived a thread while there was still discussion going on about your actions to svg files. Why? While you have every right to do so, common sense would prevail that you don't speedy archive discussions because it may be about your problematic actions. Just saying, but it does show you not wanting to discuss the problems you've made. SHB2000 (talk) 07:55, 21 September 2021 (UTC)

SHB2000 you are right, it is not my interest to continue useless discussions -- sarang♥사랑 08:29, 21 September 2021 (UTC)

"useless discussions". Useless? SHB2000 (talk) 08:32, 21 September 2021 (UTC)

@SHB2000: sarang is well within their right to archive, whether we agree with it or not. If you have an issue with it, raise it at one of the Admin noticeboards, personally I think I expressed what I had to say and had nothing further to add to it but do hope they take onboard the criticism I had regarding the lack of edit summaries. Time to move on, there are bigger issues in the World then someone archiving a dead-end discussion. Bidgee (talk) 11:52, 21 September 2021 (UTC)

Well aware of it (mentioned it in "While you have every right to do so"), although was just pointing out to sarang that it's a sign of them not willing to discuss their actions. But agree on time to move on SHB2000 (talk) 11:56, 21 September 2021 (UTC) :This section was archived on a request by: -- sarang♥사랑 08:55, 25 December 2021 (UTC)

stop removing 1=

Lieber Sarang!

Ich fasse Commons:Administrators'_noticeboard/User_problems#User_is_making_thousands_of_errors_with_an_automated_script,_refuses_to_discuss es für dich zusammen: Der Großteil deiner Änderungen sind ok, jedoch eine Änderung des Skriptes ist explizit verboten worden: Die Entfernung von "1=" in Sprachvorlagen wie {{En}} oder {{De}}. Ich werde mich noch kümmern, dies in Template:Internationalization_template_doc#Vorlagenparameter klarer darzulegen. Alle anderen Synstax-vereinheitlichungen (sortierung der Variablennamen, kleinschreibung der Variablennamen,...) sind irgendetwas zwischen erwünscht und toleriert.

Falls die Diskussion/Entscheidung unklar ist, bitte ich dich nachzufragen.

User:Davey2010, hat in Special:Diff/593033024 eine Sperre verlangt/gewünschen. Die Änderung des Skriptes braucht verständlicherweise einige Zeit, bis dahin solltest du solche Edits (entfernen von "1=") unterlassen, bzw manuell nach-korrigieren, ansonsten drohen administrative Sanktionen, wie ein temporärer Block. Sollte etwas missverständlich sein, kannst du mich fragen.

Als einer der Nutzer des Skriptes würde ich mich freuen, wenn du das Skript korrigieren könntest. Es wäre hilfreich zu wissen, ob bzw bis wann du planst das Skript zu ändern.

 — Johannes Kalliauer - Talk | Contributions 17:59, 23 September 2021 (UTC)

Blöde Frage, kann es sein, dass es im Computer im Cache das Skript zwischengespeichert ist, weil heute beim Arbeitspc hatte wollte er auch das 1= entfernen?  — Johannes Kalliauer - Talk | Contributions 18:47, 27 September 2021 (UTC)

Ich verstehe zuwenig vom caching - es erscheint mir sehr merkwurdig dass langst geanderte Funktionen wieder aufleben: eines der unerklarlichen Wunder der IT; aber es muss eine Erklarung geben, auch wenn ich sie nicht zu finden vermag. Beim script-editing wird darauf hingewiesen dass gepurgt werden soll um zuverlassig die neue Version zu aktivieren. So ein Purge wirkt doch auf den Cache, und damit auch auf alle anderen user? Oder hat jeder seinen eigenen Cache? Selbst dann kann doch nicht plotzlich wieder altes aktiv werden nachdem neues funktioniert hat. Eine Hypothese: jeder Server hat seinen Cache, und wenn du zufallig an einen anderen Server geratst der noch geschlafen hat... wie gesagt, die Materie ist mir nicht vertraut. Zum Gluck ist dieser spezielle Fall, das Entfernen oder Belassen von "1=" vollkommen unkritisch. Aber es ist sehr beunruhigend wenn Dinge nicht richtig funktionieren. -- sarang♥사랑 06:57, 28 September 2021 (UTC)

Ich mag Cookies (auch die unbeliebten Browser-Cookies). Sie ermöglichen es mir, dass ich mich nicht jedes mal auf Wikimedia einloggen muss, aber ja es gibt Datenschutz- und Sicherheitsprobleme die in zusammenhang mit Cookies stehen.

Kannst du https://commons.wikimedia.org/w/index.php?title=File:Pure-storage-vector-logo.svg&action=edit&simpleSVGcheck=0&curSize=1883&badSVG=0&PGF=0&switchTrans=0&textTrans=0 aufrufen, und mir sagen ob er auch bei dir das "1=" entfernt, oder ob das nur bei mir so ist?

Ich mag ein phab-ticket schreiben.

Ich hab schon (2) Template:Purge_client_cache versucht, (2) alle Cookies,Cache,SitePreferences,OfflineWebSiteDate in FF gelöscht (3) mit BleachBit BackupFiles,Cache,Cookies,CrashReports,DomStorage,SitePreferences,Vacuum von FF gelöscht.

Bei mir ist das Problem sogar in Chromium repoduzierbar.

Ich geh von der Arbeit heim und schau ob ich es nach einem weiteren Neustart reproduzieren kann.

 — Johannes Kalliauer - Talk | Contributions 17:16, 28 September 2021 (UTC)

Hallo Johannes, ich hab genau deinen Link zu Pure-storage-vector-logo.svg aufgerufen und mich vergewissert dass per W3C-Blume1 das script nochmal durchgefuhrt wird. Alles wird richtig gemacht und das "1=" bleibt belassen. Nur, weil der SVG-code keinerlei tool-Hinweis enthalt und die Datei kleiner als 2048 bytes ist schlagt das script 'Text editor' als tool vor. Ich habe diesen Test auch mit Opera und als User:Sarangbot mit identischem Ergebnis durchgefuhrt. Es bleibt ein Mirakel -- sarang♥사랑 08:00, 29 September 2021 (UTC)

Komisch, bei mir entfernt es "1=", aber es lässt Adobe Illustrator als Tool, siehe https://owncloud.tuwien.ac.at/index.php/s/GFJm5MmqOtGOnq4.  — Johannes Kalliauer - Talk | Contributions 08:19, 29 September 2021 (UTC)

​Ich machte mehrere Tests; nur wenn ich das bestehende |other fields= entferne kommt das script mit Text editor (das script sucht verzweifelt, wenn es nichts finden kann ubernimmt es die bestehende Adobe-Angabe).Losche es mal (temporar) weg und schaue, was der Blume1-transclude macht.

Als admin konntest du ja an das User:sarang/cleanup.js ran, aber ist gar nicht notwendig; nach dem hier empfohlenen Test setze mal einen purge auf das script ab (kann jeder user), und versuche es dann nochmals. Ich bin schon sehr gespannt ob wir finden konnen was da klemmt. Wenn wir gar nichts finden konnen weisst du vllt jemanden den man fragen kann ? -- sarang♥사랑 11:47, 29 September 2021 (UTC)

​Ich habs gefunden! Eine sehr naturliche Erklarung und ganz einfach, sobald man weiss:

ich verwende User:Sarang/simpleSVGcheck/sandbox.js, und die meisten anderen User:Perhelion/simpleSVGcheck.js – da ist alles richtig.

du aber verwendest User:Sarang/simpleSVGcheck.js, eine von mir fast vergessene Version, und da war noch eine 1= Entfernung drin! Jetzt ist auch die repariert (Z. 607), und alles muss richtig laufen. Also keine Gefahr mehr, dass ausgerehnet du zum "Law of 9/22"-Sunder wirst.

wie oben erklart, musst du das Igen ganz entfernen, damit das script nicht wieder Adobe findet. -- sarang♥사랑 14:51, 29 September 2021 (UTC) :This section was archived on a request by: -- sarang♥사랑 08:55, 25 December 2021 (UTC)

Category:Structural_formulas_created_with_SVG

Category:Structural_formulas_created_with_SVG has been listed at Commons:Categories for discussion so that the community can discuss ways in which it should be changed. We would appreciate it if you could go to voice your opinion about this at its entry. If you created this category, please note that the fact that it has been proposed for discussion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it. If the category is up for deletion because it has been superseded, consider the notion that although the category may be deleted, your hard work (which we all greatly appreciate) lives on in the new category. In all cases, please do not take the category discussion personally. It is never intended as such. Thank you!

Leyo 22:27, 23 September 2021 (UTC)  :This section was archived on a request by: -- sarang♥사랑 08:55, 25 December 2021 (UTC)

=1

Hallo Sarang,
Von diesem Punkt an können Sie den Parameter "=1" aus keiner Vorlage entfernen - dieser Parameter sollte so lange bestehen bleiben, bis Sie oder jemand anderes Einvernehmen darüber besteht, ihn zu entfernen.
Wenn Sie es weiterhin entfernen, können Sie leider aus dem Projekt ausgeschlossen werden.
Ich habe Google Translate verwendet, da ich kein Deutsch spreche,
Vielen Dank, Mit freundlichen Grüßen, –Davey2010^Talk 12:04, 24 September 2021 (UTC)

Thank you Davey2010; I have no problem to understand English — my problem is only to understand nonsense-arguments or accept nonsense-accusations. I can try to explain when people have not understood documentation, but I will not force anybody to understand or accept the truth. I cannot level up someones ability to understand simple facts, or someones intelligence, when he does not want to list but prefers to keep his wrong views.

I shall follow the orders I got but please do not come with arguments.

I have used my poor knowledge of English, hoping you can read it nevertheless -- sarang♥사랑 12:39, 24 September 2021 (UTC)

Hi Sarang, Oh okay sorry, As you're not a native English speaker I thought German might help better, Anyway no worries.

I haven't come with arguments tho - I was advised by someone to come here and ask in your native language which is what I did, no arguments here :),

Your English is fine it's a lot better than me haha!, Happy editing. –Davey2010^Talk 12:50, 24 September 2021 (UTC)

Since 2021-09-22, due to a proposal of a subcompetent user who misinterprets documentation, a rule for Commons prohibits the removal of superfluous names from positional parameters.

:This section was archived on a request by: -- sarang♥사랑 08:47, 25 December 2021 (UTC)

Category:SVG_images_with_embedded_raster_graphics:KarimKoueider

Category:SVG_images_with_embedded_raster_graphics:KarimKoueider has been listed at Commons:Categories for discussion so that the community can discuss ways in which it should be changed. We would appreciate it if you could go to voice your opinion about this at its entry. If you created this category, please note that the fact that it has been proposed for discussion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it. If the category is up for deletion because it has been superseded, consider the notion that although the category may be deleted, your hard work (which we all greatly appreciate) lives on in the new category. In all cases, please do not take the category discussion personally. It is never intended as such. Thank you!

𝟙𝟤𝟯𝟺𝐪𝑤𝒆𝓇𝟷𝟮𝟥𝟜𝓺𝔴𝕖𝖗𝟰 (𝗍𝗮𝘭𝙠) 13:40, 9 October 2021 (UTC):This section was archived on a request by: -- sarang♥사랑 08:47, 25 December 2021 (UTC)

Large circles used to fill non-circular areas on flags

Please do not use large circles to fill non-circular areas. You did this today on File:Flag of South Sudan2.svg. These files are absolutely painful to work with when they are imported into other SVG files. As an exercise, please try this:

• Open Inkscape
• Draw a rectangle that is 200px × 100px.
• Import File:Flag of South Sudan2.svg (preferably in a new semi-opaque layer)
• Attempt to make the flag fit inside the rectangle. MapGrid (talk) 00:44, 19 October 2021 (UTC)

@MapGrid: These SVG code examples are not intended to be imported by Inkscape. Draw your SVG files with any vector graphic tool, but leave the text-drawn SVG examples as they are; you do not need to use them when there are plenty of other drawings of the same object. -- sarang♥사랑 07:17, 19 October 2021 (UTC)

I learned something new today.

Generally, a scalable SVG file should have a viewBox but not width or height attributes. The purpose of the width and height attributes is to specify fixed display dimensions. Scalable images do not want fixed dimensions.

In addition, specifying the width and height to be a multiple of the viewBox seems odd. Why not 1:1?

Simply removing the width and height attributes causes display problems on browsers.

The browser display is accurate if the flag is drawn in a 2:1 container, but if the container is not that ratio, then the edges of the image become visible. If the width is too narrow, then we get more green on top. If the width is too wide, then we get more green to the left and a rounded lower-right green corner. (The flag is drawn at 114×57. The hypotenuse is 127.46, and the green circle radius is just outside that at 128.)

That suggests the real purpose of the width and height attributes is clipping the image to the proper flag dimensions. That's not the fundamental intent of those attributes. The flag dimensions should be set in the body of the SVG.

It seems simpler to use a green rectangle rather than an oversize circle. One need not calculate the hypotenuse, and one gets a more robust image.

Glrx (talk) 18:56, 19 October 2021 (UTC)

example Jamaica

You said: "Generally, a scalable SVG file should have a viewBox but not width or height attributes. The purpose of the width and height attributes is to specify fixed display dimensions. Scalable images do not want fixed dimensions."

I need to confess that I cannot understand that statement.

• when I redraw file (bitmap or SVG) e.g. 600×300, either width/height can be specified - than it is 600×300;
• when it is specified with e.g. viewBox="0 0 600 300" the code may be the same, but its size will be 512×256.

Of course can be scaled to any display, in both cases. Unscaled display is either 600×300, or 512×256.

I cannot understand any benefit from using a viewbox except for scaling coordinates, e.g. a width/height of 600×300 with viewBox="0 0 6 3" with a possible advantage that in some cases a stroke does not need a stroke-width.

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" width="600" height="300" viewBox="0 0 12 6">
<circle fill="#00973F" r="13"/>
<path stroke="#FCDB00" d="m-6,9 24-12v12L-6-3"/>
</svg>

@Glrx: How about moving this discussion to a more visible SVG guideline?

"Fixed display dimensions" occur when I use an offline renderer, the first view without zooming in/out.

My opinion about width/height and viewBox: when instead of w/h the viewBox is used, our renderer uses 512px for the sizing – which is a good value for the display; I am not completely sure whether that is a rule for all renderers.

I prefere to use always w/h, and normally a width about 600 or a height about 400 is a good value. I am using viewBox only to shorten coordinates, and then in addition to w/h – e.g. width="600" height="400" viewBox="0 0 12 8" which would be without w/h definition 512 and 341.

W/h much too small (e.g. 10×16 for small icons) need often coordinates like 0.15, and even zooming to the maximum will be too small. W/h too large give the analoguos problem that not the whole picture can be seen. While a viewBox may allow to express coordinates shorter, an image as e.g. with width="10" height="6" (for the three rectangles 10×2) will sure be much too small.

About the "first background", sure a rectangle is more correct – but the circle can cause the same effect when there is a competition depending the bytes size. It can be compared to draw circles with the linecap option. I have problems to understand the sense of your statements "The browser display is accurate if the flag is..." and "That suggests the real purpose" or "robust image".

It is not nice of me to other users when SVG code is optimized beyond readability, but nevertheless it is correct designing an image? -- sarang♥사랑 10:56, 20 October 2021 (UTC)

There may be a better place for this discussion, but I'm more interested in your viewpoint right now.

Specifying w/h is an instruction to display the image at that size. Logically, it says the image is not scaled.

It is not a rule. When confronted with a viewBox, MediaWiki assumes a width of 512 pixels and a matching height. (I do not believe that MediaWiki interprets the preserveAspectRatio attribute.) The 512px is an arbitrary choice, and other SVG agents do not need to make that choice. Most other agents are painting the SVG file within a container, and those agents will map the viewBox to that container's size. That's why browsers will display an SVG with a viewBox (but without w/h attributes) so that it fills the window.

The viewBox attribute should have a reasonable value. It's OK for the viewBox small values. If the SVG does not have the w/h attributes, then it will display full size in a browser. MediaWiki would display the image 512px wide on the Commons page. If the SVG has w/h but no viewBox, then the Commons page may show a tiny image.

For the Flag of Jamaica, deleting the w/h attributes would still produce a large display on the Commons page. It would produce odd displays in browser displays because the browsers will display the outside margins of the SVG files. The viewBox attribute sets up a transformation that maps the image to the container, but it does not impose a clip region.

The uncompressed byte size is not the best metric. GZIP compression can do a good job.

My point is that you are using the w/h attributes to implement a clipping path that trims the large circle to the flags size. If the flag is drawn to stay within the flag boundaries, then no clipping path is needed. If one uses oversize drawing elements, then there should be an explicit clipping path.

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 6">
  <clipPath id="clip"><rect width="12" height="6" /></clipPath>
  <g clip-path="url(#clip)">
    <circle fill="#00973F" r="13"/>
    <path stroke="#FCDB00" d="m-6,9 24-12v12L-6-3"/>
  </g>
</svg>

You may not like the extra characters for the clipping path, but it makes clear that the graphics outside the flag boundary should not be displayed. The semantics are clear.

The result is more robust (i.e., less likely to be displayed incorrectly).

BTW, I would use an explicit line-to after the initial move m 6,9 l 24-12 v12 L-6-3.

Glrx (talk) 20:59, 20 October 2021 (UTC)

I am a firm believer in explicitly setting width and height attributes... especially on flags. I commented on this in File talk:Flag of the Democratic Republic of the Congo.svg a few days ago. The majority of flags on Wikipedia use a height setting of around 600.

Skipping the width and height attributes leads to both annoying and inconsistent behavior when the file is displayed natively in a browser. FireFox and Chrome have different behavior than Edge.

And yes, the width:height ratio needs to need to be exactly the same as the w:h ratio used in the viewBox... otherwise nasty things start to happen. MapGrid (talk) 22:43, 20 October 2021 (UTC)

@Glrx: "removing the width and height attributes causes display problems on browsers"

Why display problems, that's a useful feature: https://upload.wikimedia.org/wikipedia/commons/c/c6/Earth_energy_budget.svg

@MapGrid: In combination with preserveAspectRatio different width:height ratios than the w:h ratio used in the viewBox, can allow useful features, see File:Test.svg

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="500" height="300" viewBox="0 0 5 1" xmlns="http://www.w3.org/2000/svg" preserveAspectRatio="xMidYMid meet">
 <circle r="6" fill="red"/>
 <rect x="0" y="0" width="5" height="1" fill="white"/>
</svg>

 — Johannes Kalliauer - Talk | Contributions 18:43, 22 October 2021 (UTC)

Also see File:Flag of Qatar.svg, the code will be more complicated if the viewBox has the same aspect ratio.--Mike Rohsopht (talk) 04:20, 23 October 2021 (UTC)

Cool. Thank you Mike and Johannes for these examples. And thank you Sarang for letting us take over your talk page! MapGrid (talk) 05:26, 23 October 2021 (UTC)

@JoKalliauer: The comment about removing width and height attributes is specific to the case when the SVG file draws outside the lines. Displaying that SVG in a browser may show extraneous portions of the image. Those SVG images need an explicit clipping path to avoid problems when used outside of Wikimedia projects. In general, I believe SVG files should specify a viewBox and not specify a width and height. The width and height attributes may make sense if the images is supposed to be a specific size.

@JoKalliauer and Mike Rohsopht: Asking the SVG agent to do the scaling rather than having the SVG file do the scaling is a contorted practice. For example, the File:Flag of Qatar.svg is

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" width="1400" height="550" viewBox="0 0 75 18" preserveAspectRatio="none">
<path d="M0,0H75V18H0" fill="#8a1538"/>
<path d="M22,18H0V0H22l6,1-6,1 6,1-6,1 6,1-6,1 6,1-6,1 6,1-6,1 6,1-6,1 6,1-6,1 6,1-6,1 6,1z" fill="#fff"/>
</svg>

The width/height attributes specify an aspect ratio of 2.5455 and the viewBox attribute specifies an aspect ratio of 4.1667.

The file confuses construction transforms with viewports. The proper way of handling the construction is to use transform="scale(sx, sy)". So it would be better to scale by (18.6667, 30.5556) and just use a viewBox="0 0 1400 550". (A further hack would increase the scale by a factor of 9 for (168, 275) to get integers.)

Glrx (talk) 16:38, 25 October 2021 (UTC):This section was archived on a request by: -- sarang♥사랑 08:47, 25 December 2021 (UTC)

SVGO

@JoKalliauer: Hallo Johannes, ich komme nicht klar mit Help:SVG_guidelines#Using_Optimizers. Schon lange vor Entwicklung deiner guidelines habe ich SVGO angewandt; in der Form dass zu einer SVG-Datei auf meinem Rechner eine weitere, optimierte Version ebendort gespeichert wurde. Aber entweder hat sich nun was geandert, oder ich bin total verblodet - ich bekomme das Ding nicht zum Laufen. Links auf github/toolforge/svgo bringen nur Infos die mich nicht interessieren, ohne jede Moglichkeit eine Datei (wo auch immer) anzugeben. Kannst dun mir bitte da helfen? -- sarang♥사랑 11:05, 7 November 2021 (UTC)

Ich verwende Linux, du verwendest vermutlich Windows?

https://nodejs.org/de/ herunterladen&installieren, dann in die Komandozeile gehen und

npm install -g npm
npm install -g svgo

sollte das Programm installieren.

svgo -i Input.svg -o Output.svg -p 5 --pretty --indent=1 --multipass verwende ich zum ausführen.

Längere Antwort später.

Wenn du nichts installieren willst, könntest du auch https://jakearchibald.github.io/svgomg/ verwenden.

 — Johannes Kalliauer - Talk | Contributions 11:14, 7 November 2021 (UTC)

​ Ja, das war es. Grossartig dass du immer alles weisst! Ich verwende den FF browser, in einer (vermutlich) Windows Umgebung - bin ich da kein Linux user?

Inzwischen habe ich festgestellt, dass wohl deswegen vieles nicht funktioniert, weil ich die automatischen updates von FF abgechaltet habe; deswegen scheine ich zZ ein nur halb arbeitsfahiges System zu haben. Also werde ich nun einen Update fahren, und mich an die dadurch verursachten Anderungen gewohnen.

Es scheint, dass ich SVGO nicht ausreden kann, alle linefeeds zu elimineren? Egal, das ist schnell wieder zuruckgeandert.

Aber: gibt es eine Option, dass alle absoluten Koordinatenwerte in relative umgerechnet werden? Ich hatte mir mal dafur ein tool erstellt, aber nun leider keinen Zugriff mehr darauf. -- sarang♥사랑 12:15, 7 November 2021 (UTC):This section was archived on a request by: -- sarang♥사랑 08:47, 25 December 2021 (UTC)

File:And Babies.jpg

File:And Babies.jpg has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry. If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues. Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

GreenC (talk) 02:53, 9 November 2021 (UTC):This section was archived on a request by: -- sarang♥사랑 08:47, 25 December 2021 (UTC)

Collagen

hallo, ich habe File:SVG Fish Symbols.svg erstellt und hätte gern dazu deine fachkundige meinung - es ist ein nicht unerheblicher aufwand, deswegen ist mir deine einschätzung wichtig - ist so eine arbeit sinnvoll? collagen dieser art hab ich noch keine gesehen - das kann daran liegen dass es schlicht nicht sinnvoll ist, oder dass sich niemand die mühe macht - bitte um klare worte - danke und gruß --Mrmw (talk) 20:18, 13 November 2021 (UTC)

Hallo Mrmw, es ist eine sehr schone arbeit, ubersichtlich und gut gruppiert. gefallt mir! ob es sinnvoll ist? - wohl eher nicht. da denke ich vor allem daran, dass heute oder morgen von jemandem ein neuer fish-icon erstellt werden kann; der fehlt dann in dieser ubersicht. oder soll dann jedesmal deine zeichnung erweitert werden, immer wieder neue uploads?

als gegenentwurf denke ich an ein categorysystem, das praktisch automatiach aktualisiert. oder an eine tabelle (ein sinvolles system ineinander verschachtelter tabellen), mittels derer eine identische darstellung wie mit dieser recht grossen datei erzielbar ist; aber mit wesentlich weniger aufwand modifizierbar!

es sieht nach viel arbeit aus: all diese dateien aufzuspuren, entscheiden welche genommen werden und welche dann doch nicht, das layout zu konzipieren, und dann alle (geschatzt: ~130) einzeldateien einzupassen.... auch ist beachtlich dass du all das in nicht viel mehr als 1 MB untergebracht hast! ich habe nicht nachgesehen kann mir aber vorstellen dass manche der einzeldateien grosser waren? manche benutzer snd da sehr grosszugig, so wurde zB die einfache grafik Trafigura company logo.svg mit fast 20 MB gemacht.

ich sehe es an als gute ubung und schone demonstration. direkten nutzen hat es eher wenig. Ich sehe andere dinge, die mehr als korrekturen und aufraumarbeiten zu bezeichnen sind, als wesenlich nutzbringender an. mit deinen Inkscape-kenntnissen und deinen fahigkeiten zu sinnvollen dateigrossen kannst du viel zu bereinigungen beitragen, und vielleicht auch anderen die es notig haben auf die sprunge helfen. einen schonen sonntag! -- sarang♥사랑 06:56, 14 November 2021 (UTC):This section was archived on a request by: -- sarang♥사랑 08:47, 25 December 2021 (UTC)

File:Bandera de las Malvinas.svg

File:Bandera de las Malvinas.svg has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry. If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues. Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

GPinkerton (talk) 13:27, 14 November 2021 (UTC):This section was archived on a request by: -- sarang♥사랑 08:47, 25 December 2021 (UTC)

Category:SVG coat of arms elements - fish

hi, ich habe gerade gesehen dass du dieser kategorie kürzlich text hinzugefügt hast - ich konnte nun meine files uploaden - was kannst du zum naming der files sagen? --Mrmw (talk) 18:41, 28 November 2021 (UTC)

hast du reingeschaut? --Mrmw (talk) 16:11, 30 November 2021 (UTC)

ich finde dass diese kategorie eine sehr gute ubersicht ist, da sie alle c-elemente zeigt. zugleich zeigt sie die vielen konkurrierenden namenssysteme - es ist leider so dass eben jeder aus einer anderen richtung kommt, sich zT an englischem oder franzosischem wappenzeichnen orientiert und letztlich jeder sein ding macht; ich selbst wurde ein einheitliches system bevorzugen, aber es ist nun mal so gewachsen und jetzt nachtraglich alles uber eine kante zu brechen ist noch weniger sinnvoll. dein system mit 'heraldry' + lfd nr ist ja ein gutes und zukunftsicheres system; auch wenn es nur eines von vielen ist. -- sarang♥사랑 16:56, 30 November 2021 (UTC):This section was archived on a request by: -- sarang♥사랑 08:47, 25 December 2021 (UTC)

Interwikis vs links

Please try to avoid replacing wikilinks with invalid interwikis or breaking pages with markup. Thanks. Magog the Ogre (talk) (contribs) 19:33, 3 December 2021 (UTC) :This section was archived on a request by: -- sarang♥사랑 08:47, 25 December 2021 (UTC)

igen

hi, ich glaube das script macht aus [[:c:special:permalink/612459865#Proposed_flag_of_Cyprus_(1959)]] das hier:
{{W|c:special:permalink/612459865#Proposed_flag_of_Cyprus_(1959)||}}
und das ist nicht in meinem sinne --Mrmw (talk) 14:41, 8 December 2021 (UTC)

hallo Mrmw wenn der link statt [[:c: mit [[c: beginnt unterbleibt das verbiegen. wird denn dieser link automatisch erzeugt? fur alle falle habe ich es nun verhindert, dass das umgesetzt wird -- sarang♥사랑 07:57, 9 December 2021 (UTC)

ich verstehe deine frage nicht

[[:c:special:permalink/612459865#Proposed_flag_of_Cyprus_(1959)]] schreibe ich selbst um auf einen request zu zeigen - der rest kommt vom script --Mrmw (talk) 08:43, 9 December 2021 (UTC)

ein​ [[c:special:permalink/612459865#Proposed_flag_of_Cyprus_(1959)]] (ohne das erste ":") ist die korrekte verlinkung; es geht naturlich immer auch anders, aber das hat das script in die irre gefuhrt. das script muss auch mit solchen angaben zurecht kommen, deshalb entfernt das script nun das erste ":" ehe es weitermacht.

meine frage: irgendwie kann man sich auch einen link auf einen anderungsedit geben lassen, aber ich habe noch nicht herausgefunden wie das geht. weisst du das? -- sarang♥사랑 09:08, 9 December 2021 (UTC)

ich baue mir den link immer selbst zusammen: also [[c:special:permalink/ gefolgt von der id und dem anker - dazu wähle ich im linken menü Permanenter Link bzw. Permalink (Version) in wiki oder ich rufe die entsprechende version in der änderungshistorie auf - dann steht die id in der url, die ich dann kopiere --Mrmw (talk) 13:13, 9 December 2021 (UTC)

danke, das mit dem permalink habe ich noch nicht gewusst... -- sarang♥사랑 13:21, 9 December 2021 (UTC)

zufällig entdeckt: de:Benutzer:PerfektesChaos/js/pageLinkHelper#diff --Mrmw (talk) 15:13, 13 December 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 08:47, 25 December 2021 (UTC)

File:CovidVaccCert.jpg

File:CovidVaccCert.jpg has been marked for speedy deletion. (Reason: real original vaccination certificate: risk of fraud) Why not upload a picture of a plant, animal, or anything else which fits into our scope. You can contribute any media type you want, including but not limited to images, videos, music, and 3D models. Start uploading now! If you don't have anything to upload at the moment, why not take a look at our best images or best videos, sounds and 3D models. If you have any doubts/questions don't hesitate to visit our help desk.

User who nominated the file for deletion (Nominator) : KurtR.

I'm a computer program; please don't ask me questions but ask the user who nominated your file(s) for deletion or at our Help Desk. //Deletion Notification Bot (talk) 01:25, 15 December 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 08:47, 25 December 2021 (UTC)

image-map symbol-indicator

hi, sehe ich es richtig, dass der kleine symbolindikator (blaues 'i') in einer unteren ecke des images ein png.file (File:Desc-20.png) ist (z.b. Grönland infobox ganz unten)? und ist es richtig dass es sich dabei um eine wiki-media-erweiterung handelt (mw:Extension:ImageMap)? kann man sich den quellcode ansehen? ich würde den entwicklern dort vorschlagen das svg-file (File:Desc-i.svg) zu verwenden - ob sie interessiert sind, da es 13 mal größer ist, sei mal dahingestellt - danke und gruß --Mrmw (talk) 17:36, 17 December 2021 (UTC)

Ja, generell ist die verwendung von SVG angestrebt. in diesem fall ist Desc-20.png vergleichsweise nur 1171 byte gross; Desc-i.svg hat hingegen 13245 bytes weil es jede menge inkscape-müll enthält - imsbesondere aufwendige gradienten. mit omg kann es ohne weiteren eingriff sofort auf 3473 bytes reduziert werden. wenn zB die überflüssigen (in der verwendeten größe eigentlich nicht sichtbaren) gradienten ersetzt werden wird es dann deutlich kleiner als das PNG.

jedes SVG wird serverseitig in ein PNG konvertiert und erst dann weiterverwendet. die server-belastung ist gering, aber der vorteil eines SVG ist in dieem fall auch nicht so bedeutend, dass sich da grosser einsatz lohnen würde. ich rechne also nicht mit toller begeisterung der wikimedia-leute. aber wenn es dir am herzen liegt kann ich weitere reduzierung des SVG versuchen um den vorschlag plausibel zu machen -- sarang♥사랑 07:23, 18 December 2021 (UTC)

 

Hier ist das PNG verwendet (1171)

 

besser das SVG, reduziert von 13245 zu 3102 bytes

 

Vereinfachtes SVG (ohne gradient), 972 bytes

Die unterschiede sind marginal - kaum sichtbar! -- sarang♥사랑 11:25, 18 December 2021 (UTC)

ja da hast du schon recht, im grunde ist mir das bewusst, aber ich finde wenn sie gleich groß sind könnte man schon die svg-version benutzen - du hast meine frage ob das png verwendet wird nur implizit beantwortet - und wer, wo, also an welcher stelle (mw-extension?) hast du nicht beantwortet - danke und gruß --Mrmw (talk) 07:08, 19 December 2021 (UTC)

bez. mw-extension konnte ich nichts herausfinden und auch nichts posten, das ist ein eigener komplex und kein wiki wie wir es kennen. deshalb kann ich da auch nichts anregen, und meine neigung mich in mw-extension einzuarbeiten ist begrenzt. -- sarang♥사랑 07:21, 19 December 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 08:47, 25 December 2021 (UTC)

haarlinie

hi, bei geradlinigen flächen die aneinanderliegen und oder überlappen sind manchmal haarlinien sichtbar obwohl sie eigtl. deckungsgleich sein sollen, d.h. das weisse objekt deckt das darunterliegende farbige nicht 100%ig ab, in inkscape ist dann u.u. abhängig vom zoomlevel diese haarlinie sichtbar - ist das auch in wiki ein thema? denn es gibt schon möglichkeiten diesen effekt sicher zu umzugehen, indem man die flächen geometrisch verkleinert, dazu sind weitere knoten erforderlich und es ist umständlicher - weisst du wovon ich spreche? --Mrmw (talk) 14:40, 23 December 2021 (UTC)

das problem ist mir bekannt, es gibt dazu beispiele, wie Hairline crack.svg.

vor kurzem sah ich dass Аргенций eine version von Flag of Kuban People's Republic.svg mit 411 bytes, die genau diesen Fehler hatte, durch eine hochkomplizierte version mit 1994 bytes ersetzt hat, statt es einfach (mein beispiel hat 217 byyes, es ginge noch sparsamer) zu machen. beides sind naturlich extrem einfache beispiele; du hast ja kein konkretes beispiel genannt, ist aber auch nicht notwendig -- sarang♥사랑 16:12, 23 December 2021 (UTC)

an dem haarline-crack-svg sehe ich dass es das problem gibt, aber es beschreibt nicht exakt das was ich meine

hier zb: File:Flag of Eidgenössische Sammlung.svg - stell dir vor es ist invertiert, der grund ist rot und das weisse kreuz darüber, dann erscheint u.u. an den seitenrändern am kreuz eine rote haarlinie, und manchmal will ich es dann so machen wegen layoutgründen dass der grund rot ist, prinzipiell tritt das auch bei anderen farben auf die sich unterscheiden, gelb grün z.b.

eine lösung ist dann, den roten grund zu modifizieren, also im bereich des kreuzes zum rand hin ein dreieck einzuschneiden, damit er dort nicht bis zum rand ragt - ist mein problem verständlich?

bei der anderen flagge von dir könnte z.b sein dass der blaue grund als haarlinie links und rechts der anderen beiden fahrben zu sehen ist, wären diese heller z.b. gelb oder hellgrau

oder gibt es das haarlinien problem nur bei angrenzenden flächen nicht aber bei überdeckenden? --Mrmw (talk) 16:59, 23 December 2021 (UTC)

NACHTRAG: File:Presqu'île de Rhuys traditional district flag.svg

hier ist zu sehen was ich meine - der grund blau, darauf gelbe flächen über blau, die bis an den rand reichen - ich betreibe da verhältnismäßig großen aufwand und stutze das blau unter dem gelb vom rand weg - um zu verhindern, dass die gelben flächen am rand außen eine blaue haarlinie haben - ich denke da auch an ungünstige situationen, weiterverwendung, anderer renderer ... ist das zuviel deiner meinung? --Mrmw (talk) 19:05, 23 December 2021 (UTC)

es können zwei völlig unterschiedliche phänomene auftreten: bei bestimmten zoomingverhältnissen können koordinaten rundungsfehler aufweisen so dass eigentlich aneinandergrenzende flächen eine zwischenspalt bekommen; das lässt sich an diesen beispielen zeigen.

aber auch wenn flächen korrekt aneinandergrenzen, oder eine überdeckung vorliegt, kann die optische täuschung einer überstrahlung stattfinden, sodass ein rand andersfarbig wirkt - meist ist es eine art verlauf. -- sarang♥사랑 08:01, 24 December 2021 (UTC)

Presqu'île de Rhuys traditional district flag.svg ist mit koordinaten gezeichnet die auf zehntausendstel pixel angegeben sind, dazu kommen noch transformationen; natürlich kann es da zu rundungs"fehlern" kommen die sichtbare spalte ergeben. die endgültige zeichnung, das PNG, kann nur auf pixelgenauigkeit basieren, und die erforderliche ab- oder aufrundung auf ein ganzes pixel kann so einen ungewollten spalt erzeugen. -- sarang♥사랑 08:11, 24 December 2021 (UTC)

danke für die antwort - ich habe kein problem damit die flächen die sich eigentlich überdecken sollen entsprechend auszusparen an den rändern, nur muss ich dann einen kompromiss eingehen zwischen dem vermeiden von anzeige-fehlern und einfachen svgs

bei den einfachen länderflaggen wird das auch nicht so gemacht, dass flächen ausgespart werden - weil dort rundungsfehler unwahrscheinlich sind? kann ich mir das aussparen sparen wenn die koordinaten einstellig sind? also wenn alle x- bzw. y-werte die selbe einstellige koordinaten haben? Mrmw (talk) 09:58, 24 December 2021 (UTC)

bei entsprechendem zoom kann es vorkommen dass auch ganze pixel so dividiert werden müssen dass sich dieser fehler ergibt - ist aber viel seltener; und kann vermieden werden. "einfache" länderflaggen (wenn sie nur aus streifen bestehen, auch kompliziertere wie Tibetan buddhist flag.svg) mache ich immer so dass die farben einander voll überdecken, es kann also nie ein zwischenraum entstehen.

Presqu'île de Rhuys traditional district flag.svg hätte ich so gezeichnet, dass zuerst die gesamte fläche blau ist mit dem fur skin als fill pattern, dann nochmals blau als dreieck mit darin den gelben streifen, und das weisse dreieck mit dem roten symbol; das ganze moglichst ohne jede transformation. ich glaube, es wäre recht einfach geworden. soll ich das mal machen? -- sarang♥사랑 11:02, 24 December 2021 (UTC)

@Mrmw: nun hab ich testhalber eine version Drapeau traditionnel du district presqu'île de Rhuys.svg erzeugt; nicht so schön wie deine variante, aber sehr vereinfacht und ausschliesslich mit geradzahligen koordinaten. alle flächen überdecken einander, es kann also keine hairline cracks geben. übrigens, ich hab nun doch einfach geklont statt mit fill pattern zu machen. -- sarang♥사랑 16:33, 24 December 2021 (UTC)

ja sehe ich, wobei es da einfach unterschiedliche philosophien gibt - ich z.b. ärgere mich immer, wenn ich svg, wie z.b. eine flagge weiterverwenden will, und dann pfade über den rand hinausragen - will man aber einfache svgs erzeugen ist deine variante vorzuziehen

die unterhaltung war aber hilfreich für mich, weil ich nun weiss, dass haarlinien nicht auftreten, wenn die koordinaten ganzzahlig sind, und das ist am seitenrand zu bewerkstelligen n der regel - danke und gruß Mrmw (talk) 00:01, 25 December 2021 (UTC)

​die datei ist ohne einschränkung überall in wiki mit dem librsvg verwendbar; wenn es probleme in anderen systemen geben sollte kann ein clipping path eingefügt werden.

wie gerade die datei Hairline crack.svg zeigt liegt es nicht daran ob die koordinaten ganzzahlig sind, sondern ob spezielle zoomings rundungsfehler verursachen, die zu solchem spalt führen. -- sarang♥사랑 08:47, 25 December 2021 (UTC) :This section was archived on a request by: -- sarang♥사랑 16:51, 28 December 2021 (UTC)

FanNihongo's deletion request

Hello Sarang, FanNihongo is a young contributor and is still clumsy. Commons is a complex beast by 2021. S.He seems willing to help at a calm pace but needs some mentoring indeed, on local community rules and process, from both Commons and SOP. I help as I can when I see some needs. Business as usual. ^__^ Yug (talk) 19:52, 28 December 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. FanNihongo (talk) 23:11, 14 January 2022 (UTC)

FanNihongo (talk) 23:11, 14 January 2022 (UTC)

File:Calvin-cycle4.svg

Thanks for uploading a new version. Glrx (talk) 19:44, 30 November 2021 (UTC)

@Glrx: you are welcome; it is a pity that some people increase the size of an SVG multiple times just for a small correction or change of a color.

I had been thinking to make also a multilingual version, as with Circle Area.svg. There are about 20 single-language Calvin cycles, looking sometimes very different. But there seems not to be a consent whether to generate large numbers of single — or one multilanguage SVG file? -- sarang♥사랑 06:31, 1 December 2021 (UTC)

There are many complicated considerations here.

Yes, I wish small corrections would not bloat files. I wish that all files and all changes are rational. However, Commons is a community of volunteers with varying skill levels and different viewpoints. The error in the Calvin-cycle4 was 2 extra hydrogens; deleting 2 lines and 2 circles would fix the problem. I'll guess that was the original plan. When editor Adenosine made those changes, he probably also addressed some unexpected font displays (font-family="'Helvetica'" and font-family="'Helvetica-Bold'"; Adobe Illustrator does not set the font-weight="bold" attribute). Ultimately, the editor "solved" the display issue by converting the text to curves. Many editors have gone that route. I cannot blame them. The notion of available fonts on Commons is complicated, and Adobe Illustrator has a vested interest in making it easy to use Adobe fonts and difficult to use other fonts. Editors may not know how to compose text so it displays well on several agents.

So it is a bit of a balancing act. The errors in the image were removed, but much of the text was lost.

Commons is a multilingual project, and I want multilingual images available. There have been many important illustrations such as those that addressed the West African Ebola outbreak and address the current Covid pandemic. One editor can make an illustration, and other editors can translate that illustration to other languages.

The simple method of translation copies the file, translates the text, and then uploads as a new file. Someone who can use a graphics editor can make the translation. The drawback is the different copies of the file do not track. If the graphics portion of the file is corrected or improved, then those changes do not automatically propagate to the other copies.

The SVG 1.0 standard included the switch element, and some wiki developers enabled its use on Commons. That effort solves the copy problem, but it brings in other problems. The solution is imperfect because Commons and librsvg have bugs. For example, systemLanguage="zh-Hans" and systemLangage="zh-Hant" are treaded identically. In addition, many graphics editors may not be suitable to edit such files. What if LadyofHats draws a fabulous diagram using Adobe Illustrator. Then someone comes along and adds switch elements to the diagram. Will LadyofHats still be able to edit her own illustration?

Using switch can also have extraordinary costs. There's an SVG map of the United States that has about 100 languages. IIRC, the basic map is 100 kB, but the translations add another 300 kB (50 states × 100 languages × 100 bytes). So switch translations can work, but they can also be cumbersome.

Very simple switch-translated files on Commons have the benefit of crowd sourcing. SVG Translate is simplistic and has its own set of problems, but it has enabled the translation of many diagrams. See, for example, File:Symptoms of coronavirus disease 2019 2.0.svg.

There are more complicated switch-translated SVG files. Some include graphics elements within the clauses. Some SVG files do translation planes rather than a switch for each "translation unit".

Any switch-translated SVG file may be less useful outside of the WMF servers. It may be more difficult for others to use (such as within a graphics editor), but that is not a problem to which I give much weight. Most SVG files will be displayed in a browser, and modern browsers have reasonable support for the switch element.

A switch translated file has undergone internationalization (i18n). Another alternative is localization (l10n). When librsvg produces a PNG file, then it produces a localized PNG.

Commons does not have a facility for generating localized SVG files. A commercial website often uses the localization approach. There would be a pattern SVG file that can be edited by any graphics editor (a benefit over switch). Other XML or text files contain the translations: they map the pattern SVG file into a localized SVG file. The advantages are the localized SVG files are not bloated by extraneous translations and changes to the pattern SVG file propagate to the localized copies. Commercial websites have the advantage of imposing reasonable standards on their SVG files. The commercial website files can be small. Commons does not impose such constraints.

Yes, I do not see consensus for how to handle translations on Commons. Using several separately translated copies certainly works, but it has copy limitations. Using switch translated SVG also works, but it has other limitations. Neither is perfect.

Consequently, I tend to leave files as they are, but I have a bias toward switch translations because it seems to be the best option on Commons. If I created the file, I will include switch. If the original author has not edited the file in a couple years (and is therefore unlikely to edit it again), then I may add switch translations. The Calvin-cycle4 file has not been edited in a long time, so it could be a candidate. If the original is an Inkscape file, then I'm more willing to add switch translations; if the original is an Adobe Illustrator file, then I'm more reluctant. The Calvin-cycle4 file is an Adobe Illustrator file. If the file will be updated with newer data, then the choice is more involved; it involves the skill of those who will update the data. I also consider translation potential. The Calvin-cycle4 file is used on wikis in 30 different languages. The flip side is many of the terms being translated are technical chemical names such as "3-phosphoglycerate" rather than more general terms such as "carbon fixation". Overall, I'd have no problem with somebody adding switch translations to the file.

I have collapsed several illustrations into a single switch translation. When I've done that, I've left all the files in place, but I changed most uses of the other files to point to the switch-translated file. That is, I have not asked for the other files to be deleted. (I have asked that a file be deleted when it has been a recent derivative of a file that is already switch-translated that should have been made by adding more clauses.)

There is an implicit but weak stamp of approval for switch translations due to SVG Translate. I have left some SVG files alone, but other editors have converted them with SVG Translate.

Glrx (talk) 21:02, 1 December 2021 (UTC)

@Glrx: It might be worth to put your considerations to a place where interested people can find it, e.g. to Category talk:SVG simplification by text switch#Multilingual files. When you are not strictly against it, I will move or copy it, and you can maintain it there.

I have been looking at Symptoms of coronavirus disease 2019 2.0.svg; same people used wrong tags (badSVG instead of required raster embedding), and the frequent use of SVG Translate created a not-so-fine code. I used my script to maintain the code, and tried a version Symptoms of coronavirus disease 2019 2.1.svg (without all the hundreds of superfluous IDs, causing many W3C errors at 2.0). But I think it will not be worth the effort to add all the other languages from the later versions, because soon somebody will use again SVG Translate... This tool is a fine help for people not able to maintain text otherwise, but it is too buggy and it creates a lot of chunk code.

I do not see any need to make all things better, and many users do not like their files tagged or changed. I rather think of preparing some comments, advices and hints for interested people who want to increase their work and create better files. -- sarang♥사랑 15:46, 2 December 2021 (UTC) :This section was archived on a request by: -- sarang♥사랑 09:02, 18 January 2022 (UTC)

glück

hi, ich frag mal auf gut glück, vlt weisst du bescheid und kannst mich aufklären - ich frage mich wie der link zu dateien im wikitext nach commons funktioniert - genauer wie er aufgelöst wird, genauer, wie mit leerzeichen verfahren wird - sehr viele bilder sind im wikitext mit unterstrichen anstatt mit leerzeichen verlinkt - ob es andersrum auch funktioniert weiss ich ehrlich gesagt gar nicht, ich weiss nicht mal ob es auf commons files mit unterstrichen gibt - aber ieine regelung muss es hierfür geben, weil es nach meinem verständnis unterschiedliche zeichen sind - danke und gruß --Mrmw (talk) 20:13, 27 December 2021 (UTC)

@Mrmw:

URLs may not have ordinary spaces; a space signals the end of the URL. Embedded spaces in a URL may be represented with %20. You will see many URLs with % followed by two hexadecimal digits. That practice is known as URL encoding. With just URL encoding, one can reach a Commons page with embedded spaces:

• https://commons.wikimedia.org/wiki/File:First%20Ionization%20Energy.svg

That works because the URL decode of File:First%20Ionization%20Energy.svg produces File:First Ionization Energy.svg.

MediaWiki has adopted _ as a represention of a space. When MediaWiki processes a reference to a wiki page, it will replace any spaces with underscores. Consequently, these wiki texts are equivalent:

• File:First Ionization Energy.svg
• File:First_Ionization Energy.svg
• File:First Ionization_Energy.svg
• File:First_Ionization_Energy.svg
• File:First Ionization Energy.svg: MediaWiki will direct all of them to a URL that uses underscores.

Ordinary URLs do not treat underscores as spaces. It is only MediaWiki (when it resolves links) that treats underscores and spaces as the same.

The appropriate practice is to use underscores (rather than %20) in wikitext URLs ([]) and use spaces in conventional wikitext links ([[]]).

Glrx (talk) 21:02, 27 December 2021 (UTC)

​und die schreibweise [[:File:First_Ionization_Energy.svg|First Ionization Energy.svg]] wie sie sehr oft als standard zu beobachten ist (bei allen namespaces, nicht nur file) ist alternativ machbar mit der vereinfachten schreibweise {{F|First_Ionization Energy.svg}}, wobei die vorlage alle unterstriche ersetzt um die anzeige von File:First_Ionization_Energy.svg zu vermeiden. ubrigens, das geschieht mit PAGENAME, das alle understrokes zu spaces macht, [[:File:{{PAGENAME:First_Ionization_Energy.svg}}]] wird zu File:First Ionization Energy.svg, oder {{PAGENAME:1_2_3}} zu 1 2 3.

wie bei den anderen namespaces, kann dabei der namespace selbst ausgegeben oder unterdruckt werden. siehe C, F, G, M, T, U, W etc. -- sarang♥사랑 07:31, 28 december 2021 (UTC) :This section was archived on a request by: -- sarang♥사랑 09:02, 18 January 2022 (UTC)

Request

Greetings. Would you be able to do what you did with File:Hastighetsbegränsning upphör.svg, with File:UK traffic sign 671.svg, but in milimetres instead of pixels? I tried doing it myself but can't seem to quite figure it out. The schematic can be downloaded from the British Government. Basically what I was attempting to do is create a black square that is 606mm, with a white circle overtop that is 600mm in diameter and positioned in the centre of the square (3mm upward and 3mm to the right), then the black slash overtop that is 160mm wide. Finally the clip-path circle would be 604mm in diameter and also positioned in the centre (1mm upward and 1mm to the right). This would create a 1mm blank "safe space" around a black circle, which itself provides a 2mm thin black border around the white circle. I hope I'm not being too technical, and that you are able to assist. Fry1989 ^eh? 17:37, 29 December 2021 (UTC)

​No, because of two reasons:

1. Using the unit mm for SVG is much troublesome, it leads to complicated decimal fractions when the necessary conversion to pixel occurs. I will alays only draw in px.
2. I saw that you made traffic signs 606×606 mm, which will be 2,147×2,147 px – much too large for easy treating the file. The present size 342×342 px is much better; if there exists the wish to make a new drawing 606×606 px it will be o.k.

I can draw it with all the measurement you gave but in px instead of mm. It will not make any problem to display an older mm version beneath a new px version because all relations are the same. But using another unit (en, em, in, mm, pt or whatever) instead of px is nonsense, seen by me -- sarang♥사랑 18:03, 29 December 2021 (UTC)

(talk page stalker)I'm not sure how to handle plans that are drawn to scale. (German: Ich weiß nicht wie man massstäbliche Pläne auf Commons behandeln soll.)

If it is a PDF I think it should be created in scale. SVGs are ment to be scaleable, so something that is in 1:1 or 1:10 scale should imho not be zoomed stepless as used on Commons.

If it is a plan, such as File:Stahl_Details_JoKa.svg it should use a scale in mm (589.8mm x 594.1mm) as the PDF, and not fitted to reasonable sizes (i.e. not as done for this svg).

I don't know any decision about svgs in scale. Imho both arguments are valid, not sure which I would prefer for traffic signs.

 — Johannes Kalliauer - Talk | Contributions 22:29, 29 December 2021 (UTC)

Hallo JoKalliauer, it is an undeniable fact that images (e.g. SVG) with a height of about 600px, ±100, can be viewed well without zooming. Fry1989 changed a lot of drawings (e.g. Cyprus road sign mandatory go streight.svg 600 × 600 to 2,147 × 2,147, IE road sign RUS-021.svg 724 × 722 to 2,133 × 2,133, UK traffic sign 811 (Gibraltar).svg 680 × 775 to 2,505 × 2,859) from a fine size to a much too large size — I have no idea why. Of course an SVG can be displayed in any scale, but it is boring when it cannot be seen on its page.

I do not intend to correct it back when he likes it that way, but also I won't support such nonsense. You may think about whether his changes (no alteration in appearance, just enlarging by a factor ~4) belong to the wanted contributions ? In my understanding such re_uploads are clearly undesired and should be discussed with the user. -- sarang♥사랑 07:51, 30 December 2021 (UTC)

Hi Fry1989: this is exactly what you want:

Traffic sign code

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" width="606" height="606" stroke="#000">
<clipPath id="c"><circle cx="303" cy="303" r="302"/></clipPath>
<circle fill="#FFF" stroke-width="2" cx="303" cy="303" r="301"/>
<path clip-path="url(#c)" stroke-width="160" d="M0,606 606,0"/>
</svg>

(301 bytes)

whith all your mm relations in px:

• white circle d=600
• bordered d=604 (gives border width 2)
• surrounding square 606×606 (gives save space 1)
• upward black stroke 160 width

Will you upload it, or shall I (when you tell me the name)? Or do you not like it? -- sarang♥사랑 07:01, 30 December 2021 (UTC)

@JoKalliauer: Sarang; I will try to explain myself. There are several reasons why I am altering these images. The first reason is accuracy. It doesn't matter whether these images are extracted from a PDF where they are already formatted in SVG, or converted from DWG or EPS or some other format, in my experience the images provided by governments almost always have inaccuracies in them. For example, File:UK traffic sign 617.svg is supposed to have a red circle with a diameter of 600 and the white circle 480, but if you download and convert the EPS version and expand it to 600, the white circle is 480.528. So simply uploading the government files is not sufficient if one cares about accuracy, the images have to be re-drawn.

The second reason is that even if the images were in their correct measurements, there are other problems. For example, File:UK traffic sign 811.svg previously had a blue external border, which could be confused as part of the sign itself. Compare File:Brasil R-1.svg which does have a red external border with a thin internal white outline, but File:Nepal road sign A1.svg only has an external white border, so for that reason it only has a thin black outline around the white area to provide contrast between the image and the transparent space behind it. That is why the blue border on File:UK traffic sign 811.svg should be changed to black. The colours are also incorrect. The British Government (and some other governments such as Sweden) provide an official colour palette for their signs, and that image did not match the colour palette.

Lastly, I do understand that SVG is a scalable format. However, I have a preference of using the native measurements of the images which is in milimetres. I can not provide any reason why mm is better than px, it is only how I prefer to do it. I also have very little experience with using a text editor and anything beyond simple circles and squares. Inkscape is my preferred tool because it is easier for me to understand. It does have the drawback of creating images with a larger file size, but I am trying my best to reduce the file sizes as best I can within Inkscape. I apologise that my preference for milimetres and using Inkscape creates results that you both find offensive.

Sarang, I am most thankful for your assistance, despite your hesitantcy to provide it. I will be able to upload the image myself using the code that you have provided. If it is your preference, I will avoid asking for your help in the future. Fry1989 ^eh? 16:12, 30 December 2021 (UTC)

@Fry1989: I try to clarify your intention, with Sarang in another discussion, to use the native measurements of SVGs. I think till now I was unable to explain the use of Plans that are dawn in scale, I tried it with more obvious examples as File:Stahl_Details_JoKa.svg, or File:A_size_illustration.svg.

If there is a visible change (color,higher Precission,...) it is desired to reupload SVGs. However your "mistake" is to write in "File changes:" thinks like "Minor updates.", "Reconstruct", "Overhaul", but not what you changed, like: "Overhaul: corrected blue colour". The Problem is, that the first thing people see is that you changed the dimensions, and changing only the dimensions might violate Help:SVG_guidelines#Optimizing_SVGs_that_have_already_been_uploaded (which I wrote).

Sarang prefers to have a SVG that fits on their screen, and a 600mm x 600mm Image does not fit on most screens.

 — Johannes Kalliauer - Talk | Contributions 16:34, 30 December 2021 (UTC)

@Fry1989 and JoKalliauer:

I will address Help talk:SVG guidelines on that page later today.

All of us agree that an RGB color error may be corrected.

I question whether small errors need correction. That 480.580 should be 480 is 0.12 percent error. For traffic signs, such an error would be acceptable. (I've been unhappy when a PCB designer made a 0.25 mm error in a 100 mm length.)

I see a distinction between computer-aided-design (CAD) formats and SVG. CAD programs have clear distinctions between model space (the actual dimensions), paper space (the scale at which the model is drawn), and viewports. SVG does not make such distinctions (if we ignore CSS transforming 3D objects in SVG). In addition, although SVG is scalable, its scaling is differs from CAD scalling. A centerline in a CAD program is always drawn on paper at a fixed width and sensible dash pattern even when zooming in. Zooming in on a centerline in SVG magnifies the centerline; it becomes fat and the dash pattern is no longer sensible. I do not think SVG should be considered a CAD format.

Most SVG files are not intended to display at actual size. Most images are intended to be inserted into articles at a reasonable size for the article. Most images are intended to be rendered in paper space and not model space.

There may be images that should be displayed at a specific scale. For example, an image of a ruler may want to be displayed at a 1:1 scale. How that display is achieved is difficult because the img and object containers have different semantics. Putting width="100mm" in many instances does not mean display this SVG image at that scale. The simple view is to put the accurate scaling of an SVG image on the user. The user must choose a container of the correct size to get an accurate scaling.

The larger issue is whether there is a sensible size for SVG files. Is a 20 px image too small or a a 2400 px image too large? A width of 600 pixels usually gives a reasonable display. I do not see a good answer to the sensible size question. My default position is the SVG element should set viewBox and not set width or height. That makes the chosen scaling of the SVG file irrelevant. The image will always fit in the container. My default position has problems; zooming the browser window does not zoom the image. Consequently, I do not see a good answer. For Commons, it is a good idea to have a width in the 300 to 1200 px range. That will give a reasonable display, but I do not see a mandate. I also think it unreasonable to arbitrarily change the width of an existing SVG.

Glrx (talk) 19:56, 30 December 2021 (UTC)

@Glrx: agree, however some CAD-formats are saved as svg on commons, since *.dwg or *.dxf is not allowed on commons, and the jpg-tumbails of *.pdf sometimes look terible.

What should be done with CAD-Plans saved as svg on commons? imho they should have their native size in mm.

Are trafic-signs are kind of CAD-images, see e.g. https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/542925/traffic-sign-drawing-schedule-10-part-02-item-02-p671.pdf . I think User:Fry1989 argument is valid, because it has advantages, also it does imho not justify a reupload.

The preview on commons is limited to 800px x 600px, therefore everything larger is imho irrelevant (as long as you don't open the native svg).

Having only a viewBox takes a width of 512px, if the height is below 600px, otherwise it takes a width that the height does not exeed 600px (therefore the height is often 599px).

A widht of 0px imho don't get rendered.

The width imho get rounded to the next integer, and the height is imho fitted acordingly to the next integer.

The size of the native svg is imho quite irrelevant (iff above 800px x 600px), because the preview does not change. @Glrx: Do you agree on that?

So we are talking if the native svg-size should be (a) in scale 1:1 (viewBox with height/widht in mm) or (b) so that it fits the screen (viewBox without any height/widht). That is imho too unimportant to prescribe the one or the other, just don't do a reupload only changing the native SVG-size.

 — Johannes Kalliauer - Talk | Contributions 20:43, 30 December 2021 (UTC)

@JoKalliauer: You've covered a lot of ground. I have no problem using logical pixels as if they are units. If a sign should be 1200 mm by 600 mm, then I would use 1200 px by 600 px. Then I'd use a viewBox of (0, 0, 1200, 600). If somebody wants a life-size image, then he can put the SVG in a container that is 1200 mm wide. All the numbers in the SVG file look reasonable, and the result is reasonable.

I'm not a fan of life-size objects. Most I-beams need to be scaled to fit on a sheet of paper. If I draw an image of E. coli, it will just be a dot on the page. I may want to draw some images in meters, some in millimeters, some in microns, and others in nanometers. I expect all of those objects to go through a viewport transformation so they fit reasonably on my computer screen.

If I start using SVG dimensions such as mm, then I risk getting into trouble with strange conversions. I do not want my browser trying to show an entire building at 1:1 scale. Even on a 65-inch screen, such an image is unreasonable.

In addition, there are other problems with using real/model space units. For example, Inkscape uses mm for most dimensions and points for fonts. It also has the notion of 96 CSS pixels per inch. Someone draws a nice image in Inkscape using multiples of 1 mm, but Inkscape outputs an SVG file that converts those multiples into seemingly random numbers. I'd rather see a rational scale of 1 or 10 pixels per mm.

I'm not against a lot of unusual numbers in an SVG file, but I'm not in favor of them either. I do not see an obvious right thing to do. The choices have benefits and drawbacks.

Units within SVG have a strange fiction. Using SVG, I can specify a length of 1 mm, but that does not mean the drawn length will be 1 mm. That 1 mm is converted to a fixed number of logical pixels.

I disagree about the native size being irrelevant. First, that an image on Commons displays well if it is over 800 pixels wide is only a feature of Commons; it is not true of the rest of the world. If the image is under 4 pixels, it probably does not display well on Commons.

I also disagree with your dichotomy of display at 1:1 or at viewBox without width or height. A 1:1 image of a corona virus (approximately 25 nm) would be silly. A viewBox display of a ruler would also be silly. The goal is a reasonable display of the image. Unfortunately, an image may be displayed in several different environments, so there is no clear answer.

We agree that reuploads to merely change the size are probably unreasonable.

Glrx (talk) 22:51, 30 December 2021 (UTC)

@Glrx: so you are saying CAD uses vector-effect="non-scaling-stroke" and SVG1.1 not? (But Inkscape&SVG2.0 supports vector-effect mozilla.org, selfhtml.org).  — Johannes Kalliauer - Talk | Contributions 20:51, 30 December 2021 (UTC)

@JoKalliauer: Yes, but I do not want to wander into a false dichotomy. As I said above, CAD files support more than non-scaling lines. SVG is primarily an output format that describes how to make marks on a screen or a sheet of paper. It does not support associative dimensions. SVG is also a troubled specification. Features get added because somebody thought it was a good idea. Many additions are poorly thought out. Sometime later, features get removed (e.g., glyph and Path DOM). SVG can have a lot of stuff in it, but I do not see it as a good CAD format. But I get surprised from time to time. I haven't studied it, but our laser cutter workflow sounds horrible. Use a CAD program to do the 3D design. Build an appropriate 1:1 view of each surface. Output a DXF file. Read the DXF file into Adobe Illustrator. Adjust the line widths and colors to those the laser cutter wants. Output the result as a PDF file. Print the PDF file using the laser cutter printer driver. The world should be simpler than that, but the guys who are responsible believe that the laser cutter must be fed a PDF. File formats and their usage can be twisted. Glrx (talk) 22:51, 30 December 2021 (UTC)

@Glrx: @JoKalliauer: If there is a genuine benefit to setting the images to px instead of mm as has been suggested, I would be prepared to revert my work back to px, with the scalable nature meaning 1 pixel is equivalent to 1 milimetre. However, my main tool would still be Inkscape where complex shapes are involved, and so Sarang and JoKalliauer will remain dissatisfied with the file size. For that I can only apologise. I must also disagree on the accuracy point. Whilst it may be considered minimal by some, why shouldn't we make the images as accurate as possible when we have both the ability and users who are willing to invest their time? The other points raised about the SVG format and CAD, I have no knowledge or experience in, so I will leave that to those that do. Fry1989 ^eh? 00:35, 31 December 2021 (UTC)

Too large to see

@Fry1989: On one side I am sorry that such a long discussion developed about this minor "problem", using essential time of two specialists; on the other side I see kind of consent for all four of us:

• px might in general be better for unit, as long as not special needs require another one
• a size neither too small nor too large to view might be preferred
• reupload just for changing units of an exsting image is not desired

but these are not rules - only onsiderations. Fry1989, when you have no experience in uploading SVG from text editor, and it is not yet done, shall I upload the requested traffic sign code? Please tell me a file name when you want me to do. Happy 2022 to all, stay healthy 💉 -- sarang♥사랑 05:48, 31 December 2021 (UTC)

About file size @Fry1989: you are making lots of good images, and when you use Inkscape even simpler traffic sign images will get much of SVG code. Nobody will blame you because of the kilobytes a file needs. About the view size it would be easier to look at when it is not too large, but when you have other criterions it will be fine — the main thing is that you contribute with good images!

About accuracy, when Inkscape files showing just a very simple diagram (where some px more or less do not matter at all) are drawn with 5 or more pixel fractions it will be useless accuracy; it cannot be seen wheter a stroke-width is "1" or "1.0001234", and seldom exists a reason for it. Often it is useful to 'clean' Inkscape code, but it is not required. Often a simple file can better be drawn with a text editor (as above) but not everybody knows to do, and better to have an image than to wait until the optimum version can be drawn.

Fry1989, have you ever thought about tagging your SVG files with Image generation? -- sarang♥사랑 07:50, 31 December 2021 (UTC)

@Glrx: agree, however an w:en:I-beam will be drawn 1:10, and an w:en:Escherichia_coli will be drawn not in scale, but with a bar of 1µm, for comparision. So both can be combined with other images so that the scale fits. A building is usually drawn in a scale of 1:100. Basically the size of the image should be done in such a way that the smallest readable text would have a font-size of ~25px, however on Commons I scale the image that the smallest Font-size is between 25px and 249.9px because of phab:T35245.

Yes that means that a trafic sign should not be in 1:1 scale; imho more like 1:10 or 1:5 (1:20 for legislative texts and for catalogs for driving-license-students, 1:2 for manufacturing).

@Glrx: I know convertion is tricky: User:JoKalliauer/SVG_units, bascially everyone assume 96dpi(including librsvg2.52 or newer), however librssvg till 2.51 uses 90pdi, however my 4K-screen has 163dpi.

@Fry1989: I don't see a disadvantage to produce trafic signs in scales like 1:5, if that's not the only intention of the reupload.

@Fry1989: Precission: imho difficult topic. For displaying files on commons I agree with User:Glrx that a precission of 1 per mill is not important, however for making derivatives rounding errors can cause servier issues. I knew AutoCAD much better than SVG/Inkscape now. Often a small error (something like 10^-6=0.000001) can make large troubles. Lines are not parallel any more, Automatic measuments might be wrong,... Areas that should be closed are considered as open, because of such small gaps, this can lead in AutoCAD to crashes or hours of bugfixing. And if you would use thinks like w:en:Building_information_modeling such small error lead that nothing is working, and you cannot continue till the gaps&overlaps are eliminated and even if it is just the 12 digit it is important. So the precission depends on what the derivatives are used for. If a manufacturer would like to use trafic-signs from wikipedia, than such errors might be essential for derivatives of those files. And beeing able making derivatives is a keystone for Wikimedia. I consider 1 per mill as resonable precission, so if a picture is 1000px width a change does (generally) not change more than one pixel. Is there a special reason why you care about precission that much? Is it just perfectionism? Imho useless perfectionism might not justify reuploads (watchlisttickeling,disk-space-ussage,...), it might be considered as Help:SVG_guidelines#SVG_sourcecode_edits_without_visual_change, which are imho not allowed.

Too small to see

@Sarang: If you check my Screenshot File:UK_traffic_sign_825-G-R_Screenshot_2160px_×_3840px.png the preview is rather too small than too large. However the height-limit of 600px of Commons is imho reasonable and is imho not the discussion here. Even if you would remove height/width the viewBox would suggest 512px x 873px, however it would be limited to a height of 600px so it is displayed as 351px × 599px .

 — Johannes Kalliauer - Talk | Contributions 10:14, 31 December 2021 (UTC)

​Johannes, ich staune uber deinen screenshot! Der von mir ist bei normaler Betrachtung gemacht, also 100%; gelegentlich browse ich auch mit 110% oder noch grosser. In deinem screenshot sind kaum mehr Texte lesbar, so ist nicht mehr genug zu erkennen. Bei mir entspricht das dem maximalen Zoom von 30%. Ich sprach von der normalen Betrachtung – naturlich muss bei speziellen Dateien wie zB deinem Stahl der Zoom angepasst werden, bei einfachen Verkehrszeichen sollte es eigentlich nicht notwendig sein.

Naturlich erfordern Sonderaufgaben spezielle Verfahrensweisen; ich hatte ursprunglich mit Frey1989 nur uber ganz einfache Verkehrszeichen diskutiert, wie sie auch leicht mit einem Texteditor gezeichnet werden konnten. AutoCAD sagt mir bisher gar nichts, ich weiss nur dass es ein tool fur computer aided design ist. Um mitreden zu konnen musste ich mich da einarbeiten, was mir nicht so sinnvoll erscheint. Ich kenne nicht einmal Inkscape und die anderen tools, ich beschranke mich auf einen sehr kleinen Teilbereich der SVG-Zeichnung. -- sarang♥사랑 12:26, 31 December 2021 (UTC)

normale Betrachtung

Die Standardversion von AutoCAD kostet 2300 pro Jahr oder 6000 alle 3Jahre: https://www.autodesk.de/products/autocad/overview?term=1-YEAR&tab=subscription Nicht was man sich privat zulegt.

File:UK_traffic_sign_825-G-R_Screenshot_3840px_×_2160px.png zeigt meinen Bildschirm in 100% in Querformat wie es normalerweise habe. Für einige Aufgaben drehe ich ihn aber Hochformat, dann kommt so ein Bild wie das was du vorher gesehen hast.

In deinem screenshot sind kaum mehr Texte lesbar

— User:Sarang

Meine Schriftgröße ist doch fast 30% GRÖßER als deine Schriftgröße. Dein "l" in File is 17px hoch und mein "l" in File ist 22px hoch, das heißt meine Schriftgröße ist ca. 29% größer, insofern verstehe ich nicht warum meine Text kaum lesbar sein soll. Dein Screenshot is als *.jpg gespeichert, dadurch wird es ganz unscharf&verpixelt, daher ist DEIN Text kaum lesbar. Du solltest das Bild in Originalgröße betrachten.

Wenn du mit 110% oder noch größer arbeitest, dann heißt dass dass die Pixeldichte zu hoch für dich ist.

Wenn du zu wenig vom Bild siehst, heißt das du brauchst eine größere vertikale Auflösung.

Eventuell magst du dir einen neuen Monitor leisten: https://geizhals.at/?cat=monlcd19wide&v=e&hloc=at&hloc=de&sort=p&bl1_id=30&xf=11944_1200%7E11957_matt+(non-glare)%7E11963_60%7E11967_DisplayPort%7E11967_HDMI%7E12018_70%7E12019_200%7E13263_38402160

 — Johannes Kalliauer - Talk | Contributions 14:27, 31 December 2021 (UTC)

Ja, gute Idee einen besseren Monitor einzuplanen! Meine hardware ist nicht mehr so toll, und es ist auch schwierig mit den umlauten -- sarang♥사랑 20:01, 31 December 2021 (UTC)

@Sarang: (Quetsch) Wenn du einen neuen Monitor/Hardware haben willst, kann ich dir da gerne dabei helfen. Ich habe auf https://kalliauer.com/pc_kauf/ die wichtigsten Kriterien für Office-Notebook&Monitore aufgeschrieben. Die Infos sind stichwortartig ohne viel blabla. Sie sind objektiv, das heißt Marken (geschmackssache) werden auf meiner Webseite keine genannt, sondern nur objektive Kriterien. Ich habe mich da eingelesen, aber im Internet fand ich viel heiße Luft, Fanboys die dieses oder jenes empfehlen/vorraussetzen (und jeder was anderes) und bezahlte Werbungslinks. Oft werden Information zu verkürzt, das sich eine Aussage mit einer Aussage einer anderen Webseite wiederspricht, was schlussendlich zu Fehlkäufen führt. Die Unterklasse (500€-1000€ für einen PC) wird kaum erwähnt, die Mittelklasse (1000€-3000€ pro Notebook) ist besser beschrieben, aber oftmals bekommt man eine bessere (nominelle) Hardware oft zum halben Preis des empfohlenen Produktes. Die Oberklasse (>3000€ pro Notebook) wird großteils für Gaming-PCs beschrieben, und über Office-PCs gibt es kaum Infos, und wenn dann eher die Luxus-Variante für Leute die kaum tech. Anforderungen haben (z.B. großer kontrastreicher Bildschrim für Filmschauen) und nicht schlichte Computer die Programme mit hohe tech. Anforderungen erfüllen müssen (Student:innen die GB-große Modelle bearbeiten, die auf Supercomputer über mehrere Tage rechnen).

Ich verwende Geizhals-Links weil man die tech. Anforderungen vorgeben kann und dann das günstigste Modell findet, das am Markt ist. Ich bekomme kein Geld von Geizhals, noch von sonst jemanden.

 — Johannes Kalliauer - Talk | Contributions 09:51, 3 January 2022 (UTC)

@Sarang: I will be able to upload the image by myself with the code you kindly provided. I am just holding off during this conversation, since it will determine my efforts in the future. An image generation template is also something I could use in the future.

@JoKalliauer: I will admit that I have a perfectionist bend to my images. But as I mentioned there are other considerations, such as colour palette, whether or not the image has/requires a outline border, and so forth. Another issue is that when these images are simply extracted from PDF/converted from DWG/EPS, they aren't always in a uniform scale. It doesn't matter whether using mm or px, a scale of 1:1 or 1:5, it is ideal that all the images in the set are drawn to the same appropriate scale. This is because some signs are used together, for example File:IE road sign RUS-018-L-R.svg and File:IE road sign P-051.svg are used together to create File:Ireland road sign RUS 018LR + P 051.svg. Drawing all the images to the appropriate scale makes it easy for anyone to use 2 or more images that are combined to create something new, without any re-scaling efforts.

I should also say that this issue extends beyond just the traffic signs in the United Kingdom and far into the future. I have quite a long list of countries on my user page for which I intend to upload images at some point. For consistency, this conversation will determine how I should go forward. As stated, I am prepared to use px from now on, and for the reasons I stated above I will slowly revert the images I have uploaded so far from mm to px. I would still prefer to use 1:1 scale for it's simplicity, unless there are any objections. Once I have both your advice and approval, then I will go back to my efforts. Fry1989 ^eh? 16:56, 31 December 2021 (UTC)

Hi Fry1989: I see no problem in coexistence of files with very different measure and unit, it can't be seen

• 
  646 × 646
• 
  342 × 342
• 
  2,147 × 2,147

As long as you are not using their code for something else no need will be to change anything (creating a new upload). Do not upload when only mm is changed to px. You may change your downloaded version from which you are making new images. Of course it will be better to avoid any transformation in the SVG code as long as it is possible. Good luck -- sarang♥사랑 20:01, 31 December 2021 (UTC)

Sarang, I also have no issue with the coexistence of files with different measurements when they are unrelated. The Swedish image and the British one that you linked above are completely unrelated. However, all of the British signs are part of a family, and are often used in combination. I don't intend to go back through history and change 100s and 1000s of images making them all the same, but images that are part of a family, such as on this page will have to be changed back to px because that will allow them to be combined. For example, File:UK traffic sign 811.svg and File:UK traffic sign 811.1.svg are used together. Having them both in the same format will allow anyone to combine the two signs into one image, the same way that File:Ireland road sign RUS 018LR + P 051.svg was made by combining two separate images. That way anyone wanting to do so needs minimal experience since no converting or scaling alterations need to be made. I can promise that this would be the last change I would make to those images. Since I will use px in the future, it will not become a problem again.

I am very thankful for your assistance, and your kind regards. Happy New Year. Fry1989 ^eh? 00:40, 1 January 2022 (UTC)

@Fry1989: All your considerations are understandable, and it is always good to keep the same scheme for members of an image family. Nevertheless I am unsure whether it has a high priority to see forward for a possible future combination work; which never may arise.

I got the idea that a remark in the file description, or category, might be sufficient, for you and any other future combinator? That would be preferable against the other possibility: the reupload of the whole file where no visible change occur. That "warning" or hint may look somehow like This file is drawn with the main unit mm, diverging to the other files in the category - you will use a better suitable text.

But of course it is your deal: before you get completely unhappy of the situation, or are fearing a great mess you are responsible for, you will justify the violation of the SVG guidelines. Also you can search in advance for a consent with JoKalliauer. Good success in 2022! -- sarang♥사랑 07:34, 1 January 2022 (UTC)

I think everyone, of you both, understood my arguments, so I do not have anything valuable to add. I think, I will happy with whatever you decide. I wrote most of Help:SVG_guidelines, they are just guidelines for orientation, imho none of those rules were brought to court. Sometimes those guidelines should be violated (Commons:Ignore_all_rules). I think you are both now on a more sophisticated level than the guidelines, so they imho don't apply any more.  — Johannes Kalliauer - Talk | Contributions 14:29, 1 January 2022 (UTC) :This section was archived on a request by: -- sarang♥사랑 09:02, 18 January 2022 (UTC)

W3C SVG errors

Hi,

Your edit says Category:Invalid SVG created with Other tools:Military map symbols has many validation errors. I did a random sampling (e.g., File:AFD AIR.svg) that has the file page saying 1 error, but if I click on the invalid link, the W3C validator says it is OK. Are you using a different validator?

There is a problem. If I click on the image to get the actual SVG file, my browser displays the SVG code rather than an image. The response type is image/svg+xml, but the SVG does not have the namespace declaration xmlns="http://www.w3.org/2000/svg". I'm presuming your validator complains about the missing namespace declaration.

The SVG starts with (but this is not shown by my browser):

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20000303 Stylable//EN"
"http://www.w3.org/TR/2000/03/WD-SVG-20000303/DTD/svg-20000303-stylable.dtd">

The W3C validator apparently changes the character set because it gives the listing as:

<?xml version="1.0" encoding="UTF-8"?><!-- <?xml version="1.0" encoding="iso-8859-1"?> -->
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20000303 Stylable//EN"
"http://www.w3.org/TR/2000/03/WD-SVG-20000303/DTD/svg-20000303-stylable.dtd">

Another problem is the DOCTYPE will be blocked by Commons. See Help:SVG guidelines#SVG validity.

For File:AFD AIR.svg, I added the namespace attribute, deleted the DOCTYPE processing instruction, and changed the XML encoding attribute. Your validator should accept it now.

Glrx (talk) 22:06, 26 December 2021 (UTC)

​Thank you for checking all of that. When I saw the ~160 symbols of Urhixidur from 2007, I used a batch task to get them together, intending to check them one-for-one later. I noted in the category that most of them may be invalid.

Urhixidur had been using a strange unknown tool, which draws the curves with hundreds of single dots instead of as curves. I redraw one of them, FRD AIR.svg. I assume that the doctype blocking had not yet been in use at upload time 2007.

I am thinking that it's of no use to redraw this symbols - execpt a very few ones for example. AFAIK only few of them are really used. The best thing would be to delete all the unused, and to redraw the needed ones? I will work through all of them, and divide into used and unused. Then further decisions can be considered. -- sarang♥사랑 07:06, 27 December 2021 (UTC)

​Now I gave it a check. From 160 symbols, 137 are nowhere used - nobody would miss them when deleted.

Depending an the validation tool, all files have either 1 error (when validated by the script) or 0 errors when done from the link. To avoid irritations I set them now all valid. -- sarang♥사랑 09:59, 27 December 2021 (UTC)

Yes, in 2007, there was no test for DOCTYPE. A few years ago, somebody pointed out how to use a malicious DOCTYPE to inject JavaScript, so WMF responded by limiting the allowable DOCTYPEs.

I would neither delete them nor redraw them. The images have problems, but they do display on Commons. Even though some are poorly drawn, they may have some value or use to someone. Also, we really cannot tell if they symbols are not used. In the last 14 years, somebody may have made some external links to them. We can only tell whether they are currently used on WMF websites. To me, if an image is older than a few months, then WMF should never delete the file page. If the image is a copyright violation, then the page should remain but the image should no longer display. I've run into too many deleted pages. Stability is important.

That the files are not used or little used is a good reason to avoid spending significant time on them. For that reason, I would not bother redrawing them. I remember being surprised that some simple images were so big, and I was disappointed to discover a complicated path for a simple circle. Many SVG files could be improved, but that is not to say we should improve them. I periodically look at a list of 200 bitmap images that should be converted to vector format. The list is ranked by the number of transclusions. I find many members of the list unpersuasive. Some images win priority because they are a small icon in a widely used template; resolution is not an issue. Lots of transclusions in articles that are seldom read is not a high priority. A poor quality image with one transclusion that is viewed hundreds of thousands of times per day is much more important. Images on an important topic (say Covid-19) that could benefit from translation are more important.

The simple fix is to delete the DOCTYPE and add the namespace declaration. Your category was a good list of files to fix, but the problem is more general. I could see a robot editing all SVG files that fail to make a namespace declaration; when the robot makes that edit, it could also delete empty, non-whitelisted, DOCTYPE processing instructions.

Glrx (talk) 19:12, 27 December 2021 (UTC)

Hi Glrx, I fully agree with these thoughts; in fact, it is my style since long. I delete only own files and it is a trouble to me that so often a bitmap-source of an SVG vanishes, leaving just a red link. I cannot understand that files pointed at by a reference/link get deleted.

Of course files can be accessed from outside wikipedia, this can't be seen on the wikipedia file access lsting.

We have many thousands of military map symbols, most of then with W3C errors (which does not hurt anybody) and almost all of them rather in poor SVG code, some really horrible. A great part of them are just repetions of one image in different colors, or small variations of of a base pattern. When in some future time SVG can be used not only as fix files but also as dynamically interpreted HTML-like code, kind of template should handle the variations and addings; then a few base images are enough and all variations are generated on demand. Similar to multilingual switches now, code parts can be swithed on or off, so one SVG image can contain all colors and variations, influenced from outside.

But at the moment we have to deal with fix files. In my opinion, as long librsvg can display a file more ar less properly, there is not much need to touch it; not even to correct crazy DOCTYPEs, by a bot or somehow else. -- sarang♥사랑 16:37, 28 December 2021 (UTC)

This section was archived on a request by: -- sarang♥사랑 10:50, 22 January 2022 (UTC)