Sarang

Sarang (talk: sarang) is primarily a user of the German Wikipedia. At the Commons, I mainly try to improve the categorization and to simplify SVG drawings.  My edits   My gallery   Réfo galerie   Corbelle galerie   SVG check

	SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day. For the archive overview, see Archive/. The latest archive is located at Archive/2024.

Over-categorization

Over-categorization

There seems some improovement possible with categorization.
As far as now done,the Category:Crux is subcategory to Category:Constellations, a subcategory to categories Category:Astronomical objects | Category:Asterisms (astronomy) | Category:Sky.

Category:Crux containes 3 subcategories:

• Category:Alpha Crucis
• Category:Milky Way (now I am completely confused - that's a parent, isn't it?)
• Category:Southern Cross flags.

About categorizing astronomical objects, I do not know enough about that complicated structur what is subcat or parent-cat.

But a lot of Southern hemisphere flags, showing the Southern Cross, show as well the cross of the Union Jack of the United Kingdom. Many of these flags are categorized at Category:Southern Cross flags, and also at the parent Category:Crux.

Seems that some work should be done. -- Sarang (talk) 10:54, 27 May 2009 (UTC)

SVG and clipping

Hey there. Tuvalkin suggested I asked you about this: how well does the librsvg code deals with clipping? The possibility of using it came up about the new  (ÜWBo+l) series of icon (and I can think of a few other uses too), but it's not clear whether it is at all possible. Circeus (talk) 03:50, 4 October 2011 (UTC)

Hey Circeus. Clipping is just one possibility among others. I used it several times without any librsvg-problems, and I never heard about (enough problems elsewhere but not with clipping). I am using your technique drawing parts outside the visible box as well, with no problems. But user AnonMoos told me recently that "keeping drawing elements within the rectangle is desirable if the SVG file is to be re-used as general clip-art (see File:Flag of South Africa.svg)..." — I understand that there might be problems only if you use such SVG drawings outside Wikipedia (outside the reach of our librsvg) when not converted to PNG. I cannot see the need to avoid the often much cheaper possibility to have parts outside the view. May be you ask AnonMoos more about the consequencies of these, he knows a lot.

BTW: I saw that some drawings in Icons for railway descriptions/experimental are much too complicated. Anything larger than a few hundred bytes is unnecessarily full of redundancies. Quickly I redraw some of the icons ( BSicon exSTR-C.svg, BSicon 8031.svg, BSicon 6001.svg, BSicon DAMMel.svg) reducing them to 2%, 5%, 7% and 8% respectively. IMHO it would be a good idea to look a bit more on simplicity of such simple graphics; if you want some support there just ask me! -- sarang사랑 08:42, 4 October 2011 (UTC)

Yeas, I've been simplifying stuff along the line too. It's a side part to my proposal for a new all-encompassing naming scheme for BSicons, which may get accompanied by drawing standards (there is some ridiculous variation in bridges!) Circeus (talk) 20:43, 4 October 2011 (UTC)

Template:F

Hallo Sarang, mir ist gerade bei File:Kühlsen Drostehof.jpg aufgefallen, dass seit Deinem Umbau von Template:Derivative versions die Information-Vorlage nicht mehr wie gewohnt angezeigt wird, nämlich wenn die Option „other fields“ genutzt wird. Der graue Rahmen um das komplette Information-Zeugs schließt dann „other fields“ (hier: Namensnennung) nicht mehr mit ein. Gut sehen kannst Du den Unterschied, wenn Du bei diesem Bild in der Vorschau die „Derivative versions“-Vorlage entfernst (dann erscheint das Namensnennungs-Feld wieder als normaler Bestandteil des Infokastens). Ich vermute, dass Template:F ursächlich ist, und dass dort etwas fehlt oder zuviel ist, entdecke aber auf Anhieb nichts und hoffe, dass Du dieses Problemchen lösen kannst. Grüße --:bdk: 18:34, 14 October 2011 (UTC)

Hallo bdk, danke für die Nachricht. Bisher konnte ich die Ursache noch nicht lokalisieren, aber ich finde es noch heraus, und mache es bald wieder heile. Gruß -- sarang사랑 22:49, 14 October 2011 (UTC)

Fein, dank Dir schon mal :-) --:bdk: 00:23, 15 October 2011 (UTC)

Hallo bdk, das Problem hätte ich nun ermittelt; eine allen zusagende, perfekte Lösung ist weniger einfach.
Also, der graue Rahmen wird nicht von {{F}} unterbrochen, es liegt an der von {{Derivative versions}} erzeugten Liste, und war bereits vor meinen Änderungen so; das Problem tritt identisch bei {{Derived from}} auf.
Jede Liste im Element "other_versions" von {{Information}} zerschlägt den Rahmen! Sieh dir einfach mal an, was bei der Eingabe von |other_versions=*Test geschieht. Noch viel schlimmer wird es, wenn |Permission=*self eingegeben wird.
Die Liste lässt sich mehr oder weniger gut substituieren. Weniger gut, weil das manuelle <br> ungleiche Umbrüche erzeugt, und weil ich diesen blauen Bollen nicht so schön dick hinbekomme, mit • oder • komme ich nicht hin (blau wäre kein Problem, aber das bringt es ja wohl nicht). Es gibt eine ganze Menge anderer Zeichen die verwendet werden könnten, z.B. ♦. In Kühlsen Drostehof.jpg habe ich es mal mit ⇒ versucht und weiss bereits jetzt, dass das vielen nicht gefallen würde...
Eine Möglichkeit wäre es mit zu versuchen — ich habe da etwas für diesen Zweck besser geeignetes gezeichnet, wenn die Bullet-Darstellung mit einer Datei erfolgen soll, das "", es kann noch beliebig angepasst werden.

Nun gibt es auch die Vorlage {{Bullet}}, die so ein Ding   erzeugt. sarang♥사랑 20:08, 17 September 2013 (UTC)

Vorerst habe ich das nur in {{Derivative versions}} eingebaut. Wir können das hier weiterdiskutieren und nach besseren Lösungen suchen. Gruss -- sarang사랑 09:12, 15 October 2011 (UTC)

Hallo bdk, der Änderung in {{Derivative versions}} war nur sehr kurzes Leben beschieden, sie ist nach zwei Minuten zurückgesetzt worden. Die Situation ist ja eigentlich so, dass es nur ein work-around war für ein Problem, das tatsächlich in {{Information}} liegt, bei den Elementen Permission und other_versions; diese Vorlage ist heavy used, und um einiges komplizierter. Aber ich werde sie mir mal gelegentlich ansehen. Du könntest auch das lokalisierte Problem der Vorlagenwerkstatt melden, die haben Fachleute für so was. Gruss -- sarang사랑 09:28, 15 October 2011 (UTC)

Texteditor für SVG

Moin, ich bin von deinen Ideen (und Fähigkeiten) zur Bekämpfung aufgeblähter SVG wirklich begeistert und habe mir schon einige Inspiration für die Arbeit mit dem Texteditor geholt. Ich vermisse allerdings immer wieder hilfreiche Tools für diese Arbeit: Umwandlung von absoluten in relative Angaben; transformierte Pfade in normale Pfade mit neuen Koordinaten umzuwandeln... Eigentlich ist das ja nur Mathematik :) Hast du dafür etwas in Nutzung oder eine Idee? Und hast du zufällig Erfahrungen mit Programmen wie Scour, die einen Teil des Überhangs per WYSIWYG erstellter SVGs entfernen wollen? Vielen Dank für deine inspirierende Arbeit hier.. --Richtest (talk) 12:28, 8 December 2011 (UTC)

Hallo RichTest, es freut mich immer sehr zu sehen dass ich doch nicht als einziger an den redundanzüberfrachteten SVGs Anstoss nehme. Allerdings muss ich gestehen dass ich nicht nur null Erfahrung mit SVG-Programmen wie Inkscape&co habe, ich wende auch sonst sehr primitive Methoden an. Scour kenne ich nicht. Zum Editieren finde ich Notepad++ ausreichend, und die von dir angefragten Umrechnungen absolut→relativ bzw. Transformationsauflösungen lasse ich von Microsoft Excel errechnen, trotz mancher Mängel; die Relativierung kubischer Béziers ist damit etwas komplizierter, umso einfacher ist das Runden zur Reduzierung der Nachkommastellen. Für Zwischenkonversionen verwende ich noch andere MS-Programme wie das dafür sehr hilfreiche Word mit Macros. Falls dich solch primitive Hilfsmittel näher interessieren verrate ich dir gerne mehr, damit du nicht alles neu erfinden musst.

Es wäre natürlich grossartig dafür ein leistungsfähiges Programm zu haben, mit ausreichend Einstellmöglichkeiten und dennoch leicht zu bedienen… Bis so was gefunden (oder erfunden) wird mache ich mit meiner umständlichen Methode weiter. Und vieles dürfte einer automatisierten Bearbeitung kaum zugänglich sein, da bedarf es weiterhin menschlicher Interaktion. Wenn ich Grund zur Annahme hätte dass das noch mehr Benutzer interessiert könnte ich für sie eine Art Diskussionsportal einrichten, irgendwo im Umfeld von SVG Simplified. Es kommt noch dazu dass ich kaum neue Grafiken entwickle, stattdessen zeige ich beispielhaft bei den allerärgsten Hämmern wie es anders sein könnte.

Natürlich interessiert mich auch an welchen speziellen Grafiken du gerade bastelst. Gruss, -- sarang사랑 14:12, 8 December 2011 (UTC)

Hmm, also ich hab dieses Jahr mein erstes SVG gebastelt (Karte mit Openstreetmap-Daten), und dann ein paar simple Symbole: . Diese sind aber nicht aufs letzte Byte, sondern auf mein Verständnis hin optimiert. Habe mir (allerdings eher als Spielerei) auch schon mal kleine Programme geschrieben, die SVG-Dateien erstellen, zum Beispiel mit Zufallsgeneratoren.

Für Karten ist Inkscape o.ä. unerlässlich, aber die Ergebnisse ungeheuer aufgeblasen und ohne SVG-Eleganz. Aber bei 300kB SVG Ausgangsmaterial ist halt nix von Hand zu machen, wenn man nicht alles nachzeichnen will. Das mit Excel klingt sehr spannend, auch wenn ich mir gerade nicht vorstellen kann, wie du das gemacht hast.. Ich schick dir über de.wp mal ne Mail, vielleicht hast du Lust, mir das mal zu schicken, ist vielleicht einfacher als alles zu erklären. Vielen Dank -84.169.181.193 14:54, 8 December 2011 (UTC)

Ganz ausdrücklich beschänke ich mich auf einfache und einfachste Grafiken, also so was wie deine beiden BSicons. Natürlich lässt sich Aufwendigeres wie Karten nicht mehr von Hand zeichnen – aber immer noch anschliessend überarbeiten, mit tools und auch manuell, um zu einem akzeptablen Ergebnis zu gelangen.

Wie gesagt mache ich das meiste mit nur sehr geringer Unterstützung durch Automatismen. Wenn ich dir meine Vorgehensweise erkläre wirst du sicher Verbesserungsmöglichkeiten erkennen. Ich habe noch das "alte" Windows, XT glaube ich, die Officeprogramme sollten kompatibel sein, falls du moderner bist. Deine Mail ist angekommen, ich werde nun was zusammensuchen und -schreiben. -- sarang사랑 15:13, 8 December 2011 (UTC)

Hat zwar eigentlich mit deinem Ansatz nix zu tun, aber ich hab Scour mal ausprobiert, das reduziert fast auf die Hälfte bei meiner Karte, entsorgt viel Ballast, aber versteht natürlich nix, fürs automatische Gruppieren von Elementen aber ganz nett. Freu mich auf deine Mail, evtl. kann ja daraus eine Art Simple-SVG-Tutorial für Commons werden. -Richtest (talk) 16:17, 9 December 2011 (UTC)

Dass Scour ein leistungsfähiges tool sei und generell angewandt werden sollte habe ich früher schon gehört; wir könnten das deutlicher publik machen.

Leider habe ich noch nicht geschafft, ein übersichtliches Rezept für Simplifizierungen zu editieren. Auf die Schnelle habe ich in File talk:BSicon DRAISINE.svg ein paar Anmerkungen notiert, die dich vielleicht interessieren (Englisch ist nicht meine grosse Stärke, wenn du meine Texte verbesserst bin ich dir dankbar). Am Rezept bastele ich noch. Auch im Hinblick auf ein ev. Tutorial - wenngleich mir meine Methode etwas zu primitiv erscheint. -- sarang사랑 16:57, 9 December 2011 (UTC)

Ok, mit der DRAISINE hast du dir ja wirklich Arbeit gemacht, danke. Du scheinst wirklich ein Byte-Fuchser zu sein, das ist ja schon eine eigene Wissenschaft. Ich versuche allerdings meine SVGs lieber so zu erstellen, dass ich auch später noch verstehe, wozu was dient. Und das könnte ich nach deiner Radikalkur wohl nicht mehr ohne weiteres, auch wenn das vermutlich Übungssache ist. Plattenplatz im Byte-Bereich ist mir allerdings auch nicht so wichtig :) --Richtest (talk) 22:44, 9 December 2011 (UTC)

Das weiss ich schon dass ich da masslos übertreibe, alles Unnötige radikal wegzulassen; zur Leserlichkeit, da hast du recht, sollten wieder ein paar Zeichen mehr rein. Die Draisine ist ein Beispiel, beim Handcar liesse sich (in der Relation) mehr einsparen. Ich habe die Draisinengrafik nicht hochgeladen, wenn du sehen willst ob wirklich dasselbe gezeigt wird musst du es erst ausprobieren. -- sarang사랑 00:19, 10 December 2011 (UTC)

Herausforderung angenommen: File Talk:BSicon HANDCAR.svg. Viel Spaß, ich glaube, ich hab es dir nicht zu leicht gemacht. Ich hab leider gerade wenig Zeit, um das Thema wirklich anzugehen, aber ich werd deine Mail nicht vergessen.. Danke --Richtest (talk) 01:32, 10 December 2011 (UTC)

Gratulation - das hast du ausgezeichnet hinbekommen. So sollten IMHO einfache SVGs erstellt werden! Wie Inkscape, Adobe &Co so was machen würden weisst du ja… Bei hinreichendem sportlichen Ehrgeiz lassen sich an bereits vereinfachten Grafiken immer wieder noch einzelne Bytes sparen, wobei der relative Aufwand dafür extrem ansteigt, und das Ganze immer mehr zu Lasten der Leserlichkeit geht. Ein recht krasses Beispiel ist die letzte, 6. Variante von Iching-hexagram-64.svg:  diskutiert in File talk:Iching-hexagram-64.svg. Dessen 5. Version ist sehr elegant, die 6. jedoch schlichtweg nicht mehr verständlich. Speziell bei Serien erscheint es sinnvoll, ein brauchbares Muster zu haben, aus dem dann mit minimalen Anpassungen alle anderen Grafiken entwickelt werden können, wie in SVG simplification templates angedacht. Bei den BSicons gibt es vielfach auch Kleinserien von ±12 Grafiken, wie bei denBSicon ABZdf.svg-Variationen. So ein Muster sollte vor allem mit geringem, Aufwand varierbar sein und dafür nicht bis zum allerletzten Byte minimiert. -- sarang사랑 11:46, 10 December 2011 (UTC)

Mir ist gerade Wikiprojekt SVG #Manuell erstellte SVGs aufgefallen. Dort sollte man zumindest mal was dazu schreiben, wie die Vorteile aussehen und co.. -Richtest (talk) 20:53, 12 December 2011 (UTC)

Different SVG styles

The only SVG I've made from scratch which uses stroke-dash is File:Overhand-folded-ribbon-pentagon.svg (as far as I remember), while you seem to be constantly attempting to come up with new and innovative ways of making use of dashing... -- AnonMoos (talk) 13:58, 14 December 2011 (UTC)

Dashing seems really often a good way to minimize a drawing. Many files in Checkered could be drawn that way, and in many other cases it makes things easy, even when the first glance does not show dashed lines.

It had not been an option for Broken crossed circle.svg because its line ends, so I made it this time rather complicated with clipping twice instead. Sure a better solution can be found, at least the drawing is exact, even strict mathematically.

With Broken crossed circle 2.svg I had again troubles with the librsvg bug, it took ".16" for "0" and before I changed it to "0.16" (which will work) you remade in a good way. Thank you -- sarang사랑 17:33, 14 December 2011 (UTC)

I was motivated to change File:Broken crossed circle 2.svg as much as by the errors in the description and filename as anything. I changed the English description, but the German one is still inaccurate -- it's really not a cross, and it has only a somewhat remote relationship with a swastika... AnonMoos (talk) 19:21, 15 December 2011 (UTC)

I shall care for the German description -- sarang사랑 21:50, 15 December 2011 (UTC)

Feeling quite Sarang-ish today

File:Optical-illusion-diamonds.svg is the first SVG I made with a dashed line as wide as it is long... -- AnonMoos (talk) 14:14, 13 April 2012 (UTC)

Good and interesting work! I changed the template for two reasons:

1. now it is tagged "valid SVG" and the validator displays the source code, and
2. it is now an example in the dasharray-subcategory of SVG simplification technics where I am collecting some hints (if anybody will give them a look ...).

Do you have more ideas for the technics collection? -- sarang사랑 14:59, 13 April 2012 (UTC)

Probably should be spelled "techniques"... -- AnonMoos (talk) 15:03, 13 April 2012 (UTC)

Thank you. I am always fighting for good English, without success . Changing a category name is a bit complicated, but if you improve some of may sentences: just go ahead! At SVG simplification by cloning I tried to explain what I called "cascaded cloning" (I am fearing my description is not very clear; this technique would reduce the number of "use"s in your drawing. -- sarang사랑 15:28, 13 April 2012 (UTC)

"Cascaded" is OK; "nested" could also be used... AnonMoos (talk) 16:31, 13 April 2012 (UTC)

Chess piece simplification

Thank-you for your edits to the yellow bishop. There are many other chess pieces, so if you are interested in doing one of each, I'll happily recreate the other colours and variations of them.  :) NikNaks _{talk - gallery - wikipedia} 14:50, 26 December 2011 (UTC)

Of course I can give it a look, and do it time by time. If you look for the differencies you may see that it is not at all difficult but nevertheless it's some work needing time. -- sarang사랑 17:17, 26 December 2011 (UTC)

Knots

Actually, the serious mathematicians at http://katlas.org/ would consider me a mere tyro, since my interest is more on the quasi-decorative or ornamental uses of knots, not the basic mathematics. However, you can see my knot atlas home page (currently not fully updated) at http://katlas.math.utoronto.ca/wiki/User:AnonMoos ...

As for File:9crossings knot.svg, it's not mathematically a "knot" at all, unless the over-under interlacings are shown. If the interlacings are alternating, then it's a "7 4 knot", or Buddhist Endless Knot... AnonMoos (talk) 15:41, 27 December 2011 (UTC)

File:Chenhao2007SHIFF.jpg

Analyzed at http://katlas.math.utoronto.ca/wiki/8_18 . File:Celtic-knot-twoloops-bigends.svg has 14 crossings, and is mathematically technically a "link", not a "knot"... -- AnonMoos (talk) 17:18, 27 December 2011 (UTC)

SVG problem

Do you have any idea why the "14:50, 2 February 2012" version of File:No Logo logo.svg doesn't display correctly? It seems to be a bug, but if so, it's a rather strange one, and I don't know how to avoid it... AnonMoos (talk) 16:04, 2 February 2012 (UTC)

Oops, never mind, as soon as I posted this message, I finally saw the problem (had been assuming that a duplicate of the "N" outline was the "L" outline...). AnonMoos (talk) 16:10, 2 February 2012 (UTC)

Sometimes it's really difficult; and from time to time somebody else can help. That is the Wikipedia community. -- sarang사랑 16:15, 2 February 2012 (UTC)

File:AFEMRib.svg

LOL. I didn't think it was possible to minimize it any more. Nice work. Magasjukur2 (talk) 08:50, 13 February 2012 (UTC)

You did really good simplification work. But some reductions remain still almost always as a possibility. -- sarang사랑 08:55, 13 February 2012 (UTC)

Category talk:SVG simplified Coats of Arms

I was inspired by the discussion there, and the shield shape SVGs I included on that page to create a personal coat of arms for myself. Sorry that the SVG file is a hulking behemoth, weighing in at a huge 11kb, but the shield and its contents by themselves (omitting the triskelion and motto text converted to paths) would be a mere 2kb... AnonMoos (talk) 02:20, 16 March 2012 (UTC)

It looks really good! Lots of your work lead to a remarkable success. Good idea to document all its history and that of its components. sarang사랑 06:37, 16 March 2012 (UTC)

I took the freedom to reduce the size there on the talk page

It doesn't compare artistically to what User:Sodacan does, but it seems to work in its own little semi-paradoxical way... -- AnonMoos (talk) 23:53, 16 March 2012 (UTC)

Following your hint I looked at the pix of User:Sodacan; I admire this. But for my part, I restrict to my good old simple SVGs. sarang사랑 11:28, 17 March 2012 (UTC)

File:宿-5BBF.gif

Making a GIF transparent in cases such as this means thumbnails will have a relatively low quality (the transparent area eats away at the black area, so that small text will quickly become illegible)... AnonMoos (talk) 07:27, 19 March 2012 (UTC)

Thank you, I didn't know that. Now I can care in future; but I use GIF rather seldom and only for intermediate reasons, when SVG seems too much effort. Depending the case of this picture, I should rather remove the text from the picture, the explanation given in the description is more useful.

Sure you have seen that I redrew some extremly simple pics of Sodacan, when Sodipodi/Inkscape seems to me not such a good choice, as with this chakra: . sarang사랑 08:27, 19 March 2012 (UTC)

Possibly interesting SVG file

File:Op-art-4-sided-spiral-tunnel.svg has an unusual structure; it's highly repetitive, yet I'm not sure that the repetitive parts can be collapsed... AnonMoos (talk) 08:02, 30 March 2012 (UTC)

Good job on condensing; I had some difficulty in understanding how File:Op-art-4-sided-spiral-tunnel-6.svg etc. worked at first, but eventually managed to optimize the original file in the same way... AnonMoos (talk) 15:02, 31 March 2012 (UTC)

256x256 - Matrix

Hallo Sarang.
Vielleicht findest du etwas Zeit meinen Code für das Gitter in File:4-ary Boolean functions; matrix gbec; 1.svg zu verbessern. Ich habe viel mit Klonen gearbeitet um es einigermaßen schlank hinzukriegen, aber du findest bestimmt was Überflüssiges. Ich werde dieses Gitter oft benutzen, es lohnt sich also. Die Ebene entries brauchst du dir nicht anzusehen. Grüße, Lipedia (talk) 01:28, 20 May 2012 (UTC)

OK, ich schau mal. Bis bald sarang사랑 09:19, 20 May 2012 (UTC)

Jetzt habe ich es mir angesehen. Es ist viel einfacher als ich erst dachte, denn die breiteren Trennstriche verschieben die Quadrate nicht, sondern nehmen den benachbarten ein wenig Platz weg; das ist nicht ganz exakt, aber einerseits nicht zu sehen und somit ausreichend; andrerseits wäre die Berechnung für die farbigen Quadrate sehr umständlich, wenn die weiter rechts und unten stehenden immer um diese Pixelbruchteile verschoben wären. Das Gitter geht also sehr einfach zu zeichnen.

Immer wieder bin ich verblüfft wieviel unsinnigen Code Inkscape-Sodipodi zu erzeugen imstande ist. Z. B. das farbige Quadrat mit M 255 127 L 256 127 L 256 128 L 255 128 L 255 127 z. Die letzten paar Zeichen (L 255 127) und (z) sind äquivalent, eines davon würde genügen, und es sind sogar beide überflüssig. Der Code M255,255h1v1h-1 leistet genau dasselbe, wobei nur die beiden Koordinaten nach dem "M" variert werden müssen, das "h1v1h-1" bleibt für jedes der 256 × 256 möglichen Quadrate gleich (sog. relative Koordinaten: 1px horizontal nach rechts, 1 vertikal runter, 1 horizontal nach links - das ist es!). IMHO erhöhen die vielen redundanten Leerzeichen die Leserlichkeit keineswegs.

Ich werde schnell eine simplifizierte Version erstellen, die genau dasselbe zeichnet. Dauert noch ein wenig.

Wie erstellst du die Variationen? Wird das von einem Programm umgesetzt, oder machts du die Einträge manuell? sarang사랑 15:08, 20 May 2012 (UTC)

Ja, das Gitter ist einfach. Ich weiß nur nicht wie viel von dem Header Müll ist - oder vielleicht gebraucht wird, damit die Klone funktionieren. Ich halte es nicht für sinnvoll die farbigen Pfade in Ebene entries stark zu vereinfachen - abgesehen davon, dass ich die Startpunkt-Endpunkt-Redundanz und überflüssige Zeichen weglassen könnte. Ich habe in MATLAB ein Programm namens bin2svg.m geschrieben, das mir eine Binärmatrix in den Code für einen SVG-Pfad umwandelt. Das könnte ich in Details leicht ändern, aber ich habe wenig Lust auf Änderungen, die nur für Rechtecke Sinn ergeben (M255,255h1v1h-1), weil die meisten Pfade vermutlich keine Rechtecke sein werden. Wenn es dir Spaß macht, kannst du natürlich bin2svg.m überarbeiten. Lipedia (talk) 15:55, 20 May 2012 (UTC)

Können wir vielleicht die Details am Telefon besprechen? Du kannst mir ja eine Festnetznummer mailen. Sonst stelle ich es halt schriftlich zusammen, was es an Möglichkeiten gibt. sarang사랑 15:50, 20 May 2012 (UTC)

Ich glaube das Thema ist schriftlich am besten zu lösen. Willst du den Code für bin2svg.m? Lipedia (talk) 15:55, 20 May 2012 (UTC)

Gut, schriftlich. Ich würde auch die Transformationen weglassen, dazu müsste einen von mehrenen möglichen Anpassungen gewählt werden: das ganze kleiner, 256 × 256 + die Ränder; wenn du die Grösse 780 × 780 beibehalten willst, ginge das unwesentlich komplizierter mit viewBox. in beiden Fällen funktioniert die Färbung mit beiden oben gezeigten Methoden, der umständlichen und der kurzen.

Die größere Version geht auch ohne viewBox, dann müssten allerdings die Koordinaten den dreifachen Wert + 6 angeben, und h3v3h-3 zum Zeichnen (wenn es ohnehin per Programm errechnet wird wäre das wohl egal).

Oder eben doch mit Transformation.

Ich kann dir Muster machen von allen Möglichkeiten, oder du legst vorab fest was dir am ehesten liegt; dann mache ich das und du kannst es dir ansehen. sarang사랑 16:14, 20 May 2012 (UTC)

Mir ist gerade was seltsames passiert: Ich wollte dir als Muster File:Hadamard-Code.svg zeigen (mit bin2svg.m erstellt), aber beim Hochladen ging <?xml version="1.0" encoding="UTF-8" standalone="no"?> verloren. Verstehst du das?
Ich dachte mir schon, dass du die Transformation weglassen willst, aber ich will die Dinger auf jeden Fall in ordentlicher Größe auf der Beschreibungsseite, und andererseits würde ich den Output von bin2svg.m gern unverändert einbauen. Finde ich irgendwie eleganter.
Da die kleine Matrix nicht wollte habe ich jetzt mal File:Binary Walsh matrix 256.svg als Beispiel hochgeladen an dem man sieht wie mein Programm gegenwärtig die Pfade erstellt. Selbst bei diesem komplizierten Muster ist die Dateigröße moderat, ich sehe also keinen dringenden Verbesserungsbedarf bei den Pfaden. Nur der Header und das Gitter sind halt sehr unaufgeräumt. Lipedia (talk) 16:52, 20 May 2012 (UTC)

Gut, Tilman, ganz wie du willst. Im Header ist fast alles unnötig, und wenn nicht geklont wird ist auch "xmlns:xlink" überflüssig. Und das Gitter geht sehr einfach. Ich mache dir jetzt eine einfache Version von 4-ary Boolean functions; matrix gbec; 1.svg mit deinen Pfaden, auch wenn sie viel komplexer sind als nötig. Wie soll ich es machen - über deine Version laden, oder als Code in die Talkpage stellen? sarang사랑 17:07, 20 May 2012 (UTC)

Lad einfach drüber. Detailverbesserung an den Pfaden könnte ich noch mit einbauen. Wie würdest du
M 3 1 L 4 1 L 4 3 L 3 3 L 3 4 L 1 4 L 1 3 L 2 3 L 2 2 L 3 2 L 3 1 z
schreiben? (Das ist die zweite Pfadzeile in File:Binary Walsh matrix 256.svg.) Lipedia (talk) 17:27, 20 May 2012 (UTC)

Mal sehen: von Position 3,1 nach 4,1 geht mit h1; von 4,1 weiter nach 4,3 geht mit v2; von dort nach 3,3 geht mit h-1 (oder H3); runter nach 3,4 mit v1; nach links von 3,4 auf 1,4 mit -h2 (oder H1); rauf nach 1,3 mit v-1 (oder V3); mit h1 nach 2,3; mit v-1 nach 2,2; mit h1 nach 3,2; wenn es wie in der Walsh Matrix eine gefüllte Struktur ist reicht das, bei nur Umriß (fill="none") geht es mit "z" nach 3,1.

Also entweder verschieblich M3,1h1v2h-1v1h-2v-1h1v-1h1(z) oder absolut M3,1H4V3H3V4H1V3H2V4H3(z) (wenn ich mich nicht vertan habe...). Absolute Koordinaten können grössere Zahlenwerte benötigen, hier bei diesen Werten nahe dem Ursprung wird es durch das Vorzeichen länger. Natürlich kann absolute und relative Angabe gemischt werden, der Vorteil bei relativen ist die Verschieblichkeit - nur die Anfangskoordinaten müssen geändert werden.

Ich glaube das Klonen war nicht ganz korrekt, doch habe ich es nicht geprüft; jedenfalls sieht die 4-ary-Bool von mir etwas anders aus, regelmäßiger.

Jetzt habe ich die umständlichen Pfade drin, soll ich sie doch vereinfachen? sarang사랑 18:02, 20 May 2012 (UTC)

Beide Versionen sind jetzt hochgeladen, erst absolut, dann darüber relativ. Eventuell könnten die Strichstärken variiert werden?

Was beim Hadamard-Hochladen passiert ist kann ich mir auch nicht erklären, jedenfalls habe ich es heile gemacht. Ich hoffe ich konnte dir so helfen, wie du es wolltest. sarang사랑 18:49, 20 May 2012 (UTC)

WTF - echt beeindruckend, danke. Ich hätte nie gedacht, dass man das Gitter so klein kriegt. Jetzt verstehe ich auch deine Art die Pfade zu vereinfachen. Das müsste ich hinkriegen, mein Programm so zu verändern. Lipedia (talk) 20:10, 20 May 2012 (UTC)

Hallo Timan, da bin ich ganz sicher dass du das hinbekommst; die Programmierung sollte sogar um einiges einfacher werden als bisher. Natürlich könnte da noch viel weiter minimiert werden, aber es muss ja auch nicht übertrieben werden; wenn die ärgsten Inkscape-Redundanzen eliminiert werden ist schon viel gemacht. Wenn dir noch was nicht so klar ist mit SVG: frage mich, einiges weiss ich mittlerweile, und auch dokumentiert ist bereits manches in SVG simplification techniques. Ich werde da noch was reinstellen über Koordinaten, vielleicht gelingt es mir das verständlich darzustellen.

Ich habe null Ahnung von MATLAB, aber dein Programm interessiert mich, sicher kannn ich da von dir viel lernen. Ich mache bisher solche Berechnungen sehr primitiv mit EXCEL, mit externer Rumkopierei… ganz archaisch! Gruß sarang사랑 06:51, 21 May 2012 (UTC)

Hallo Tilman, ich konnte es doch nicht bleiben lassen dir noch die Variante mit relativen Parametern zu zeigen, da ändert sich "M" zu "m" und bei den höheren Zahlwerten wird einiges gespart. Ob du das in dein Programm einbauen willst wirst du entscheiden, die Berechnungslogik ist trivial (auch für eine eventuelle Wieder-Absolutierung; falls größere Änderungen anstehen, denn mit absoluten Werten ist alles viel flexibler. Ich habe mir Hilfsmittel zur Konvertierung in beide Richtungen erstellt.)
Bei Grafiken wie der Walsh matrix wäre der Spareffekt viel signifikanter.
Nur aus Gründen der besseren Lesbarkeit habe ich jedes Quadrätchen in einer Zeile belassen, eine Variante ohne linefeeds innerhalb der Pfaddaten wäre mit 868 bytes um 30 Stellen kleiner. Aber wir wollen ja nicht übertreiben, und den Code inspizierbar lassen. sarang사랑 14:14, 21 May 2012 (UTC)

So - hab mein Programm überarbeitet und veröffentlicht: v:User:Lipedia/bin2svg

Hast du was gegen große Ms? Siehe File:Hadamard-Code.svg und File:Binary Walsh matrix 256.svg.

Lipedia (talk) 20:53, 24 May 2012 (UTC)

Sieht gut aus! Dass es was gebracht hat und viel einfacher ist, siehst du ja selbst. Grosse "M" bedeuten: absolute neue (Move-to) Position, wenn kein neuer Kommandobuchstabe folgt werden die folgenden x/y-Parameter behandelt wie wenn ein "L" codiert wäre. Kleines "m" bedeutet die Werte sind die relative Verschiebung zur aktuellen Position (wenn es das erste Zeichen eines path data-strings ist ist es natürlich eine absolute Position), und es wird ein "l" impliziert wenn kein Kommandobuchstbe folgt.

Bei Hadamard folgt immer ein Kommando, somit entfällt die Bedeutung für die Folgeposition.

Da es meist lange Ketten von v/h-Kommandos enthält, wird die Einsparung durch das relative "m" nicht allzu berauschend werden; andrerseits wäre es bei den durch Programm erzeugten Parametern sicher leicht, stets die aktuelle Position zu wissen und statt "M" relativ zu codieren. Das Programm könnte sogar vergleichen was weniger Zeichen benötigt und dann je nachdem "M" oder "m" ausgebeben... Aber wie gesagt, das Programm müsste erweitert werden, und der Effekt wäre nicht mehr so dramatisch wie bei dem was du bereits erzielt hast. Wenn es dir Spass macht, der Sache wegen, nur zu; wennn nicht kannst du auch sehr zufrieden sein mit deinem Erfolg. Jedenfalls finde ich es gut codiert und ich habe nichts daran zu meckern. Glückwunsch zum Erfolg! sarang사랑 20:59, 24 May 2012 (UTC)

File:Bin2svg icon.svg

Eben ist mir aufgefallen: Codierungen wie M5,5h1v1h-1v-1 können noch etwas vereinfacht werden, ohne das "schließende" v-1 wird genau dasselbe gezeichnet. Äquivalent wäre M5,5h1v1h-1z, aber das v-1 (oder in diesem Fall V5) oder z wäre nur für die Umrisslinie (stroke="#???") erforderlich, während Flächen (fill="#???" bzw. implizit black) automatisch zum (letzten) M/m-Ausgangspunkt hin geschlossen werden (Svg example fill.svg: ). Allerdings gilt das nicht für die aktuelle Position, die wird nur dann zum Ausgangspunkt zurückgeführt wenn es auch so codiert ist. Zu deiner Information, falls du es noch etwas schlanker haben möchtest. Nachtrag: In 4-ary Boolean hatte ich das Grün etwas geändert, weil IMHO #0F0 etwas zu hell ist, #0C0 passt weit besser zum Rot. sarang사랑 04:16, 25 May 2012 (UTC)

Die Kleinigkeit mit der letzten Koordinate habe ich noch geändert. Optimieren könnte man jetzt endlos. Dir wird nicht entgangen sein, dass man ein Schachbrett mit acht statt 32 Rechtecken zeichnen kann, und dann gibt es ja noch Klone. File:Binary Walsh matrix 256.svg schreit natürlich nach Klonen, auch File:4-ary Boolean functions; matrix ggbec; 55424.svg könnte man auf etwa ein Achtel eindampfen. Man könnte sicherlich einige Monate seines Lebens mit der Optimierung von bin2svg verbringen. Mich irritiert gerade eher, dass ich bei deinem Gitter in Inkscape die dünnsten Linien nicht sehen kann (oder nur vereinzelt). Stört mich ja nicht so lange sie hier zu sehen sind, ist aber seltsam. Lipedia (talk) 21:04, 25 May 2012 (UTC)

Natürlich könnte man noch endlos rumspielen und sich einen verkünsteln - da jedoch der nun erreichte Status sowohl gut strukturierten & leserlichen Code enthält als auch praktisch ballastfrei ist, hast du dein Ziel erreicht: über eine sinnvolle Ausgangsbasis für viele weitere Matrices zu verfügen.

Das mit den "dünnsten Linien…" konnte ich nicht verstehen, dass sie nur vereinzelt aber hier doch zu sehen seien. Klärst du mich bitte auf?

Die der Matrix innewohnende mathematische Logik habe ich noch nicht angesehen, wo sich Strukturen wiederholen und wie weit Kloning möglich ist. Wenn diese Logik allen Matrizen gemeinsam ist und bei dichter besetzten Gittern entsprechend viel einsparen lässt, wäre es natürlich schon etwas von ästhetischem Reiz, das wir überlegen könnten. sarang사랑 05:43, 26 May 2012 (UTC)

Es gibt die dünnsten Linien im Gitter, durch die man 256x256 u nd nicht nur 64x64 Quadrate sieht. Die sehe ich auf Commons, aber nicht wenn ich die Datei in Inkscape aufmache. Lipedia (talk) 07:04, 27 May 2012 (UTC)

Die dünnsten Linien der Einzelquadrate habe ich mit 0,03 px definiert, das px wiederum kann mit 0,01 mm angenommen werden. In der 2000er Vergrößerung ist die Linie gut zu sehen, bei kleinerer Darstellung natürlich weniger. Gerne kannst du es mit anderen Strichstärken versuchen, doch bleibt es grenzwertig, in einer Grafik 256 × 256 Quadrate darstellen zu wollen: in Gesamtsicht verschwinden da die Einzellinien zu Schatten, und in starken Vergrößerungen sind nur mehr Teilbereiche anzeigbar. Bei SVG kann es in verkleinerten Übersichten auch wesentlich anders aussehen wenn Strukturen genau auf Pixelgrenzen oder daneben definiert sind.

Was Inkscape zeigt habe ich noch nicht untersucht, für SVG offline verwende ich Firefox (und fallweise Windows IE), die vieles anders anzeigen als der Wikimedia renderer librsvg. Von den unterschiedlichen Macken dieser tools abgesehen, wird es bei derart feiner Strukturierung nie unproblematisch sein. Die Variante mit dasharray ist eine von vielen Möglichkeiten, und jede Variante kann in der Verkleinerung (als thumbnail) anders wirken. Übrigens, während der Entwicklung habe ich die Grafik mit viewBox extrem vergrößert, um die Details deutlich sehen zu können - so habe ich mich auch um größtmögliche Annäherung an deine Ursprungsgrafik bemüht. sarang사랑 06:25, 28 May 2012 (UTC)

Signature

Please change your signature. Per Commons:Signatures#Images_in_signature, images of any kind must not be used in signatures. Thank you --Gauravjuvekar (talk) 17:25, 23 June 2012 (UTC)

 Done. sarang♥사랑 17:34, 23 June 2012 (UTC)

Hello, Sarang. You have new messages at MGA73's talk page. You may remove this notice at any time by removing the {{Talkback}} or {{Tb}} template.

Resolved sarang♥사랑 17:24, 20 July 2012 (UTC)

U6A02 (樂)

OK, if it's a real tattoo, then it's certainly a rather large one, so I was mildly curious as to why it might have been chosen. Thanks... AnonMoos (talk) 15:51, 1 July 2012 (UTC)

The upper right 幺 was difficult to see on the 1^st pic; the 2^nd one was better. If the pic was licencable I would add it to the category, but for sure it is not. I am thinking of creating an own category Chinese glyph tattoos within the next days. -- sarang♥사랑 16:02, 1 July 2012 (UTC)

There's a semi-notorious site http://hanzismatter.blogspot.com/ which has exposed many blunders in the past... AnonMoos (talk) 16:28, 1 July 2012 (UTC)

P.S. You could always contact the "shadowcatcherimagery" site and ask them to relicense. AnonMoos (talk)`

File:Tattoo U+6A02.jpg

I don't know whether that image is copyrightable in that particular form or not, but we both know that the source isn't "vintage"[sic]. As explained in earlier -emails, it's from a photograph taken by one of the people responsible for the http://www.shadowcatcherimagery.com website (in 2001 or slightly before), though the photograph was not downloaded from the website. It would be cutting fewer corners to follow my suggestion above to ask the people at that site whether they would relicense the photograph(s) under a free license... AnonMoos (talk) 15:21, 23 September 2013 (UTC)

One year ago, shadowcatchers didn't answer my question. Depending this file, I believe that just the character without anything else from the photography, not showing all the photographical artwork, hopefully will not infringe the copyright, and the copyright for the character 樂 only is covered sufficiently by PD-Unicode. I do not feel completely well either, and I would much prefer to get the permission to show more of the picture. I am thinking of giving it another try and to contact shadowcatchers again.

Thank you for completing so neatly the file description. sarang♥사랑 09:51, 24 September 2013 (UTC)

I sent shadowcatchers again a mail 24 September 2013 - no reaction. sarang♥사랑 08:50, 14 October 2013 (UTC)

File:Mars symbol.svg

Guten Tag,

Es gibt ein problem mit den Bild Mars symbol.svg. Es gibt den richtigen symbol ♂ nicht mehr ; anstatt sehe ich eine schwarze geometrische Figur mit eine Kurve, zwei Strecke, und drei Ecke.

Deshalb stelle ich mich die Frage, um eine ältereres Version dieser Bild wieder zu machen.

Ich hoffe dass meine Deutsche Sprache genug gut ist. Verzweifeln Sie nicht, mich zu korrigieren.

Danke schön >^w^<

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Good afternoon,

There is a problem with the picture Mars symbol.svg. The ordinary symbol ♂ doesn't appear anymore; instead of it, a plain black shape with two sides, one curve, and three vertexes.

This is why I ask myself a question: why not displaying an older version of this file.

I hope my German (and my English) are good enough; don't hesitate to correct me.

Thank you >^w^<

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

KiwiNeko14 (talk) 12:36, 16 October 2012 (UTC)

Merci beaucoup, KiwiNeko14, for telling me about this problem. It is caused by a well known librsvg bug and is now repaired by a workaround. Maintenant Mars symbol.svg:  est comme tu veux. Je regret; désolé mon français n'est pas bon. sarang♥사랑 17:44, 16 October 2012 (UTC)

Kein problem Sarang, ich habe dich verstanden! Jetzt funktioniert es super, danke sehr! Guten Abend

KiwiNeko14 (talk) 18:50, 16 October 2012 (UTC)

Inzwischen ist der Bug auch generell gefixt , siehe Bugzilla:31122 (live on 24.10.12) -- Perhelion (talk) ℗ 16:39, 29 October 2012 (UTC)

Being open is what the missing height happened (is this correct English?). De: Wobei offen ist was mit dem fehlenden height passiert (sieht schon etwas kurios aus, der Renderer macht daraus ein width="31" height="31"!?). -- Perhelion (talk) ℗ 08:13, 30 October 2012 (UTC)

Ganz generell scheint bei fehlenden width/height 512x512 genommen zu werden, zB wenn statt den beiden Angaben nur eine viewBox angegeben ist.

Offline wird bei nur width dieselbe height genommen,also ein Quadrat; mit dem librsvg gibt das dann Probleme, je nach der gerenderten Grösse. Bei solchen Variationen ist oft offline ok, nicht hingegen was dann in Wiki gezeigt wird. sarang♥사랑 10:01, 30 October 2012 (UTC)

My favorite SVG file ever!

See File:Double optical illusion.svg... -- AnonMoos (talk) 20:19, 29 November 2012 (UTC)

Commons:WikiProject BSicon

You are invited to join Commons:WikiProject BSicon‎. Useddenim (talk) 19:44, 21 July 2013 (UTC)

Sq3_bluewhitegreen

Think it was just a caching problem; I purged and reloaded, and it looks fine for me now... AnonMoos (talk) 13:42, 26 July 2013 (UTC)

Template linking templates

Hi Sarang,

I noticed you're putting effort into cleaning up the existing template linking templates and extending their functionality. Kudos for this!

However did you read my comment here? I assume en:Template:tlg has already all the functionality you might want to implement in Template:Svtest plus much more (e.g. it already easily handles Interwiki-linking of templates, linking to arbitrary namspaces, etc).

I'd recommend to just import it here (as per my comment I mentioned) and built upon it's functionality instead of reinventing the wheel for Commons. This way future improvements can also quickly be applied on Commons and on enwiki. What do you think? --Patrick87 (talk) 09:51, 1 August 2013 (UTC)

Hi Patrick, deinen Beitrag habe ich sehr wohl entdeckt und gelesen. Gleichwohl halte ich die Importierung von {{Tlg}} nicht für das Allheilmittel um diesen Vielfaltwirrwarr an template-templates aufzuräumen. "Tlg" ist ein sehr mächtiges Instrument, das aber einem etwas anderen Konzept folgt. Es ist sehr einfach, damit auf die Parameter einer Vorlage hinzuweisen, alles andere ist aber recht umständlich. Insbesondere hat Commons einen gewissen Standard für interwiki-templates bezüglich der Parameter 1=, 2= und 3=; es kann diskutiert werden ob dafür zusätzlich noch benannte Parameter (in diesem Fall wohl alttext und language eingeführt werden sollten, manche bevorzugen das. Einige tlg-Parameter (code, bold, italic) lassen sich weitaus einfacher codieren, zB mit ''{{tl|example}}'' oder als {{tl|example|''example''}} — wobei nichts dagegen spricht, es auch als Vorlagenparameter anzubieten. Ein eventueller bot-Lauf könnte so etwas auf beiderlei Arten umstellen. IMHO wäre es sicher am sinnvollsten, eine einzige Vorlage zu haben, am besten wohl als {{Sarang}}, mit allen Parametern.
Praktikabel wird es am ehesten sein, zwei Vorlagen zu haben, eine wie {{Sarang}} mit den unbenannten (aber auch benambaren!) Parametern für Displayname und Language, die andere zB {{Tp}} verwendet alle unbenannten Parameter 2 bis ∞ zur Aufzählung der Vorlagenparameter. Eine Fülle von benannten Parametern, bei den beiden Vorlagen identisch, erlaubt alle beliebigen Formatierungen. So sind Parameter in beiden Vorlagen mit parm= als ein komplexer Textstring, aber auch mit par1=, par2= etc. einzeln darstellbar. Beide Vorlagen würden sehr viel Code enthalten, deshalb wäre es vielleicht besser dass beide nur ihre Parameter an eine Supervorlage übergeben, die dann alles macht.
Es liefe darauf hinaus, dass mehrere sehr einfache Vorlagen durch eine überaus komplexe Vorlage ersetzt werden, und die sehr einfachen Vorlagenaufrufe in sehr vielen Fällen dann die leistungsfähige zentrale Vorlage aufrufen, ohne irgendwelche Werte für die zahlreichen Parameter zu übergeben.
Was hältst du davon? Wollen wir uns dafür aus dem Fenster lehnen? Und das ganze mal an der entsprechenden Stelle formulieren? Gruss, sarang♥사랑 07:38, 2 August 2013 (UTC)

Ganz ehrlich muss ich sagen, dass ich davon nicht viel halte. Die von dir vorgeschlagene Vorlage mit drei unbenannten Parametern für Vorlage/Alternativtext/Sprache würde das "Vielfaltwirrwarr" wie du es selbst nennst nämlich noch deutlich verschlimmern. Bist du dir sicher, dass es diese Variante auch noch braucht und ein einfacher "lang" Parameter nicht ausreicht (falls überhaupt nötig, schließlich kann man bei "tlg" einfach per Sprach-Prefix verlinken - auch zu anderen Projekten was bei deinem Vorschlag nochmal einen Parameter erfordern würde)? Aus meiner Sicht sprechen sogar einige Dinge dagegen:

• Zunächst mal wird ohnehin eher selten zu anderssprachigen Wikipedias oder gar zu anderen Projekten verlinkt. Wenn man das wirklich will, warum nicht einfach mit Prefix (oder von mir aus auch lang-Parameter)?
• Bis heute ist die Interwikifunktionalität in den meisten Vorlagen gar nicht vorhanden. Es scheint also kein großer Bedarf zu bestehen. Die Funktion per Parameter nachzurüsten sollte also mehr als genügen.
• In der englischen Vorlage habe ich den "lang" Parameter sogar ganz entfernt – weil er überhaupt nicht benutzt wurde. (Ich vermute aber mal, dass der Bedarf auf Commons nach Interwikilinks etwas höher sein würde).
• Die von dir vorgeschlagene Version ist von vornherein limitiert was Parameter angeht. Man kommt also, trotz der noch größer werdenden Vorlagenvielfalt, nicht darum sich mehrere Vorlagen zu merken.
• Auch der Alternativtext wird so gut wie nicht benutzt. Schlussendlich ist er fast nur in Kombination mit Interwikilinks nützlich oder für Vorlagen im Benutzernamensraum (um den Namensraum zu "verstecken").

Ganz grundlegend würden mir persönlich zwei Vorlagen genügen (den ganzen Formatierungsmist halte ich ohnehin für unnötig), so wie in der deutschen Wikipedia: {{tl}} zur verlinkten Verwendung und {{tnl}} zur Erklärung der Vorlagenverwendung ohne Verlinkung oder bei mehrfacher Verwendung im Fließtext. Aber das werden wir hier kaum durchsetzen können, deshalb war mein persönliches Ziel die Vorlagenverwendung so gut wie möglich zu vereinheitlichen (mit gleichen Parametern, identischer Funktionalität und sinnvollen Namen)... und dem läuft dein Vorschlag leider ziemlich entgegen.

Ich würde mich freuen, wenn wir da eine sinnvolle Lösung finden könnten um das Wirrwarr etwas zu entwirren. Wenn wir zwei uns schon nicht einig sind brauchen wir glaube ich auch noch gar nicht daran denken irgendwas irgendwo zu formulieren. --Patrick87 (talk) 18:56, 2 August 2013 (UTC)

Die unbenannten drei Parameter sind ein in den Commons verbreiteter Standard, und in Vorlagen wie {{C}}, {{F}}, {{U}}, {{W}} und nun auch in {{U}} realisiert. Ich will keine weiteren Vorlagen, im Gegennteil, doch habe ich die drei Vorlagen {{Sarang}}, {{Sarang}} und {{Sarang}} einheitlich von einem auf drei unbenannte P. erweitert. Natürlich wird der 2. kaum, und der 3. Parameter noch weniger benützt; die Erweiterung ist mehr eine Anpassung an diesen erwähnten Standard.

Es wäre bereits jetzt möglich, {{Sarang}} und die sehr frequentierte Vorlage {{Sarang}} per bot auf {{Sarang}} umzustellen, oder aber zwei davon so zu reduzieren, dass sie nur mehr mit ihren Parametern die 3. aufrufen; so eine Verschachtelung brächte keinen direkten Vorteil, ausser dass als Endziel nur mehr eine Vorlage zu pflegen wäre.

Template:HandSVG als Autorinformation

Hi Sarang,

du bestückst gerade ein paar SVGs mit {{HandSVG}}, danke dafür! Allerdings ist mir aufgefallen, dass du im {{Information}} Template das "author" Feld mit dieser Vorlage ersetzt.

{{HandSVG}} enthält zwar ebenfalls einen Link zum Autor wenn man es richtig einsetzt, allerdings glaube ich, dass das trotzdem keine gute Idee ist:

• Die Vorlage sagt zunächst mal etwas über den Inhalt der SVG aus, enthält die W3C Info-Vorlage, etc. Das hat alles nichts mit dem Autor zu tun und gehört somit auch nicht ins "author" Feld.
• Bei den CC-Lizenzen wird oftmals empfohlen den Autor "so wie im "author" Feld angegeben" zu zitieren, wenn nicht anders angegeben. Zum einen lässt sich diese Empfehlung so dann natürlich nicht mehr anwenden, zum anderen veränderst du diese Information (worüber der ursprüngliche Autor eventuell nicht glücklich ist).
• Ein Laie, der über diese Vorlage stolpert, kann damit wahrscheinlich nichts anfangen. Er kapiert vielleicht gar nicht, dass hier tatsächlich auch der Autor der Datei angegeben wird (was bei einem einfachen Wikilink hingegen offesichtlich sein sollte).
• Oftmals wird ein SVG von einem anderen Benutzer erstmals optimiert oder noch weiter optimiert, nachdem es der ursprüngliche Autor hochgeladen hat. Das SVG ist dann natürlich trotzdem ein {{HandSVG}}, allerdings hatte der ursprüngliche Autor damit ja nichts zu tun.
• Maschinenlesbarkeit: Wenn ich im "author" Feld nach einem Wikilink suche, habe ich wenn eine Vorlage verwendet wird schlechte Karten. Zugegeben ein schwaches Argument, da öfters Vorlagen im "author" Feld verwendet werden, aber sollte man trotzdem nicht ganz aus den Augen verlieren.

Meiner Meinung nach sollten Autor und die {{HandSVG}} Infos strikt getrennt bleiben. Das eine hat mit dem anderen schlicht nichts zu tun. Die Möglichkeit überhaupt einen Autor anzugeben ist in meinen Augen bereits zweifelhaft, denn grafischer Inhalt und Dateiinhalt in der SVG sind wie du selbst weißt zwei völlig unterschiedliche Dinge. Der Autor im {{Information}} Template bezieht sich auf den grafischen Inhalt, der Autor in {{HandSVG}} auf den Dateiinhalt. --Patrick87 (talk) 12:04, 3 August 2013 (UTC) P.S. Habe dir auf meiner Disussionsseite geantwortet.

Welcome, Dear Filemover!

---

Hi Sarang, you're now a filemover. When moving files please respect the following advice:

• Use the CommonsDelinker link in the {{Rename}} template to order a bot to replace all ocurrences of the old title with the new one. Or, if there was no rename-request, please use the Move & Replace-tab.
• Please leave a redirect behind unless you have a valid reason not to do so. Other projects, including those using InstantCommons, might be using the file even though they don't show up in the global usage. Deleting the redirects would break their file references. Please see this section of the file rename guideline for more information.
• Please know and follow the file rename guidelines.

--Steinsplitter (talk) 07:37, 5 August 2013 (UTC)

Es ist empfehlenswert sich eine Benutzerseite anzulegen, oder wenigstens eine Weiterleitung auf die Disk. Danke.--Steinsplitter (talk) 07:38, 5 August 2013 (UTC)

Statistics

Statistics
Files:	110,803,547
Page total:	145,732,988
User total:	13,048,843
Active users:	37,689

Commons:Requests for comment/How Commons should deal with TemplateData

Hallo Sarang, I würde gern wissen, ob Du in Zukunft TemplateData lieber per JSON eingeben willst oder dazu gern Vorlagensyntax benutzen möchtest. Danke für Deine Zeit. Beste Grüße Rillke^(q?) 18:53, 28 August 2013 (UTC)

Hallo Rainer, bisher wusste ich nichts von der JSON-Möglichkeit. Ich möchte gerne auf effiziente Weise gute und brauchbare (also ebenfalls effizente) Dateien erstellen; das betrifft auch templates. Somit werde ich mich damit auseinandersetzen, und demnächst nach Infos suchen. Danke für deinen Hinweis. sarang♥사랑 05:56, 29 August 2013 (UTC)

TemplateData ist lediglich für die Beschreibung von Vorlagen. -- Rillke^(q?) 08:10, 29 August 2013 (UTC)

Ich blicke noch nicht recht durch. Die Beschreibung (documentation) von Vorlagen soll nicht über die {{TemplateBox}} erfolgen? sarang♥사랑 11:32, 29 August 2013 (UTC)

Es steht die Frage im Raum, ob wir weiterhin {{TemplateBox}} benutzen oder <templatedata>JSON code</templatedata> direkt auf die Vorlagenseiten schreiben. {{TemplateBox}} kann auch TemplateData exportieren (- das passiert im Hintergrund -); alles was man dazu machen muss, ist {{TemplateBox}} den Parameter |useTemplateData=1 zu übergeben, dann exportiert es TemplateData, welches von Tools wie UploadWizard benutzt werden kann. -- Rillke^(q?) 11:51, 29 August 2013 (UTC)

Du hast sicher ein Beispiel, wie so was aussieht, und was da zu editieren ist? sarang♥사랑 17:32, 29 August 2013 (UTC)

Konstruierte Beispiele sind auf Commons:Requests for comment/How Commons should deal with TemplateData#Make the test - What are you more comfortable with?.

Real-world-Beispiel ist Template:Information (Template:Information/doc [diese Unterseite wird in die Vorlage als Vorlagendokumentation eingebunden; TemplateData momentan unter der Parametertabelle; das Output können wir aber beliebig ändern] vs. Template:Information/sandbox/TemplateData [TemplateData direkt auf der Vorlagenseite]) -- Rillke^(q?) 17:49, 29 August 2013 (UTC)

Danke — einstweilen, ich sehe es mir an sarang♥사랑 06:33, 30 August 2013 (UTC)

Category:Chinese_glyph_tattoos

Category:Chinese_glyph_tattoos 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!

Brainy J (talk) 18:07, 30 August 2013 (UTC)

Katalanische Esteladas

Hi Sarang. Vielleicht könntest du mal diese beiden Esteladas - Estelada blava.svg, Estelada roja.svg - entrümpeln, bevor es jemand macht, der dabei den Stern wieder nach oben dreht. Grüße, mate2code 17:34, 16 September 2013 (UTC)

 Done und auch gleich Estelada blava vertical.svg:  07:21, 17 September 2013 (UTC) Gruß sarang♥사랑

File:2-d dense packing r4.svg

I've reverted your change sorry. If you view both versions at full scale in your browser, you will see that they are slightly different, such that your circles slightly overlap. Unfortunately this is not good enough for a packing diagram. --99of9 (talk) 06:46, 10 October 2013 (UTC)

Thank you. I've changed the size of the small circles. This can be done even more, if desired, any fractions of 0.001 px or whatever, without increasing the size to 52 KB; ½ KB is enough to do that. If you compare it to the 52 K version, you may see that the small circles are now a bit better centered in the gaps between the large circles.

It would be possible to remove also all the superfluous Inkscape coding from all the other circle packing pictures, but IMHO this example is enough for the moment. If you want some more corrections, please just let me know. sarang♥사랑 07:34, 10 October 2013 (UTC)

File:Symbol LED.svg

Hello. I’ve corrected the syntax errors you introduced here. I just wanted to ask, if this was kind of a automatic replacement process, so did you do this change to many other files? If so, could you correct them? If not: How could that happen? ;-) Erik Streb (talk) 18:42, 13 October 2013 (UTC)

Hallo Erik, nix automatic, war nur ein dummer Fehler, rein manuell. Dank für deine Korrektur sarang♥사랑 07:39, 14 October 2013 (UTC)

SimplSVG

Okay, ty for the post. I will take a look at it, later on. Regards, Citypeek (talk) 07:50, 15 October 2013 (UTC)