User talk:Glrx

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
Welcome to Wikimedia Commons, Glrx!

Contents

Tip: Categorizing images[edit]

Afrikaans | العربية | беларуская (тарашкевіца)‎ | català | čeština | dansk | Deutsch | Deutsch (Sie-Form)‎ | Ελληνικά | English | Esperanto | español | فارسی | suomi | français | galego | עברית | magyar | íslenska | italiano | 日本語 | ქართული | 한국어 | македонски | മലയാളം | Plattdüütsch | Nederlands | norsk | polski | português | português do Brasil | română | русский | slovenčina | slovenščina | српски / srpski | svenska | українська | Tiếng Việt | 中文 | 中文(简体)‎ | 中文(繁體)‎ | ಕನ್ನಡ | ತುಳು | +/−


Hello, Glrx!
Tip: Add categories to your images

Thanks a lot for contributing to the Wikimedia Commons! Here's a tip to make your uploads more useful: Why not add some categories to describe them? This will help more people to find and use them.

Here's how:

1) If you're using the UploadWizard, you can add categories to each file when you describe it. Just click "more options" for the file and add the categories which make sense:

Uploadwizard-categories.png

2) You can also pick the file from your list of uploads, edit the file description page, and manually add the category code at the end of the page.

[[Category:Category name]]

For example, if you are uploading a diagram showing the orbits of comets, you add the following code:

[[Category:Astronomical diagrams]]
[[Category:Comets]]

This will make the diagram show up in the categories "Astronomical diagrams" and "Comets".

When picking categories, try to choose a specific category ("Astronomical diagrams") over a generic one ("Illustrations").

Thanks again for your uploads! More information about categorization can be found in Commons:Categories, and don't hesitate to leave a note on the help desk.

CategorizationBot (talk) 10:53, 26 January 2011 (UTC)

Getting SVG valid[edit]

I wouldn't worry too much about making sure the SVG is valid. As long as it renders OK. The validator isn't smart enough to ignore stuff inside of the meta block. It also might have problems with how 'switch' blocks work.

Are you hand editing File:Ebola Outbreak 2014.svg or do you use some kind of program to generate it? Just curious. --Aflafla1 (talk) 02:55, 6 August 2014 (UTC)

One thing though - your svg file probably uses UTF-16 encoding. It's not UTF-8 in any case. (This appears in first line of the svg file) --Aflafla1 (talk) 02:59, 6 August 2014 (UTC)

The validator found some legit errors: the attribute is viewBox (not viewbox); title and desc apparently may not have conditional attributes. The metadata block seems hopeless, but I had thought it was finding some RDF. The bad part is its: is not recognized.
I'm hand editing the file. I was going to use a program to output the data, but I settled on a simple enough transform (2 pixels per day, 0.1 pixels per case) that hand editing works. When I started adding translated short day names, then I wished I was using a program (it could generate short month names by changing locale).
The file is UTF-8, but it starts with a BOM to tell the editor it is UTF-8 rather than ASCII.
The bottom line: it is a crazy way to generate a diagram. It does educate me a bit more on localization/internationalization. Glrx (talk) 03:23, 6 August 2014 (UTC)
PS. Log() is the way to go if the numbers go much higher. Glrx (talk) 03:30, 6 August 2014 (UTC)

Ebola translation to galician[edit]

Don't worry, I have fixed it :) Bye, --Elisardojm (talk) 17:09, 6 August 2014 (UTC)

The only fix is that for month "May" you have to add "Mai" for galician language (gl). Thanks!, --Elisardojm (talk) 17:48, 6 August 2014 (UTC)
I think that the file is ok, if I notice any problem I'll notify to you :) Thanks! --Elisardojm (talk) 17:58, 6 August 2014 (UTC)
I find a little typo in galician translation, month August, "Aug", is "Ago" in galician (gl). Bye, --Elisardojm (talk) 22:49, 6 August 2014 (UTC)
Don't worry :) I have found now another typo in galician translation...O:) Month September is "Set". Bye, --Elisardojm (talk) 12:36, 7 August 2014 (UTC)
Fixed. Glrx (talk) 15:42, 7 August 2014 (UTC)

Derivative files of File:Parts of a shark.svg[edit]

You have just declined a series of file moves that I requested that relate to File:Parts of a shark.svg.

The practice for SVG translations is to suffix the original filename with IETF langtag. See Help:Translation tutorial#Using a separate file. That practice would keep the related files together with only a small change to file name.

PS: There were two errors in my requests. First, a suffix should have been "es" rather than "en"; second, one file is a PNG rather than SVG.

Glrx (talk) 18:38, 17 March 2017 (UTC)

Hello Glrx. I'm aware about the SVG practice translation, I do it myself when I create a set of maps in different languages.
Here, I refused your requests because of the criteria to decline #2. "there's no reason to favor English over other languages.". If the uploader chose to name the file in its own language, you have not to modify it, even to suffix the original filename.
Sémhur (talk) 20:43, 17 March 2017 (UTC)
@Sémhur: There is not a reason to favor en, but that does not mean another reason may not take precedence. My citation for the move was number 5 - keeping a group of files together. If the original illustration were in Spanish, then all of the derivatives should keep the Spanish root. If there's only one file (e.g., Haus.png), then it should not be renamed to en (e.g., House.png).
In the longer view, I've been crawling through many files, and I've stumbled across renamed derivative files that do not attribute the original file. In the File:Parts of a shark.svg case it does not matter so much because it's PD, but even PD work should be attributed if only to help prove its PD nature.
Glrx (talk) 21:23, 17 March 2017 (UTC)

Image without license[edit]

File:Hilda Clayton explosion 2.jpg[edit]

беларуская (тарашкевіца)‎ | български | català | čeština | dansk | Deutsch | Deutsch (Sie-Form)‎ | Ελληνικά | English | Esperanto | español | فارسی | suomi | français | galego | hrvatski | magyar | íslenska | italiano | 日本語 | македонски | മലയാളം | Nederlands | norsk nynorsk | polski | português | português do Brasil | русский | sicilianu | slovenščina | svenska | українська | 中文(简体)‎ | 中文(繁體)‎ | +/−


There seems to be a problem regarding the description and/or licensing of this particular file. It has been found that you've added in the image's description only a Template that's not a license and although it provides useful information about the image, it's not a valid license. Could you please resolve this problem, adding the license in the image linked above? You can edit the description page and change the text. Uploading a new version of the file does not change the description of the file. This page may give you more hints on which license to choose. Thank you.

This message was added automatically by MifterBot (TalkContribsOwner), if you need some help about it please read the text above again and follow the links in it, if you still need help ask at the ? Commons:Help desk in any language you like to use. --MifterBot (TalkContribsOwner) 02:03, 4 May 2017 (UTC)

Reverting my edits without an explanation?[edit]

re File:Better Sample PDF417.svg

Hi there. I saw that you reverted my edits for the PDF417 barcode across all Wiki sites and languages. However, you didn’t leave an explanation, so I can’t understand why. Could you please explain your edits? FYI, I replaced the PNG with an SVG because SVG files are infinitely scaleable, higher quality, and usually smaller. Emmanuelsayshai (talk) 01:14, 8 September 2017 (UTC)

This issue was discussed on en.WP.
I included an explanation in this diff.
SVG is a better format for line drawings and some technical graphics, but that does not mean it is a good choice for all technical images. I don't think you understand why SVG can be good or the scaling issues of barcodes.
SVG is a horrible choice for a barcode image. Barcodes are not scalable in a trivial sense; the scale must be chosen so a module is an integer number of pixels. Consequently, barcodes are essentially bitmap images. Barcodes, when improperly scaled, have problems.
Compare: original PNG file is 808 bytes. Your SVG is 7kB and performs no better than the bitmap. SVG is a poor representation for barcodes.
I tried to remove the file on zh.WP, but failed.
I think your SVG should be deleted from Commons.
Glrx (talk) 03:03, 8 September 2017 (UTC)

File:SVG Test TextAlign.svg[edit]

File:SVG Test TextAlign.svg is below the c:Commons:Threshold of originality, therfore the file is public domain.

Please choose one of the following License (or a similar one):

{{Cc-zero}}
{{PD-ineligible}}
{{PD-shape}}
{{PD-self}}
{{PD-textlogo}}
{{PD-ancient-script}}
{{Bild-LogoSH}}
{{PD-font}}
{{PD-juggling notation}}
{{PD-sequence}}
{{PD-text}}
{{PD-Unicode}}

Otherwise I will revert your edit.

 — Johannes Kalliauer - Talk | Contributions 19:10, 22 October 2017 (UTC)

Says who? The SVG file is not pixels on a screen but rather a program that paints pixels. See w:Adobe Systems, Inc. v. Southern Software, Inc. where displayed font characters were not copyrightable but the code that produced the characters was copyrighted. Furthermore, the SVG displays differently on different user agents; it is not a static image. Glrx (talk) 19:44, 22 October 2017 (UTC)

Wikipedia renders just with free fonts. (public domain)
Public domain
The depicted text is ineligible for copyright and therefore in the public domain, because it is not a “literary work” or other protected type in sense of the local copyright law. Facts, data, and unoriginal information which is common property without sufficiently creative authorship in a general typeface or basic handwriting, and simple geometric shapes are not protected by copyright. This tag does not generally apply to all images of texts. Particular countries can have different legal definition of the “literary work” as the subject of copyright and different court's interpretation practices. Some countries protect almost every written work, while other countries protect distinctively artistic or scientific texts and databases only. Extent of creativeness, function and length of the text can be relevant. The copyright protection can be limited to the literary form – the included information itself can be excluded from protection.
PD-icon.svg
Unicode logo.svg
This image shows a character published by The Unicode Standard.
All graphic representations of Unicode characters are in the public domain.

বাংলা | Deutsch | English | español | français | italiano | македонски | മലയാളം | русский | 中文 | +/−

The source code is below the c:Commons:Threshold of originality (public domain). Text, and straight lines are definitely below the Threshold of originality.
Tell me anything which is above the Threshold of originality in File:SVG Test TextAlign.svg?
If you are unfimiliar to Threshold of originality you can see:
as a rough guideline.
I am a editor in de:Wikipedia:Grafikwerkstatt, ther we often have disscussion about c:Commons:Threshold of originality, f.e.: the last discussion in the german graphic lab about Threshold of originality was here: de:Wikipedia:Grafikwerkstatt/Archiv/2017/Unerledigt#Deutscher_Handballverband, with the result that de:Datei:Deutscher_Handballverband.svg is below the Threshold of originality. (I was the only one who doubt if it is below the threshold.)
I was involved in several discussions about Threshold, and File:SVG Test TextAlign.svg is without any doubt below the Threshold of originality.
 — Johannes Kalliauer - Talk | Contributions 21:19, 22 October 2017 (UTC)
(e/c)
That is not the issue in Adobe v Southern. In that case, it was a given that the image is not copyrightable.
I'm not sure that Deutscher Handballverband falls below the level of originality. The suggestion of a human throwing a ball is not a simple figure.
On en.WP it is forbidden to convert fair-use bitmap logos to SVG. Such logos are only available in SVG if company supplied the logo on its website.
Taking a bitmap image and running it through a bitmap-to-vector program should not make the resulting SVG a derivative work. Running a program does not require creativity.
Glrx (talk) 21:37, 22 October 2017 (UTC)
Sorry but I think you didn't get the meaning of Threshold.
Fair-use images shouldn't be uploaded on Wikimedia, independently bitmap or vector
If a bitmap is public domain you can run it through a bitmap-to-vector program and call it is your work.
If a bitmap is not public domain you have to be cautious of the license of the picture you used.
 — Johannes Kalliauer - Talk | Contributions 22:09, 22 October 2017 (UTC)
No, I understand threshold. Do you understand that threshold can be irrelevant? That is the whole point of Adobe.
Yes, I know that fair use images do not belong on Commons.
You may be able to call the conversion "your work", but does that work meet the threshold of originality? In the US, taking an accurate picture of a public domain work does not make a copyrightable derivative work. In some jurisdictions, the sweat of the brow can offer a copyright for such a mechanical copy, but if Igor in Transylvania can take the same PD bitmap, run it through the same program, and get exactly the same SVG file, then what does such a copyright say? It should not prevent Igor from publishing his SVG.
When was PD/non-PD bitmap an issue for me? I take most contributors at their word. If they claim CC-BY-SA 3.0, then I can vector convert their bitmap as long as I give them attribution. I'm untouchable. I am not trying, as you are trying, to strip contributors of their CC-BY-SA 3.0 claims. There is no need to do that on Commons. The images are free to use as long as the license terms are met. If, however, you wrongly delete someone's copyright claim, then you've done a copyright violation. I think it is clear that you don't understand Adobe, so you should not be stripping copyright claims. You are on dangerous ground. Even when somebody CC0's her work, it is still a good idea to attribute her. Glrx (talk) 22:32, 22 October 2017 (UTC)

RDF[edit]

You are also doing unreasonable edits to SVG files. You should not remove RDF. Removing spaces from path arguments makes them unreadable. Glrx (talk) 20:24, 22 October 2017 (UTC)

I make the SVG-files W3C-valid.
 — Johannes Kalliauer - Talk | Contributions 21:19, 22 October 2017 (UTC)
There is nothing W3C-invalid about SVG metadata. Removing attribution information is inappropriate. Glrx (talk) 21:52, 22 October 2017 (UTC)
I also removed several other invalid things, for example I changed the file size from 24kB to 8KB (now with RDF), see File:Globe_valve_diagram.svg.
RDF-Data makes the doctype svg invalid, see for example: https://validator.w3.org/check?uri=https%3A%2F%2Fcommons.wikimedia.org%2Fwiki%2FSpecial%3AFilepath%2FGlobe_valve_diagram.svg&ss=1
 — Johannes Kalliauer - Talk | Contributions 22:13, 22 October 2017 (UTC)
You need some basic knowledge about XML, DTD, SVG, and SVG recommendations. I won't ask for knowledge about schemas.
If you specify a DOCTYPE, then the document must follow that DTD. That means you need to include an internal subset for all the extensions (such as RDF metadata) or the document will not validate. The SVG DTD is overly strict with the metadata element: it does not allow any metadata. (BTW, MW does not like many internal subsets.)
If, however, you follow the recommendations for SVG and do not include a DOCTYPE, then the W3C validator will do the right thing and issue something like:
Line 26, Column 13: This validator does not validate RDF. RDF subtrees go unchecked.
for RDF metadata. It will also go easy on sodipodi markup.
That's what happened with the SVG before you touched it.
Validate previous
But if you tell the validator it must be the SVG 1.1 DTD, then everything blows up because there are no internal subsets for metadata or Inkscape markup.
Glrx (talk) 22:56, 22 October 2017 (UTC)

Sorry[edit]

After reading it again, I want to say sorry for my mistakes.  — Johannes Kalliauer - Talk | Contributions 18:30, 23 October 2017 (UTC)

Thanks. I am sympathetic with what you are trying to do. Many SVG files are horribly and needlessly oversize with Inkscape style nonsense. The files should be reduced in size. There are some SVG monsters out there. WM servers will not want to serve such large SVG files. You've just been too agressive. It would be good if you thought about what could be added to SVG files in addition to what should be taken out.
My guess is that User:Josve05a used scour or a similar program on File:History of the Universe-zh-hant.svg to reduce its size. I suspect that program (and not Josve05a directly) is responsible for the damage to the file.
I'll also guess that you are using some program to remove the extraneous commands. Yours seems more capable, but I'm not happy about its path argument compression. I hope that won't cause problems for DOM access. I've also been meaning to look at svgo and scour, but haven't gotten around to it. svgo seems to be an ad hoc tree walk. I expected to see something more along the lines of USE-DEF compiler optimizations.
Copyright is a problem on Commons. There are people who are claiming a copyright to material that should be public domain. That's a problem, but it is not a significant problem. I think it is unfortunate when an editor puts an SVG on Commons with a CC0 license, and then a second editor comes along, translates the file to his language, and then puts a CC-BY-SA license on his translation. I don't like that, but the guy may be entitled to do it. I won't fight it. Everybody can still use the translated file. The more significant problem is when somebody uploads a file and claims the file is PD, CC0, or CC-BY when it is not. Those are the serious copyright violations.
Thanks again, and good luck.
— Preceding unsigned comment added by Glrx (talk • contribs) 20:22, 23. Okt. 2017 (UTC)
Newbie
I think I can learn a lot from you. I'm just a newbie in SVG-Editing. (Then beginning of this year I did my first SVG-picture, after asking for a picture in the German Graphic Lab.)
Sorry
for being that aggressive in the discussion. (Even if I would have been right, there was no need to talk like I did, sorry.)
Valid
I thought Files reported in Commons:Commons_SVG_Checker#Checks should be W3C-valid without any warning.
I want to run a script on http://tools.wmflabs.org . It is now a bash-script which can be found in the German Wikipedia: de:Benutzer:JoKalliauer/Inkscape-SVG-Speichern#Automatisch
program to remove the extraneous commands
I use
Authorship
If I create a SVG based on a Rastergrafics I use {{AutVec|Origial Author|Johannes Kalliauer|Source.png}}
Otherwise I usually mention the original author only in the "|Source="-Field, and publish under a similar license; as here. Is it enough (if the original file would be under cc-by)? Or should I also mention the original Autor also under "Author"? (But the original Autor might not agree on the change, therefore adding as an Author might be also problematic.
I do not add metadata to SVGs, which I create, also it might be usefull.
copyright violations
I was absolutely convinced, that File:SVG Test TextAlign.svg is below the Threshold of originality, and yes I think I still didn't fully understand en:Adobe_Systems,_Inc._v._Southern_Software,_Inc.. Now I see the threshold of the file as not unambiguous, and therefore keeping the cc-by-sa is important, also I would publish such a file with {{PD-self}}.
 — Johannes Kalliauer - Talk | Contributions 19:13, 24 October 2017 (UTC)
Newbie
I'm also a newbie. I've done SVG more from the programming or text editor side rather than a graphic editor or image contributor. Commons has some impressive SVG images. There's a lot of talent out there.
Valid
  • Yes, I'd like SVG to W3C valid, but within limits. Extensions are not a problem if they are light weight. Unfortunately, SVG files seldom declare their extensions, so they will fail validation miserably. I read some SVG files with some Java code, and it was a disaster. The code would hang for 6 seconds and then throw an exception for an invalid file. I had to turn off three switches to read the file. I want to add some data-* attributes to some SVG files. If I make the SVG so it will W3C validate, then MW will refuse to upload it. On the flip side, I can make W3C valid SVG files that work on Commons but Chrome and Edge will botch. Validation is nice, but I will not insist on it.
  • I looked at your /bin/bash script, and it makes me nervous. I've never been a fan of string matching edits on structured files.
  • For example, <text>text-align="end"</text> is perfectly legal SVG.
  • Deleting the attribute text-align="end" may get rid of an error, but it also removes a hint at the intent of text-anchor="end"
  • CSS allows style='text-align:center'. The error isn't far wrong.
  • ARIA wants to be part of SVG. aria-label attributes are arbitrary strings. Such labels are used on text converted to path.
  • xml:space="preserve" is not useless and has meaning even in SVG 2.0 (even if MS ignores it).
  • stroke-width="1" may have meaning if set to something else above.
  • Don't add DOCTYPE to SVG. DTDs do not work well with namespaces. IIRC, SVG 1.2 gave up on making a DTD.
  • font-family="Sans" should become font-family="sans-serif"
  • yes, nested tspans are ugly.
  • ...
  • I'll look at the optimizers later
Authorship
Any image on Commons should be modifiable. WMF does not allow CC-BY-ND licenses.
I don't know the proper way to fill out the information box. That is an arcane art by itself. I've seen many ways of doing it, and some do not seem right. I'd give credit in the source field. AutVec seems good for the author field. If it is an automatic conversion, then the image has not changed much, so original author deserves to be there. I don't know what to do if there are significant changes. Overall, as long as credit is given reasonable prominence on the page, then CC-BY should be met.
RDF metadata should be included, but its form is not well settled yet. I think images on Commons should have cc:attributionURL pointing to the Commons file page or original source. The dc:Publisher should be Commons or the original publisher. Other fields should be filled out, too. The goal should be if somebody copies the SVG somewhere else, one can still look at the metadata and see where it came from. It would also help on Commons. I've seen SVG files copied from one place on Commons to another place with the license removed. Adobe has its recommendations, but I need to study that more. The Library of Congress has other recommendations. There are some other questions. Should a person be represented by a spelled-out name or a URL? Different recommendations go different ways.
Glrx (talk) 20:42, 24 October 2017 (UTC)
I know that my /bin/bash script has its disadvantages, I should have said that before.
Some users on German Graphis Lab think it can be intelligent to upload a source-Inkscape-SVG-file (with "real" text, with grid, construction lines...) and a second opimiced-normal-SVG-file wich is for the MW-Renderer. (But as far as I know "no one" uses this method.)
  • If I have text-anchor="end", why do I need <text>text-align="end"</text>?
  • In File:Essigsäuresynthesen.svg the aria-label doesn't make sence to me, due to the fact that the original text is 1000px moved to the right(outside the visible picture).
  • xml:space="preserve" is in my opinion used too often, when it is not necesarry.
  • I corrected the font-family="Sans"-Mistake
The optimizers have also there disadvantages, you have to use them case dependently.
Of course the Author allows to edit it's file, but (s)he still might disagree that I publish the edited file under his name, due to the fact that (s)he does not agree on the information of the changed file any more.
In many scientific papers every author has to agree on the written text. (If I use somebody else’s work it should be (or often has to be) cited.) Therfore I usually mention the source, but I don't mention the original author. (Earlier I declared the work done by the authors as in :File:BeamBendingDefinitions_German.svg, but as Sarang told me in User_talk:Sarang/Archive/2017#1.29Danke.2C_2.29Frage (german) that |author= should only have a bot-readable Author change of File:BeamBendingDefinitions_German.svg.
as I told, the description at BeamBendingDefinitions.svg was better! -- sarang사랑
Due to the fact, as soon as I change something, I can't publish it any more in the name of an original author, and as User:Sarang thinks you should only use author-information in the author-field, therefore my hands are tied and I have to write my name as author to everything I publish.
I think that often the upload of a new version (e.g. to make a file W3C-valid) does not need any change of the description. -- sarang사랑
I don't like publishing a translation with my name as the only author, but I think in future I will use the Language-Switch and replace the original file(, with keeping the original author). (I've never used the Language-Switch.)
JoKalliauer (talk) 18:11, 27 October 2017 (UTC)
Yes, some people advocate uploading two versions. In general, I think two copies of the same thing has too many problems of keeping the two copies in sync. Construction lines, grids, and other details should not consume a lot of space, so there's little harm including them in the production SVG. Some chemical SVGs include some private structure information. It's not needed, but it may not be a big deal. When the penalty for the extra information is high, there's some benefit to two copies. Maps often use text-on-a-path for rivers; it looks good. If the renderer does not support text on a path, then the artist may convert the text to curves. The conversion may be difficult to reverse, so two copies can make sense, but I would not want them under different names. The better option is to fix the renderer. Inkscape is a more complicated problem; its design goals are different from those of a website.
If you already have text-anchor="end", then deletion is appropriate. I interpreted the bash script's always delete as too agressive. I don't see text-align="end" as a valid SVG attribute, but it might be a mistake where the user intended to say text-anchor="end". Consequently, I'd keep the harmless attribute around until I was sure its intent was met or not needed. Rather than always deleting the attribute, it might be better to change it to text-anchor or turn it into a "text-align:right" style. It should be a conditional delete rather than always delete.
I don't see an aria label on the figure, but even if the aria label is nonsense in one image does not mean it is nonsense in all other images. I've seen it used reasonably to identify text that has been converted to paths. Inkscape does not clearly identify that a path element is converted text, but sometimes that is implied with style="font-family:Arial". Removing such style information removes the hint.
Yes, I think xml:space="preserve" is poorly used and over used, but I can appreciate why Inkscape and others use it. If one does not keep track of #text nodes (not text elements but #text nodes), then spaces can appear in strange places. Illustrators often do not understand the fine points. An illustrator might make a map with "ATLANTIC OCEAN" as a label. To make it take more space, he might space the letters in the label: "A T L A N T I C   O C E A N" (I saw an SVG map that did that last week). Without "preserve", the word spacing is lost and result becomes a spaced "ATLANTICOCEAN". The illustrator would be both angry and confused about the spacing. Also, deleting the attribute without confirming it has no effect can have a poor result; it would wreck such spaced labels.
First, I have high regard for Sarang. I don't know much about info templates. Yes, it would be nice if they were bot-readable, but I don't see that as an absolute requirement for wikitext on an image page. The page is meant to be read by humans. I'm aware of Commons:Structured data (but I have significant reservations about it).
Second, there's a lot more going on with attribution, and I think you see that clearly. I should not quote a paragraph from somebody's paper and make her an author of my paper; she may not agree with the other things I say. On the other hand, I should not translate the labels on a diagram and imply that I drew the diagram by listing myself as the sole author/creator. Such an implied claim does not feel right to me, either. Music publishing makes a clear distinction: there's a credit for the music score and a separate credit for the music lyrics. If I translate the lyrics, I should not also take credit for the music score. How to specify such credit for illustrations does not appear to be well settled. When somebody translates a book, should they be listed as an author, an editor, or something else? Recently, {{Cite book}} added translator* fields. How to cite translators does not gets much attention. As I said, I'd keep the artist as an author and just note that I just translated some labels. If a bot cannot handle such information, then maybe the bot should be fixed. If somebody wants machine readable metadata, then metadata in the image seems the better way to go. Such metadata travels with the image. A lot of work has been done on specifying image metadata, but there are still problems.
I'm interested in switch element translated images. See File:First Ionization Energy.svg. Sadly, too many wikis display images with English labels rather than their native language. Such switch translated images have some nice features (one copy instead of several diverging translated copies), but a switch translation can also go too far. File:Map of USA with state names.svg has 400 kB of translation information; it is so large that it should never be directly served. For MW right now, switch translated images can be reasonable. For any translation method, there are problems with images that use with crowded, multiline, text, such as File:Electric glow discharge schematic.png.
Glrx (talk) 20:53, 27 October 2017 (UTC)
xml:space="preserve" is missing in File:SVG_Test_TextAlign.svg

In File:SVG_Test_TextAlign.svg I would add xml:space="preserve" in Einstein's formula: E=mc2. Otherwhise Inkscape as well as scour will add spaces between </tspan><tspan> leading to E =mc 2 instead of E=mc2.
I know the file is written by hand, but I think it should also be read/saved correctly by other software.
It is one of the few files listed on Commons:Commons_SVG_Checker, which clams a render-bug, therefore it should be a well written example without any source-code-bug in it.
I already did too much wrong with this file, therefore I just wanted to tell you, if you like you can change it.  — Johannes Kalliauer - Talk | Contributions 17:34, 29 October 2017 (UTC)

The SVG is W3C valid and it's intent is clear. If Inkscape and scour do not do it correctly, then both have bugs and should be fixed. The absence of xml:space="preserve" does not permit agents to add spaces where they don't exist already. Neither Inkscape nor scour are authorities about SVG. Furthermore, xml:space="preserve" will be deprecated in SVG 2.0 (but still allowed and still functional).
XML indentation is a difficult problem. Most SVG elements can ignore xml:space and #text nodes.
The intended tests in Einstein's formula are tspans with different text-anchor attributes and handling superscripts with baseline-shift="super". An extraneous space inserted by a misbehaving program may be unfortunate, but I doubt such a space will hide the fundamental errors in librsvg or Edge.
By the way, there's little reason to display the SVG source on the file page. The source is accessible from the file page by clicking on the image (to load the SVG into the browser window), right clicking inside the new window, and selecting "show source". One need not download the SVG and open it in a text editor to view it.
Glrx (talk) 18:23, 29 October 2017 (UTC)
Thanks for the explantations.
I use Ctrl  & u for displaying the source-code, but many users don't know how to view a source code of an svg-file, and if someone is interested in the bug, you might don't want to open the pic in the browser an then view the source, and there are many fiels which are difficult to read (f.e.File:2D_gedrehtes_Auflager.svg (830 Bytes)), displaying the source allows to view the pic and read the source without changing the page.
 — Johannes Kalliauer - Talk | Contributions 17:35, 30 October 2017 (UTC)

Other discussion[edit]

Welcome to the Structured Commons focus group![edit]

Hello! Thank you very much for signing up to the community focus group for Structured Commons :-)

How to organize ourselves?

This focus group is new and experimental, and I welcome your tips and thoughts on how we can organize this in the most convenient and productive way. For now, I have posted a few separate topics on the focus group's talk page. Please add your questions there too! If we all add that page to our watchlist, that's probably a good way to stay up to date with current discussions. Steinsplitter has also initiated a brand new IRC channel specifically for Structured Commons: wikimedia-commons-sd (webchat) which we invite you to join. Please let me know if you have other ideas on how to work together.

Current updates

Warmly, your community liaison, SandraF (WMF) (talk)

Message sent by MediaWiki message delivery - 13:34, 25 October 2017 (UTC)

Autopatrol given[edit]

Commons Autopatrolled.svg

Hello. I just wanted to let you know that I have granted autopatrol rights to your account; the reason for this is that I believe you are sufficiently trustworthy and experienced to have your contributions automatically sighted. This will have no effect on your editing, and is simply intended to help users watching Recent changes or Recent uploads to find unproductive edits amidst the productive ones. Thank you. jdx Re: 02:34, 16 November 2017 (UTC)

Structured Commons focus group update, Nov 21, 2017[edit]

Hello! You are receiving this message because you signed up for the the community focus group for Structured Commons :-)

IRC office hour today, 21 November, 18.00 UTC
  • The IRC office hour about Structured Commons takes place at 18:00 UTC in wikimedia-office webchat. Amanda, Ramsey and I will give updates about the project, and you can ask us questions. The log will be published afterwards.
Tools update

Many important community tools for Commons and Wikidata will benefit from an update to structured data in the future. You can help indicate which tools will need attention:

Warmly, your community liaison SandraF (WMF) (talk) 16:26, 21 November 2017 (UTC)

Structured Commons focus group update, December 11, 2017[edit]

Hello! You are receiving this message because you signed up for the community focus group for Structured Commons :-)

Later this week, a full newsletter will be distributed, but you are the first to receive an update on new requests for feedback.

Three requests for feedback
  1. We received many additions to the spreadsheet that collects important Commons and Wikidata tools. Thank you! Now, you can participate in a survey that helps us understand and prioritize which tools and functionalities are most important for the Wikimedia Commons and Wikidata communities. The survey runs until December 22. Here's some background.
  2. Help the team decide on better names for 'captions' and 'descriptions'. You can provide input until January 3, 2018.
  3. Help collect interesting Commons files, to prepare for the data modelling challenges ahead! Continuous input is welcome there.

Warmly, your community liaison SandraF (WMF) (talk)

Message sent by MediaWiki message delivery (talk) - 16:40, 11 December 2017 (UTC)

Structured Commons - Design feedback request: Multilingual Captions[edit]

Hello! You are receiving this message because you signed up for the the community focus group for Structured Data on Wikimedia Commons.

The Structured Data on Commons team has a new design feedback request up for Multilingual Captions support in the Upload Wizard. Visit the page for more information about the potential designs. Discussion and feedback is welcome there.

On a personal note, you'll see me posting many of these communications going forward for the Structured Data project, as SandraF transitions into working on the GLAM side of things for Structured Data on Commons full time. For the past six months she's been splitting time between the two roles (GLAM and Community Liaison). I'm looking forward to working with you all again. Thank you, happy editing. Keegan (WMF) (talk) 15:09, 24 January 2018 (UTC)

Structured Data feedback - What gets stored where (Ontology)[edit]

Greetings,

There is a new feedback request for Structured Data on Commons (link for messages posted to Commons: , regarding what metadata from a file gets stored where. Your participation is appreciated.

Happy editing to you. Keegan (WMF) (talk) 22:58, 15 February 2018 (UTC)

First structured licensing conversation on Commons[edit]

Greetings,

The first conversation about structured copyright and licensing for Structured Data on Commons has been posted, please come by and participate. The discussion will be open through the end of the month (March). Thank you. -- Keegan (WMF) (talk) 17:26, 16 March 2018 (UTC)

Multilingual captions testing is available[edit]

Greetings,

The early prototype for multilingual caption support is available for testing. More information on how to sign up to test is on Commons. Thanks, happy editing to you. - Keegan (WMF) (talk) 17:06, 24 April 2018 (UTC)

Structured Data on Commons IRC Office Hour, Tuesday 26 June[edit]

Greetings,

There will be an IRC office hour for Structured Data on Tuesday, 26 June from 18:00-19:00 UTC in #wikimedia-office. You can find more details, as well as date and time conversion, at the IRC Office Hours page on Meta.

Thanks, I look forward to seeing you there if you can make it. -- Keegan (talk) 20:54, 25 June 2018 (UTC)

What properties does Commons need?[edit]

Greetings,

Structured Commons will need properties to make statements about files. The development team is working on making the software ready to support properties; the question is, what properties does Commons need?

You can find more information and examples to help find properties in a workshop on Commons. Please participate and help fill in the list, and let me know if you have any questions. Thanks! -- Keegan (WMF) (talk) 18:53, 28 June 2018 (UTC)

File:Agitated vessel.svg[edit]

Thank you for your contribution. Could you please correct this error in the Italian version? "Palleta --> Paletta" (as written in File:Agitated vessel - it.svg). --Daniele Pugliesi (talk) 03:02, 6 July 2018 (UTC)

@Daniele Pugliesi: Sorry about the mistake. It's fixed now. Glrx (talk) 04:39, 6 July 2018 (UTC)

Round 2 of Picture of the Year 2017 is open![edit]

POTY barnstar.svg

You are receiving this message because you voted in R1 of the 2017 Picture of the Year contest, but not yet in R2.

Dear Glrx,

Wikimedia Commons is happy to announce that the second round of the 2017 Picture of the Year competition is now open. This year will be the twelfth edition of the annual Wikimedia Commons photo competition, which recognizes exceptional contributions by users on Wikimedia Commons. Wikimedia users are invited to vote for their favorite images featured on Commons during the last year (2017) to produce a single Picture of the Year.

Hundreds of images that have been rated Featured Pictures by the international Wikimedia Commons community in the past year were entered in this competition. These images include professional animal and plant shots, breathtaking panoramas and skylines, restorations of historical images, photographs portraying the world's best architecture, impressive human portraits, and so much more.

There are two total rounds of voting. In the first round, you voted for as many images as you liked. In Round 1, there were 1475 candidate images. There are 58 finalists in Round 2, comprised of the top 30 overall as well as the top 2 from each sub-category.

In the final round, you may vote for a maximum of three images. The image with the most votes will become the Picture of the Year 2017.

Round 2 will end on 22 July 2018, 23:59 UTC.

Click here to vote now!

Thanks,
the Wikimedia Commons Picture of the Year committee 11:32, 17 July 2018 (UTC)

Rendering[edit]

“MW does not look at transform or filter, so this would be an upstream bug with librsvg. I do not know if it has been reported at Gnome.”

What is the difference between MW-Rendering and librsvg-rendering?

 — Johannes Kalliauer - Talk | Contributions 18:12, 22 July 2018 (UTC)

MW doesn't actually render SVGs; it just hands the SVG off to librsvg and hopes to get a PNG file back to shove in an img element. Consequently, most problems with how the image is rendered/painted is going to be an upstream librsvg bug. MW is not looking for transforms or filters to interpret; it is letting librsvg do that work.
There are some exceptions. MW does read the SVG file to figure out what arguments it should give librsvg. MW reads the file to look for width, height, and viewBox. If MW misinterprets the SVG file, then the rendering error is MW's fault because it gave the wrong arguments to librsvg. Your bug report about viewBox="0,0,400,200" at Phab:T194192 is an example of such a misread that bit me on at File:Map Tenerife Disaster EN.svg (v 7 July 2018). MW could not read the viewBox, so told it librsvg to paint the image in a 512 px wide PNG; librsvg could read the viewBox, so it probably produced a rectangular bitmap; the browser may then stretch the y-axis to fit the 512x512 image that MW thinks is coming (there are other possible explanations). MW can also mess up in scanning SVG files for systemLanguage and how MW subsequently processes those language tags. Some parts of MW ignore "ru-1" langtags, but other parts of MW will process "ru-1" langtags.
Glrx (talk) 18:53, 22 July 2018 (UTC)

Structured Data feedback - Depicts statements draft requirements[edit]

Greetings,

A slide presentation of the draft requirements for depicts statements on file pages is up on Commons. Please visit this page on Commons to review the slides and discuss the draft. Thank you, see you on the talk page. -- Keegan (WMF) (talk) 21:20, 7 August 2018 (UTC)

File:CoulombsLaw.svg[edit]

I like your edit, but I would see it as a mayor edit (according to Commons:Overwriting_existing_files):

  • The Forces are first order tensors (sometimes [wrongly called]/[mixed up with] vectors), removing the vector-arrow might be unwanted, because the scalars F_1 and F_2 are not defined.
  • F1 and F2 is misleading, because F1 is only one part of the force acting on the Particle 1, what you mean is the force acting on particle 1 due to particle 2. (In Systems there will be more than just two charged particles, and also other forces will occur.)

I just wanted to share my thoughts about the picture, and why I wouldn't change the intention of someone else in this case, also I like your version more than the original one.  — Johannes Kalliauer - Talk | Contributions 21:35, 30 August 2018 (UTC)

@JoKalliauer: I think your threshold for major edit is too low. I am not changing the meaning of the image. You like it. Do you think the original author would object?
If you look at the history of the file, the original author (Dna-webmaster) did not use arrows over the symbols. The arrows were added by Jfmelero in 2009, who also added the Q-q subscripts. If you want to invoke OEF, then blame him. There's a Unicode combining form for arrows, but it does not have good support: F⃗. The arrow may be a missing code point, it may not combine with the previous character, it may overwrite the preceding character, or it may (rarely) do the right thing. I debated using F12 notation in CoulombsLaw.svg, but many articles that use that image use a single index (and none/few use Q-q subscripts), so I reverted to Dna-webmaster's subscripts.
The original author did not use F12 notation, but RJB1 used double index notation in File:CoulombsLaw scal.svg. I updated his image at the same time (and corrected the formula to use bold and magnitude).
My understanding of the math typesetting convention is vectors are usually Roman bold italic. If one does not have bold fonts (e.g., a typewriter), then one decorates the vector with an arrow. The convention for tensors is sans-serif bold italic.[1]
Glrx (talk) 22:29, 30 August 2018 (UTC)
Thanks :-)
Another Question: In General what do you think deleting the sodipodi:guide and the inkscape:grid? (I think it is picture-dependent. In this picture they seem to be quite useless, therefore deleting make sense.)  — Johannes Kalliauer - Talk | Contributions 06:42, 31 August 2018 (UTC)
I wish that more artists would use a sensible pixel grid. I'm amused to see text placed at (237.1823, 89.2145); why not (240, 90)? Maybe the artist is specifying a sensible millimeter grid, but the graphics editor converts it to some strange measurement base. (Inkscape does have the annoying habit of storing a stroke-width in a single float (rather than a double float) but then writing the value out with double-float precision. Consequently, 0.6px gets turned into something like 0.6000012345px.)
Generally, I'm tempted to delete everything in the sodipodi: or inkscape: namespaces. If the file is simple, then the namespaces probably add little information. If the file is a complex, then there might be some important information. Also, complex graphics are going to be large, so trimming the grids and guides may not have much impact on the overall size.
Glrx (talk) 07:36, 31 August 2018 (UTC)

Structured Data feedback - structured licensing and copyright[edit]

Mockups of structured licensing and copyright statements on file pages are posted. Please have a look over the examples and leave your feedback on the talk page. -- Keegan (WMF) (talk) 20:32, 7 September 2018 (UTC)

New discussion on Commons talk:Structured data[edit]

Hello. I've started a new, important discussion about creating properties for Commons on Wikidata. Please come join in, if the process is something that interests you or if you can help. Keegan (WMF) (talk) 16:48, 19 September 2018 (UTC)

Structured Data - upcoming changes to viewing old file page revisions[edit]

How old revisions of file pages work are likely going to have to change for structured data. There is information about the change on the SDC hub talk page, please read it over and leave feedback if you have any. Keegan (WMF) (talk) 15:30, 28 September 2018 (UTC)

Structured Data - IRC office hours today, 4 October[edit]

There will be an IRC office hour for Structured Data on Commons today, 4 October 2018, from 17:00-18:00 UTC in #wikimedia-office. You can find date/time conversion, as well as a link to join the chat in your browser if needed, on the IRC Office hours page on Meta. I look forward to seeing you there. -- Keegan (WMF) (talk) 05:49, 4 October 2018 (UTC)

Structured Data - search prototype[edit]

There is a search prototype for structured data on Commons available. Please visit the search prototype page on the structured data hub for information on testing and feedback. -- Keegan (WMF) (talk) 19:07, 5 October 2018 (UTC)

File:Equatorial coordinates.svg[edit]

Hi Glrx,

Thanks for adding Greek and tidying up the wikitext. I tried creating a template to transclude another template but it just returns the wikitext:

This SVG has multiple translations:
File:Glrx
Glrx|lang=equatorial_coordinates.svg (equatorial_coordinates.svg)
File:Glrx
Glrx|lang=eo (Esperanto)
File:Glrx
Glrx|lang=hu (Hungarian)
File:Glrx
Glrx|lang=lb (Luxembourgish)
File:Glrx
Glrx|lang=uk (Ukrainian)


instead of

Would you know how I can get it to work?

Do you also know how to get a list of pages using the file in a given language (instead of all languages as listed in "File usage on other wikis")?

Thanks,
cmɢʟee ⋅τaʟκ 18:43, 10 October 2018 (UTC)

The template did not work because you quoted the vertical bars/pipes ("{{!}}") rather than just using a vertical bar.
I'm not sure about your list of pages. You can get a list of uses on a particular wiki with the MediaWiki API:
https://www.mediawiki.org/w/api.php?action=help&modules=query%2Bfileusage
You could also do prop=globalusage and filter by wikis.
I don't think you can get all instances that use a particular language (i.e., use the file with lang=xx parameter).
Glrx (talk) 19:19, 10 October 2018 (UTC)

A barnstar for you![edit]

Barnstar of Diligence Hires.png The Barnstar of Diligence
Many thanks, Glrx, for helping me with template:svg lang, adding the Greek translation and answering my question. Great working with you! cmɢʟee ⋅τaʟκ 22:17, 11 October 2018 (UTC)

Structured Data - IRC office hour today, 1 November[edit]

There will be an IRC office hour for Structured Data on Commons today, 1 October 2018, from 17:00-18:00 UTC in #wikimedia-office. You can find date/time conversion, as well as a link to join the chat in your browser if needed, on the IRC Office hours page on Meta. I realize this may be short notice for some people; I am experimenting with advanced notice times to see what works best for the most people, I'll be giving more warning before the next office hour. I look forward to seeing you there. -- Keegan (WMF) (talk) 16:02, 1 November 2018 (UTC)

Structured Data - IRC office hour today, 1 November[edit]

The above message says 1 October in the body when it should say 1 November, as the subject line says. Apologies for making a new section by mass message, it's the only way to get this out quickly. See you in twenty minutes! -- Keegan (WMF) (talk) 16:37, 1 November 2018 (UTC)

Structured Data - copyright and licensing statements[edit]

I've posted a second round of designs for modeling copyright and licensing in structured data. These redesigns are based off the feedback received in the first round of designs, and the development team is looking for more discussion. These designs are extremely important for the Commons community to review, as they deal with how copyright and licensing is translated from templates into structured form. I look forward to seeing you over there. -- Keegan (WMF) (talk) 16:25, 2 November 2018 (UTC)

Multilingual captions beta testing[edit]

The Structured Data on Commons team has begun beta testing of the first feature, multilingual file captions, and all community members are invited to test it out. Captions is based on designs discussed with the community[2][3] and the team is looking forward to hearing about testing. If all goes well during testing, captions will be turned on for Commons around the second week of January, 2019.

Multilingual captions are plain text fields that provide brief, easily translatable details of a file in a way that is easy to create, edit, and curate. Captions are added during the upload process using the UploadWizard, or they can be added directly on any file page on Commons. Adding captions in multiple languages is a simple process that requires only a few steps.

The details:

  • There is a help page available on how to use multilingual file captions.
  • Testing will take place on Beta Commons. If you don’t yet have an account set up there, you’ll need one.
  • Beta Commons is a testbed, and not configured exactly like the real Commons site, so expect to see some discrepancies with user interface (UI) elements like search.
  • Structured Data introduces the potential for many important page changes to happen at once, which could flood the recent changes list. Because of this, Enhanced Recent Changes is enabled as it currently is at Commons, but with some UI changes.
  • Feedback and commentary on the file caption functionality are welcome and encouraged on the discussion page for this post.
  • Some testing has already taken place and the team are aware of some issues. A list of known issues can be seen below.
  • If you discover a bug/issue that is not covered in the known issues, please file a ticket on Phabricator and tag it with the “Multimedia” tag. Use this link to file a new task already tagged with "Multimedia."

Known issues:

Thanks!

-- Keegan (WMF) (talk), for the Structured Data on Commons Team 20:42, 17 December 2018 (UTC)

Epicenter Image in Basque[edit]

Hi, Glrx! Thank you for making the correction. It seems that there are some problems with the images I've loaded. Anyway, I hav to ask you a little change or improvement; in the new image in the Basque version, ther is a spelling mistake: instead of "hipocentroa" with a C, it must be "hipozentroa" with a Z. Can you correct it? Thanks a lot! --Koldo Biguri (talk) 18:28, 31 December 2018 (UTC)

File:Epicenter Diagram.svg spelling mistake fixed.
What is the distinction between "epizentro" and epizentroa?
What is the distinction between "hipozentro" and "hipozentroa"?
Wikidata offers the first terms (-o) as translations, but the diagrams are using the second (-oa).
Glrx (talk) 18:39, 31 December 2018 (UTC)

Structured Data - file captions coming this week (January 2019)[edit]

Hi all, following up on last month's announcement...

Multilingual file captions will be released this week, on either Wednesday, 9 November or Thursday, 10 November 2019. Captions are a feature to add short, translatable descriptions to files. Here's some links you might want to look follow before the release, if you haven't already:

  1. Read over the help page for using captions - I wrote the page on mediawiki.org because captions are available for any MediaWiki user, feel free to host/modify a copy of the page here on Commons.
  2. Test out using captions on Beta Commons.
  3. Leave feedback about the test on the captions test talk page, if you have anything you'd like to say prior to release.

Additionally, there will be an IRC office hour on Thursday, 10 January with the Structured Data team to talk about file captions, as well as anything else the community may be interested in. Date/time conversion, as well as a link to join, are on Meta.

Thanks for your time, I look forward to seeing those who can make it to the IRC office hour on Thursday. -- Keegan (WMF) (talk) 20:22, 7 January 2019 (UTC)

Commons:SVG_Translation_Campaign_2019_in_India[edit]

I noticed that several of my images are tagged with Files for STC19IN (S1) and saw Commons:SVG_Translation_Campaign_2019_in_India and thought about you. Since you are interessed in translation-SVGs, I thought I tell you, that you know what's going on in this field (you might already knew it). — Johannes Kalliauer - Talk | Contributions 21:26, 20 January 2019 (UTC)

@JoKalliauer, NKohli (WMF):
Yes, I saw the campaign because several pictures on my watchlist were tagged. I'm happy about the campaign because there should be more translations on Commons, but I wish there were a better process available to the participants.
Glrx (talk) 22:35, 20 January 2019 (UTC)
@Glrx, JoKalliauer: This is so great! Thanks for letting me know. I'm happy to see that the event is still a month away. We will probably be able to have a working version of the tool available by then - maybe not all features but the users will be able to translate and upload files to Commons. I will coordinate with the campaign organizers and see if they are interested in using the tool for the campaign. It will serve as a great way to test the tool and also gain users. -- NKohli (WMF) (talk) 05:10, 22 January 2019 (UTC)

Thanks for all the corrections[edit]

Hello , Thanks for all the corrections in template files created by me. I hv one suggestion if one user is repeating mistakes, most of the time he or she is not aware of the mistakes and if he or she is not a new user (rather regular) instead of correcting continuously in same pattern, we could stop all reworks if you kindly leave a message in detail about the pattern and key points of his / her mistakes in his/her talk page. Thanks in advance. Sumita Roy Dutta (talk) 18:46, 25 February 2019 (UTC)

@Sumita Roy Dutta: My small corrections are no big deal, and the new translations are far more important than getting some template details right. If somebody is skilled at wiki editing, they will watch the files they touch and learn from the changes. If they are not as skilled, then I'm not sure I want to burden them with more details. Even if a user is a long-time editor, the user may already be trying to learn how to use new tools.
In many ways, I wish the translations were being made to multilingual files rather than creating separate files. That's a level of sophistication that I do not expect from most editors. You, for example, added a bn translation to the multilingual File:Anatomy of the Human Ear.svg, but then you also created the redundant File:Anatomy of the Human Ear-bn.svg (which I then nominated for deletion). On the bn.WP mainspace, I can include the multilingual file and the bn translation will appear; alternatively, I can get the bn translation by using [[File:Anatomy of the Human Ear|lang=bn|...caption...]].
Glrx (talk) 20:10, 25 February 2019 (UTC)
Yes that was actually my mistake even I am trying to learn use of switch when I create svg from non svg file to avoid extra space in server. But since in this SVG translation main organiser said that they will not consider the switch file so I had repeated before that I had added switch file in bn with [[File:Anatomy of the Human Ear|lang=bn|...caption...]].But not only here everywhere I hv seen the same thing. I hv learnt a lot seeing a history of the file but pinging have much faster action to stop repetitive mistake and corrections circle. Its just my opinion nothing else.Sumita Roy Dutta (talk) 20:26, 25 February 2019 (UTC)
@NKohli (WMF): take note of "in this SVG translation main organiser said that they will not consider the switch file". I do not know if or where the organiser said that, but it may be relevant to your question about SVGTranslate at User talk:KCVelaga#SVGTranslate tool for the translation campaign. Glrx (talk) 20:34, 25 February 2019 (UTC)
@Glrx: Thanks for letting me know. I am not sure what the reasoning behind not using switch-translations are. I will follow-up with the organizers. -- NKohli (WMF) (talk) 21:20, 25 February 2019 (UTC)
@Sumita Roy Dutta: "to avoid extra space in server" is not a driving reason for using switch. Space is realtively cheap compared to human effort. The advantage of switch is graphic improvements to the original file reach all the translations, too. If the translations are separate files, then each file would have to be updated with the improvements. Glrx (talk) 20:42, 25 February 2019 (UTC)
Totally agreed. pls teach me the technique of adding of switch function process when we make a new svg file let say in inkscape.--Sumita Roy Dutta (talk) 20:57, 25 February 2019 (UTC)
@Sumita Roy Dutta: (e/c) Inserting switch elements into an SVG file has many subtle issues. If the graphics artist has left lots of room for translations, kept most translations on a single line, has used appropriate text-anchor attributes, and has not used subscripts, superscripts, or font shifts, then adding a translation via switchelements should be accomplished with running SVGTranslate 3.0
https://tools.wmflabs.org/svgtranslate
Unfortunately, the new tool is not-quite-ready-for-prime-time. WMF was hoping the current translation campaign would be a test bed for the program.
Alternatively, a text editor can be used, but that requires some knowledge of XML and SVG. Manual editing also benefits from wisely choosing output options in Inkscape and other graphics programs or subsequent optimation of the SVG. Inkscape SVG is notoriously verbose. I would not recommend such editing. If a file already has switch translations, then many people probably have the skills to find the translations and then pattern match the needed SVG to add a new language.
Once a file has switch elements, it is unsettled what graphics editors will do with such files. The downside of switch is potentially locking out graphics editors. Inkscape should be able to handle them but may require artists to learn new skills. What AI and CorelDraw do with the files is unknown. Research in that area is needed.
Glrx (talk) 21:27, 25 February 2019 (UTC)
@Glrx: Thanks a lot. Being from s/w background I am using gedit(UBUNTU OS) or using Inkscape if label is not in individual text format. My work flow is 1.save links as 2. open with gedit , 3.search for </tspan> 4.see all labels to be changed 5.replace font with Lohit Bengali(already installed, 6.change labels with Bengali 7.save as file(adding-bn) . 8.check the file offline with open file option in browser. Sometime if label in Bengali is long, add code for the same with x same y differing . If more complicated then open in Inkscape.
Sumita Roy Dutta (talk) 09:32, 26 February 2019 (UTC)
@Sumita Roy Dutta:. Thank you for describing your work flow. Your software background makes it clear that you are much more sophisticated than the average WP/Commons editor. My work flow is a bit more involved in some areas, but simpler in others because I'm primarily doing European languages.
  1. Remediate the source image to make it easier for others to translate. This step involves simplifying the SVG. I download the file and do it an editor, but others use tools such as svgo. I turn path elements back into their original text. I remove extraneous attributes and styles from the source image. For example, stroke-width:1px is usually not needed, and font-variant:normal is almost never needed. I hoist many attributes. For example, a file often uses only one font-family, so I will place that attribute on the svg element and let the rest of the SVG inherit the value. I will remove width and height attributes in favor of the viewBox attribute. If a label is multiline but uses text elements for each line, then I will merge the text elements. If a file does subscripts by painting separate text elements, then I will combine those text elements. I may simplify the text element by removing unneeded tspan elements. I may group (g element) text elements with their leader lines. I will make sure that the text elements use a sensible text-anchor; that will avoid adjusting x attributes due to simple width variations. I may move text elements to give more room for translations. English is usually compact; Spanish labels need about 30% more space; Chinese is ultra compact. I will add metadata to the file so subsequent copies will identify the author and the origin of the file.
  2. Then I confront a choice: use switch or use a separate file. The decision involves many factors. I'm more reluctant to use switch when the original artist used Adobe Illustrator. If the file has not been edited in a long time, then it is stable and switch might be appropriate. If the file has been translated to many languages and the language versions are starting to drift, then switch may be more appropriate. But issues can change. If the file is being updated frequently, then switch is more appropriate.
  3. You confront a font problem that I can usually ignore. If the file is monolingual, then I can set the default font in the svg element. That would make a change to Lohit Bengali in just one place rather than each text element. I do not have experience with that font (and it is not loaded on my machine), but I often use a fallback font list when the font is important. Ideally, the font list would cover likely fonts on Windows machines, Unix machines, Apple machines, and Commons. I'm aware of some subtle issues with fonts, but they usually do not come into play with European languages. Unicode defines code points for characters, but a single code point may be drawn differently in ko, ja, zh-Hans, and zh-Hant. So font selection may be culturally significant. Font selection becomes more complicated in a switch element file. The font selection can be done for each affected switch clause, but it makes more sense to do it with a CSS attribute selector (which has the additional complication that Commons may not support attribute selectors). I haven't needed to deal with such fine points yet. I also do not expect graphics editors to preserve such distinctions; that's a general problem that needs to be addressed.
  4. When I'm using a text editor, I often have the file loaded into a Chrome window with the debugger turned on. That lets me check the file after I do a few edits. It not only gives a quick validation, but it also helps me find graphics items. Sometimes I will temporarily add some Javascript so I can click an SVG element and learn its id. I may also temporarily hide elements with visibility="hidden".
Glrx (talk) 19:23, 26 February 2019 (UTC)
Thanks a lot for all the detail. Calculation of space for label according to languages are key points when you are developing users friendly s/w to change label using switch option. Because of more back end person(worked very few in front end) and not in practice for 13 yrs I will take more time to understand your workflow fully but its very systematically done that I can understand.Regards. -Sumita Roy Dutta (talk) 08:05, 27 February 2019 (UTC)

┌──────────────────────────┘
@Glrx, Sumita Roy Dutta, NKohli (WMF): Thanks for all your efforts to support this campaign, I am grateful. On the Telegram group, which we have been for communication between the organisers and the participants, I did mention that we would not be considering multilingual SVGs for this campaign. I have some reasoning for that. But before jumping on to detailing you about the reasons, let me give you a bit of background on how we came to this. In September 2018, I organised the Wikigraphists Bootcamp (2018 India) to kickstart the spirit of vector graphics among the Indian Wikimedia communities. The program included awareness about vectors and intermediate-level training on Inkscape. It went quite well (link to report). Twenty-five people from 9 languages took part in that project. This translation campaign is a follow-up to that project. Through this campaign, we are hoping to reach out to the larger community. Eventually we would like to set up to a common Graphics Lab for all the twenty language communities in India. Since translation of an SVG file using Inkscape is probably the easiest and the first step for anyone who wants to learn Inkscape and also be of benefit to Wikimedia projects, we focused on it. Having said that I've one strong reason and two comparatively minor reasons for not having multilingual SVGs within the scope of this campaign.

  • Firstly, use of multilingual SVGs is quite limited beyond Wikimedia projects. The images we have for this campaign are of high-encyclopedic and subjective value. For example, having a Santali-labelled diagram of Human Skeleton is of great value, especially where languages suffer from lack of terminology/jargon in native languages. If this file has to be used in an education material, say a textbook of biology, then a multilingual SVG isn't useful, we need specific individual Santali version. I do slightly know that we can change the default language of a multilingual SVG, I am not sure though. But we can't expect someone outside Wikimedia or even a Wikimedian to change the XML code and use the file; knowledge of XML is a barrier. That'll hinder usage. I don't say switch translations aren't useful, as Glrx already mentioned it'll be easy to make changes. But their scope and applications are limited to Wikimedia projects, or similar Wikis. Though WCommons acts as a central repository of all Wikimedia projects, it isn't necessary that each and every file hosted here should be used on WCommons. So I say that having individual files for different languages is as important as having a multilingual file.
  • Secondly, many of the files have "-en" tag suffixed to their titles. I don't believe that making those multilingual is the right thing to do. I don't have a solution for it either. There should probably be a discussion on the Village Pump to how to handle these; whether we should duplicate the file and make it multilingual or something else.
  • Lastly, as I've mentioned before, for a Wikimedian, translating a file using Inkscape is probably the first step towards learning vector graphics. The larger plan to groom a good number users from India on these skills. So I also see this campaign to bring about a change in the area of vector graphics in India. However, it is a very minor reason, and doesn't add up to why we are not having multilingual SVGs for this campaign.

Before I conclude, I would like to stress that multilingual are important and language-specific files are also important. Both of them have specific applications, advantages and disadvantages. But keeping in view of the background, future plans, how we designed this campaign, we will not be having multilingual SVGs within our scope. KCVelaga (talk · mail) 13:37, 27 February 2019 (UTC)

@KCVelaga, Sumita Roy Dutta, NKohli (WMF):
Thank you for your comments, and I will address them below. A few observations first. For any number of reasons, it can be wise for the campaign to avoid switch translations at this time. It also seems that the campaign's goals are cultivating graphics editors rather than just seeking translations. SVGTranslate 3.0 has a different goal: enable non-graphics editors to translate labels without learning how to do graphics editing. Creating a new graphic requires both artistic and technical skill; translating "patella" into another language requires a different skill.
  1. There is broad support for switch translated files outside of Wikimedia sites. The systemLanguage attribute was part of SVG 1.0 almost 20 years ago. See https://www.w3.org/TR/SVG10/struct.html#SystemLanguageAttribute . Modern browsers support the attribute, but may have some minor issues with the implementation; I've filed many bug reports, and even Commons does not support the attribute correctly (Commons cannot distinguish between zh-Hans and zh-Hant. Chrome and Firefox work. Edge works but only processes the first langtag. What that means overall is someone can include a multilingual SVG on their private website, and that SVG file should display in one of their preferred languages. In Firefox and Chrome, the SVG will even display the user's most preferred language (SMIL allowReorder processing). A user can tell her browser her language preferences: bn > hi > en, and her browser will try to display one of those preferred language. That preference can create surprises: a user reading an en language page may see diagrams in bn. The designers of SVG did not consider nested contexts. Most commercial websites will serve localized rather than multilingual files, but those localized files are generated from a common skeleton graphic rather than being independent files. The multilingual file may be a problem for printed-paper applications. Many such applications can probably import an SVG file, but they may not know how to handle switch. A workaround would be to have a switch aware browser print a PDF or bitmap images. That problem can be handled generally with an XSLT transform. Commons should be providing that XSLT transform; the transform will also be required if WMF keeps its current semantics when it starts serving SVG files.
  2. The usual progression on Commons is an editor creates an image with the name File:MyName.svg in their native language (usually English). Other editors come along, translate the file into another language, and append the language tag; so the new file name might be File:MyName bn.svg. There are files that start out named File:MyName en.svg. When those files become multilingual, they are often renamed to just the root (File:MyName.svg) or explicitly identified as multilingual (File:MyName (multilingual).svg. A misleading language suffix is good reason to rename a file on Commons.
  3. I agree that editing just the text in a graphics editor is an easier task than full-fledged graphics editing; a beginner should find the task relatively easy. I also understand that editing switch translated SVG in Inkscape adds significant complications that make the task hard. One wiki editor reported that one must change the interface language and restart the application. Another wiki editor would use Inkscape's XML editing facility (clearly outside the skill set of a novice). Consequently, the issue of editing switch SVG is not so minor.
Thanks again for your comments. Glrx (talk) 19:21, 27 February 2019 (UTC)
@Sumita Roy Dutta: On a separate matter, when you edited File:Anatomy of the Human Ear.svg to add the bn translations, you deleted the ru translations. In addition, the translations you added generate errors/warnings because they are not in Unicode Normal Form C: W3C validation error and warnings. See Unicode equivalence. It means that the strings have some combining forms instead of reduced characters. Your edit was reverted by Cherkash to restore the ru translations. Glrx (talk) 22:45, 27 February 2019 (UTC)

Using systemLanguage with "fake" language codes?[edit]

Hi. I was wondering whether it would be acceptable to highlight the scales on ColuberScales.svg using e.g. lang=pto for the postocular scales or lang=la for the supralabial scales. Of course "pto" isn't a language and "la" would be misidentified as Latin. It might be better to use codes that are 'reserved for local use' (e.g. qpt and qla). Would this be a useful way to bundle minor variations of language-neutral images or would it be unnecessarily confusing and difficult to use? What's your opinion? TilmannR (talk) 10:52, 8 March 2019 (UTC)

@TilmannR:
Someone proposed a similar trick a few years back, but it is not a good idea. The highlighting is not about a language selection. To work, it must misuse language selection, and that misuse will introduce conflicts.
Technically, one should use the en:ISO 639-3#Special codes rather than convenient ones.
What happens when the graphic artist wants to include both language variants and selective highlighting? The single language code breaks down. The hack can be extended to use more subtags (e.g., |lang=de-x-pto), but WMF's librsvg drops everything after the first hyphen.
In most environments, the user sets his language preferences and then never changes those preferences. The user will not be setting a preference for the pto or qpt language, so the highlighting would never appear in those user agents when the SVG is viewed directly. The highlighting effort would be lost. Imagine somebody inserting the SVG in an ordinary HTML page: the SVG would display in the ordinary manner and not have any pseudo language specific highlighting. It would also give unexpected user experiences on WMF site. A user would see a highlighted image in an article. Clicking that image would take him to the File: page, but that page would display in a different language without the highlights. Setting the language for the highlight would give the original PNG image, but then clicking that PNG image would display the SVG in the user's browser without any highlighting.
The Wikimedia environment is currently strange. It localizes all SVG to PNG according to |lang=. If and when WMF starts serving SVG directly, then WMF must decide how to handle |lang=. Will WMF serve an i18n SVG or will it localize the SVG first? There are many issues.
Given the current constraints of Commons (which cannot reference external files), there is little to do except make separate files that are mostly copies of each other but highlight different parts of the image. That is done with lots of maps: the map is copied, but then the style element is edited to highlight different regions.
Glrx (talk) 17:41, 8 March 2019 (UTC)

Structured Data - development update, March 2019[edit]

This text is also posted on the Structured Data hub talk page. You can reply there with questions, comments, or concerns.

A development update for the current work by the Structured Data on Commons team:

After the release of multilingual file captions, work began on getting depicts and other statements ready for release. These were originally scheduled for release in February and into March, however there are currently two major blockers to finishing this work (T215642, T217157). We will know more next week about when depicts and statements can likely be ready for testing and then release; until then I've tentatively updated the release schedule.

Once the depicts feature is ready for testing, it will take place in two stages on TestCommons. The first is checking the very basics; is the design comfortable, how does the simple workflow of adding/editing/removing statements work, and building up help and process pages from there. The second part is a more detailed test of depicts and other statements, checking the edge-case examples of using the features, bugs that did not come up during simple testing, etc. Additionally we'll be looking with the community for bugs in interaction with bots, gadgets, and other scripts once the features are live on Commons. Please let me know if you're interesting in helping test and fix these bugs if they show up upon release, it is really hard to find them in a test environment or, in some cases, bugs won't show up in a testing environment at all.

One new thing is definitely coming within the next few weeks, pending testing: the ability to search for captions. This is done using the inlabel keyword in search strings, and will be the first step in helping users find content that is specifically structured data. I'll post a notice when that feature is live and ready for use.

Thanks, let me know if you have questions about these plans. Keegan (WMF) (talk) 21:34, 12 March 2019 (UTC)

Structured Data - early depicts testing[edit]

The Structured Data on Commons development team has the very basic version of depicts statements available for early testing on Test-Commons. You can add very basic depicts statements to the file page by going into the new “Structured Data” tab located below the "Open in Media Viewer button." You can use the Latest Files link in the left side nav bar to select existing images, or use the UploadWizard to upload new ones to test with (although those images won’t actually show up on the site). The test site is not a fully functional replica of Commons, so there may be some overall problems in using the site, but you should be able to get a general idea of what using the feature is like.

Early next week I will call for broad, community-wide testing of the feature similar to what we did for Captions, with instructions for testing, known bugs, and a dedicated space to discuss the feature as well as a simple help page for using statements. Until then, you're welcome to post on the SDC talk page with what you might find while testing depicts.

Thanks in advance for trying it out, you'll be hearing more from me next week. -- Keegan (WMF) (talk) 21:59, 21 March 2019 (UTC)

RDF metadata[edit]

Hello. Since you've reverted the File:Anatomy of the Human Ear.svg to continue using RDF metadata, what's the rationale for it? As I mentioned in my edit comment, it's outdated. Why you insist on keeping it regardless? Cheers. Cherkash (talk) 23:14, 21 March 2019 (UTC)

@Cherkash: Why do you say RDF metadata is outdated? I have not seen anything that says Creative Commons has withdrawn its spec. I've seen nothing that says LoC or Adobe have abandoned RDF. Glrx (talk) 01:15, 22 March 2019 (UTC)
I meant the specific data points in this image's RDF metadata are outdated (not RDF metadata in general). So is there a good reason to keep it there? All the necessary data is already present (and timely updated!) on the image description page. Cherkash (talk) 23:44, 22 March 2019 (UTC)
What metadata is outdated?
In addition, when a file is copied from Commons, the File page does not travel with it. The images on Commons are not intended to be used on only WMF sites.
Moreover, many files on Commons are copied from other files on Commons without the required attribution. In many of those copies, the RDF metadata would travel.
Glrx (talk) 00:02, 23 March 2019 (UTC)
The specific data elements in this file are outdated (i.e. they do not correspond to the file and its description page). If you insist on maintaining it in the file itself, then please do the actual maintenance. Otherwise, the points you made above are useless – and the metadata should go. Cherkash (talk) 22:16, 17 April 2019 (UTC)