Template talk:AutVec
This depends rather Templates for discussion but such a forum seems not to exist.
Unsuitable templates
[edit]Often the mere vectorization of a raster graphic is tagged either with
- Retouched picture naming the raster file and the converting editor
- Derived from naming the raster file; maybe naming its author in same or another line
In my opinion none is the best way; converting is neither equivalent to retouching nor to deriving.
Retouching means rather an alteration of the appearance, but do not comprise changing the file type while showing the same;
Deriving means rather creation of something new by using parts or ideas of the original, but not drawing a reproduction in SVG.
For mere conversions to SVG exists another and better appropriate template,
- AutVec ("authors of vectorized raster graphic") naming
- the author of the originating raster (if known),
- the author of the resulting vector,
- the name of the raster file (optional).
This template is intended to be used in the |author=
line of the description of the SVG file.
If useful, the template can as well categorize into an appropriate category about vectorization:
- {{Retouched}} categorizes to Retouched images, {{Derived}} doesn't;
- if desired the template can categorize to e.g. "Vectorized images" or so.
sarang♥사랑 10:58, 6 February 2017 (UTC)
(moved from User talk:Sarang#Template:AutVec)
Hallo Sarang, ich benutze dieses Template nun auch, evtl. würde ich es sogar (irgendwie und wenn es erst nur mal ein extra Button ist) ins simpleSVGcheck aufnehmen. Allerdings finde ich das Grün viel zu hervorstechend, ich empfehle hier das Titel-Blau der normalen Information oder ein Grau. Desweiteren ist mir negativ aufgefallen dass der Original-Autor ein Wikilink sein muss, das ist in den seltensten Fällen der Fall. Wenn es noch geht würde ich daher die Funktion des "o"-Paramter vertauschen. LG ↔ User: Perhelion 08:15, 8 September 2016 (UTC) ↔ User: Perhelion 08:24, 8 September 2016 (UTC)
- Farbe in #ccf zu ändern ist kein Problem, kannst du schnell machen, oder ich mach es. Auch die O-Vertauschung ginge noch, es hat bisher erst 51 Einbindungen, und viele sind ohnehin default-unknown. Ev. sollte die Vorlage {{Unknown}} in {{Unknown|author}} oder {{Unknown author}} geändert werden?
- Allerdings sind in vielen anderen Vorlagen (wie Attrib, Retouched) die unbenannten Parameter ein WikiUserLink, und die benannten ohne. Es wäre auch kontraproduktiv, wenn der 2. Autor das "v=" braucht, denn der ist ja praktisch immer ein CommonsUser (nur Editoren ohne user page müssen das "v=" für Ut oder dgl. nehmen, um den redlink zu vermeiden). Ich verstehe deinen Wunsch, bin aber von der Variante dass der Stellungsparameter kein Wikilink sein sollte (und stattdessen der Wikilink einen Parameter braucht) nicht so angetan.
- Wenn die ggf. etwas höhere Serverlast keine Rolle spielt schlage ich folgende Lösung vor:
- mit "o=" wird ohne Autolink verfahren - natürlich kann auch
|o={{u|perhelion}}
geschrieben werden.... - ohne "o=", bei unbenanntem Parameters 1, wird nun eine Existenzprüfung durchgeführt auf Usernamen; bei Nichtvorhandensein auch noch auf UserTalkPage. Wenn einer von beiden vorhanden ist wird dorthin verlinkt, sind beide nicht vorhanden wird einfach ohne Link angezeigt. Diese (ev. sogar doppelte) Existenzprüfung kann vermieden werden:
- mit dem neuen Parameter "u=" kann ein linkbarer Username angegeben werden, der nicht geprüft wird - schlimmstenfalls wird das nun doch ein redlink.
- wenn das 1. Zeichen des unbenannten Parameters 1 ein "{" oder "[" ist wird er ohne Existenzprüfung genommen.
- mit "o=" wird ohne Autolink verfahren - natürlich kann auch
- Es gibt also nach wie vor das ungeliebte "o=", allerdings optional; neu wird dass der Wikilink auch ohne "o=" unterbleibt wenn die Existenzprüfung negativ ausfällt.
- Das erscheint mir eine akzeptable Lösung; leider wird wieder mal eine Vorlage etwas komplexer und die Beschreibung ebenfalls. sarang♥사랑 11:03, 8 September 2016 (UTC)
- Hm* naja, so ein “Zwischending” ist jetzt auch nicht das Wahre (von mir aus kannst du das auch wieder entfernen). Wenn ich's mir recht überlege, kann man sich auch an das "o=" gewöhnen (zumal es bei mir ja dann eh per Button oder Script eingefügt werden wird :P). Na dann werde ich nur die Farbe ändern. LG ↔ User: Perhelion 21:44, 8 September 2016 (UTC)
- Gut, es bleibt ohne die Existenzprüfung. Nur so als Annehmlichkeit habe ich die Abfrage auf "{" und "[" eingebaut, so dass bei manueller Eingabe das "o=" bzw. "v=" in diesen Fällen nicht unbedingt getippt werden muss. Wie es auch dokumentiert ist. sarang♥사랑 08:31, 9 September 2016 (UTC)
"Original"?
[edit]The template shows the two fields "Original" and "Vector".
Considering the fact that the vectorization creates the vector as the now new original, obsoleting the old raster image, it seems not such a good idea to call the obsoleted image the "original". It might be more adequate to call the old image e.g. "raster" or something else, instead to give it the high value of being the original, somehow devaluating the vector image. -- sarang♥사랑 17:54, 23 August 2019 (UTC)
- I changed it to "Bitmap". If you dislike it, just undo it! -- sarang♥사랑 08:02, 5 September 2019 (UTC)
- Bitmap is somehow unlucky as it seems an old unusual term for an sub-part of the more general Raster graphic, it collides also with some synonyms like the Windows bitmap format or Binary image. May I prefer instead Origin(ation) for Original. May we should ask again a native speaker with a bit IT knowledge. PS: Raster VS SVG -- User: Perhelion 16:52, 5 September 2019 (UTC)
- The short term Origin seems to me much better, just saying where it comes from, without an evaluating undertone. I can generate a Template:I18n/origin, so for the languages where the "vector" is nationalized also the "origin" should be. -- sarang♥사랑 06:23, 6 September 2019 (UTC)
- Bitmap is somehow unlucky as it seems an old unusual term for an sub-part of the more general Raster graphic, it collides also with some synonyms like the Windows bitmap format or Binary image. May I prefer instead Origin(ation) for Original. May we should ask again a native speaker with a bit IT knowledge. PS: Raster VS SVG -- User: Perhelion 16:52, 5 September 2019 (UTC)
I don't know that I have any particular insights into the semantics of "origin". Maybe "raster" as an alternative to "bitmap"? AnonMoos (talk) 19:16, 11 September 2019 (UTC)
- I'm now against the changes, as this template should reflect mainly the copyright issue. The term "original" represents also a adjective, so this should be the best term for the time being. A "conversion" makes also not a new original, the obsoleting aka superseding was also formerly mainly discouraged. The main scope of Commons should be similar to Wikipedia in the view of WP:No original research.
- PS: so the German translation is not fully fitting and maybe we should remove the ucfirst.
- PPS: To be more clear, e.g. emblems: the authors are often more than 200 years dead, they have nothing to do with fileformats (the long time predecessor of this template has used {{Vectorization}}, not a fileformat). -- User: Perhelion 12:55, 16 September 2019 (UTC) -- User: Perhelion 14:00, 16 September 2019 (UTC)
- Your arguments convinced me. I am agreeing, and will remove my tries. -- sarang♥사랑 07:04, 17 September 2019 (UTC)
- PS: (lcfirst of German translation): As long as the right side tells "Vektor", as a short form for "author of the vectorized version" with ucfirst, IMHO an lcfirst of "Original" won't be so adequate. It may look less disturbant if you see it as kind of beginning of a sentence? -- sarang♥사랑 08:25, 17 September 2019 (UTC)
- Thanks, indeed, the
ucfirst
can be left standing. Maybe we should take for the German translation "Ursprünglich"!? -- User: Perhelion 08:53, 17 September 2019 (UTC)
- Thanks, indeed, the
- Rather Oppose: German users are not so stupid that they won't understand what "Original" means; and a word too long does not fit into a well looking layout of the template. Let it be 'Original' and 'Vektor', even for de. -- sarang♥사랑 17:35, 17 September 2019 (UTC)
Table problem?
[edit]- (moved from User talk:Jarekt/archive)
Hi Jarek, some days ago we talked about the boxes realized with wikitable, which made problems. AFAIK there are at least three possibilities to display such a box. Old fashioned is the wikitable method – among many others the {{Created with}} (transcluded > 1Mio, often multiple times in one file description) uses it.
After the troubles with the {{AutVec}} I converted it from wikitable to the <div>/<span> method, and it works fine. Others, e.g. {{Mbox}} use the <table> method.
I do not know which will be the best method; but I suppose that <span> cannot be bad? Do you think that I should convert the {{Created with}} – or not touch it, because it works since many years? Of the very similar {{Taken with}} (wikitable) I made a sandbox version with the <span> method. But I cannot estimate whether that will be preferable. -- sarang♥사랑 17:21, 16 November 2019 (UTC)
- sarang, Not long after the issue was discovered, someone come up with the solution (add \n before and after each field) and that was quickly deployed. That solution had some unpleasant side-effects (extra space around fields and some downstream tools not working right), so we figure out the fixes to those. I will try to deploy it this weekend. So I would not worry about template conversion, as it is no longer necessary. --Jarekt (talk) 23:47, 16 November 2019 (UTC)
- I understood the problem – the “{|” for wikitables needs to start at a new line; and I saw the solution and the suggestion by Tacsipacsi. My questions are:
- will it be useful, or worth the effort, to converse existent boxes? I understand that your answer is "no".
- when new boxes are needed, how should I write them - which method will be the best one?
- Ok, I will wait what you are working out for that theme. Thank you -- sarang♥사랑 07:58, 17 November 2019 (UTC)
- The new templates with tables, I would write using html tables. That is how all infobox templates were written. --Jarekt (talk) 04:10, 18 November 2019 (UTC)
- Thank you. I will do it when new boxes are needed -- sarang♥사랑 10:06, 18 November 2019 (UTC)
- The new templates with tables, I would write using html tables. That is how all infobox templates were written. --Jarekt (talk) 04:10, 18 November 2019 (UTC)
- I understood the problem – the “{|” for wikitables needs to start at a new line; and I saw the solution and the suggestion by Tacsipacsi. My questions are:
Extension for automatic cat
[edit]many users extend the Filepage with hidden (or not) cats "made by XY, created by XY" etc. shouldn't be it easier to extend the template like
[[:User:|{{{1}}}]] --> [[Category:File create by {{{1}}}] {{u|{{{1}}} }}
That would able to remove the everytime repeated cats. -- Gunnar (💬) 14:18, 20 November 2019 (UTC)
- Es gibt auch sichtbare Kategorien für den jeweiligen entwerfenden Heraldiker. So etwa Coats of arms by Carl Teske bei File:DEU Bad Doberan (nach Treske) COA.png. Es wäre doch praktisch nicht mehrfach diese Zuordnungen als Kategorie schreiben zu müssen, so wären sie automatisch einsortiert. -- Gunnar (💬) 01:06, 23 November 2019 (UTC)
- Liesse sich leicht machen, aber es sollte nicht automatisch immer so kategorisiert werden. Und welche nun die gewünschte Kategorie ist, "Made by", "Created by", "Drawn by", "Bilder von", "Images drawn by", "Heraldry by", "CoAs by" — es gibt unzählige Variationen! Dein Vorschlag "File create by" ist eine weitere.
- Entweder wird da was standardisiert, oder es muss irgendwie der Vorlage mitgeteilt werden, was denn nun sein soll. -- sarang♥사랑 11:29, 22 August 2020 (UTC)
Because unknown authors/artists came always into the respective maintenance category, the template sets now the option "nocat" when {{Unknown}} is requested. -- sarang♥사랑 11:29, 22 August 2020 (UTC)
Responsive
[edit]Hi, I tried a few changes to the layout in the sandbox, the main reason being a poor layout on smaller screens and in the Media Viewer. There was a standard width that prevented the labels from wrapping, so I removed that. I removed the {{{width}}}
parameters altogether since they are redundant now. Spaces are added between spans, because else there isn't any space shown in the Media Viewer on mobile. Any remarks? --Strepulah (talk) 14:12, 17 February 2022 (UTC)