Commons:Village pump

Shortcut: COM:VP

• Community portal
  • introduction
• Help desk
• Village pump
  • copyright
  • proposals
  • technical
• Administrators' noticeboard
  • vandalism
  • user problems
  • blocks and protections

↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓

COMMONS DISCUSSION PAGES Commons Help desk Village pump (general discussion) Copyright Proposals Technical Graphics and photography discussion Photography critiques Image improvement Illustration workshop Map workshop Photography workshop Video and sound workshop Categories for discussion Undeletion requests Deletion requests Volunteer Response Team/Noticeboard Translators' noticeboard Work requests for bots Contact administrators Vandalism User problems (Dispute resolution) Blocks and protections Bureaucrats' noticeboard CheckUser requests Oversight requests Telegram IRC webchat Commons mailing list (archive) Commons' bugs on Phabricator Welcome to the Village pump This page is used for discussions of the operations, technical issues, and policies of Wikimedia Commons. Recent sections with no replies for 7 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Archive/2024/11. Please note: If you want to ask why unfree/non-commercial material is not allowed at Wikimedia Commons or if you want to suggest that allowing it would be a good thing, please do not comment here. It is probably pointless. One of Wikimedia Commons’ core principles is: "Only free content is allowed." This is a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias. Have you read our FAQ? For changing the name of a file, see Commons:File renaming. Any answers you receive here are not legal advice and the responder cannot be held liable for them. If you have legal questions, we can try to help but our answers cannot replace those of a qualified professional (i.e. a lawyer). Your question will be answered here; please check back regularly. Please do not leave your email address or other contact information, as this page is widely visible across the internet and you are liable to receive spam. Purposes which do not meet the scope of this page: Please do not make deletion requests here: use the relevant process for it instead. For technical support and graphics talks (PNG, SVG, GIF, etc.), please post on the Graphics village pump. To ask for image improvement, see: Graphic Lab/Photography workshop for photographs. Graphic Lab/Map workshop for maps. Graphic Lab/Illustration workshop for other illustrations. To ask for video or audio improvement, see Commons:Graphic Lab/Video and sound workshop. For translation requests, please post at Commons:Requests for translation. For media requests, please post at Commons:File requests. Search archives:     Start a new discussion

Legend
In the last hour
In the last day
In the last week
In the last month
More than one month
Manual settings
When exceptions occur, please check the setting first.

Village pump in India. [add]

Centralized discussion See also: Village pump/Proposals   ■ Archive Costumed character files (14 October 2024) Third-party images published by the National Weather Service (26 August 2024) Commons:Requests for comment/Hosting of free fonts in Commons (18 July 2024) How do we organize categories by date (14 May 2024) Should PD-CQ Roll Call be used for recent images? (5 January 2024) Technical needs survey (17 December 2023) When does PDART apply to textile works? (15 November 2023) Does this image contain "love hearts"? (17 August 2023) Definition of country (19 June 2023) Overhaul of categories by period (5 December 2022) Version of Saudi flag to use (11 July 2022) Concern regarding revocability of KOGL licenses (22 December 2021) Should deleting content from your own talk page be forbidden? (11 November 2021) Revise the COM:FOP Sweden section (1 February 2021) Change technical name of LRs to license-reviewer from image-reviewer(2 November 2023) Was the closure of the deletion discussion concerning the current lede image for Philippe Pétain proper under Commons policy? (22 September 2024) Template: View   ■ Discuss    ■ Edit   ■ Watch

January 28

"Ku" iso-code in auto-translation choices to be replaced by kmr

List of affected pages ({{Ku}} uses)

see Commons:Village pump/List of affected pages containing template ku

Discussion

Tracked in Phabricator
Task T39310

ku (ethnologue.com) is a macrolanguage code which contains multiple mutually unintelligible sub dialects of Kurdish (see this work by UCLA Language Materials Project for more info):

• Wikipedia has hosted 3 main dialects (as far as wikipedia article count is concerned anyways). These dialects are:
  • diq (Zazaki): Zazaki, Southern (classification of it as Kurdish may be controversial)
    • ethnologue.com: Latin script
    • Zazaki dialect has separated from ku.wikipedia on 5 January 2007 with m:Requests for new languages/Wikipedia Zazaki to form diq.wikipedia.
  • ckb (کوردی): Soranî (سۆرانی)
    • ethnologue.com: Arabic script
    • Sorani dialect has seperated from ku.wikipedia on 14 November 2010 with m:Requests for new languages/Wikipedia Kurdish (Sorani) to form ckb.wikipedia.
  • kmr (kmr): Kurmanji
    • ethnologue.com: Arabic script. Cyrillic script, used in Armenia. Latin script, developed in 1932.
    • Currently the UI and vast majority of the content in ku.wikipedia is in this dialect.
• Incubator has two more dialects:
  • sdh (کوردی خوارگ): Southern Kurdish (کوردی خوارگ)
    • ethnologue.com: Arabic script
    • incubator:Wp/sdh
  • kiu (Kırmancki): Kirmanjki or Zazaki, Northern (classification of it as Kurdish may be controversial)
    • ethnologue.com: Latin script
    • incubator:Wp/kiu

I don't know if there are exceptions but the problem is practically all of the uses of ku iso code refers to the Kurmanji dialect which has an ISO code of kmr which should be preferred over ku.

Currently "kmr" isn't implemented on MediaWiki which is why {{#language:kmr}} does not currently work. This proposal is dependent on the implementaiton.

-- とある白い猫 ^ちぃ？ 15:18, 2 June 2012 (UTC)

There isn't any consensus about that "kmr" should replace "ku", which was much discussed in 2011. The users of ku.wikipedia still want it to remain "ku" and thus include any of the "mutually unintelligible" dialects of the Kurdish language in Latin script, as it appears today (2012). --MikaelF (talk) 08:32, 3 June 2012 (UTC)

This isn't how language templates operates on commons (this isn't ku.wikipedia). We avoid macro language iso codes on commons which is why the language code zh is not used for Chinese and instead zh-hans, zh-hant is preferred. -- とある白い猫 ^ちぃ？ 18:12, 3 June 2012 (UTC)

Your example invalidates your argument. We do use the macrolanguage zh for Mandarin even thought zh technically includes a number of other languages. The fact that it's necessary to use a script code to differentiate different orthographies of Mandarin doesn't change that. "ku" is Kurdish; it may be technically correct to change it to kmr, but I think that's technical correctness that doesn't really improve anything; if we have a bot going around changing ku to kmr (and we will need to, in perpetuity), then we've basically declared the identity of ku and kmr anyway.--Prosfilaes (talk) 19:58, 3 June 2012 (UTC)

Similarly, {{No}} is used instead of {{Nb}} and {{Nn}} in many cases. --Stefan4 (talk) 20:14, 3 June 2012 (UTC)

I can run the bot task if needed. On templates we avoid using zh (中文) and instead we use zh-hant (中文（繁體）) and zh-hans (中文（简体）) marking the difference (Traditional/Simplified Chinese). Both are still Chinese but the use of "zh" could be very confusing to the reader.

The difference is Norwegian has two dialects (bokmål/nynorsk) and using no or nb generates the same output:

• {{#language:no}} norsk
• {{#language:nb}} norsk bokmål
• {{#language:nn}} norsk nynorsk

As you can see regardless of the language code is used the output clearly specifies the variant.

{{#language:ku}} (kurdî) on the other hand merely reads "Kurdish" without specifying the variant. To make matters more confusing {{#language:ckb}} (کوردی) also reads "Kurdi" but in arabic script without specifying the dialect. This is very confusing to the reader whom may be speaking neither kmr nor ckb dialect. Not to mention Kurdish has many dialects and currently ku refers to more than one even if you subtract ckb which has its own wiki.

No matter how you look at it ku. related codes are confusing and this needs to be fixed.

-- とある白い猫 ^ちぃ？ 22:42, 3 June 2012 (UTC)

zh refers to 14 different languages, with Cantonese (to pick just one) being mutually unintelligible with Mandarin. Frankly, I see no point in jumping the gun on this; if there are speakers of Kurdish that want it changed, we can discuss it then, if not, then there's not really a problem.--Prosfilaes (talk) 00:51, 4 June 2012 (UTC)

This is a good point. None of Kurds wants to change the codes. We have already discussed this topic. White Cat still insists on.. He has started a discussion last year and we didnt accept. i would like to know, if he will keep to discuss it every year? (: --Gomada (talk) 14:01, 5 June 2012 (UTC)

Written Chinese does not have 14 dialects and they all use two distinct writing styles (Simplified/Traditional) and we mark whichever one is on templates all the time. Not counting Zazaki, Kurdish has three distinct dialects with at least two completely different scripts of writing (Arabic, Latin, and possibly Cyrillic). Why do you not want to mark the relevant dialects? -- とある白い猫 ^ちぃ？ 01:20, 4 June 2012 (UTC)

It had taken a bit of effort but I found an example where ku template is used with arabic script: File:Drapeau du Parti pour une vie libre au Kurdistan - PJAK.png which means it isn't kmr dialect. Vast majority of ku uses refers to kmr but not always. A clean-up must be handled with a case by case basis. Automated scripts can perhaps determine if the following text is in Latin or in Arabic script (or both). There are only two uses of {{Ckb}} therefore other uses of it probably is using {{Ku}}. -- とある白い猫 ^ちぃ？ 02:21, 4 June 2012 (UTC)

Written Cantonese is not mutually intelligible with written Mandarian. We mark the writing styles, but we still let zh stand for the more accurate cmn.--Prosfilaes (talk) 02:54, 5 June 2012 (UTC)

When given the option to tag something which template should be preferred? Macro-language {{Zh}} or {{Yue}}({{Zh-yue}})/{{Zh-hant}}/{{Zh-hans}}?

As for {{Ku}} What are you trying to argue? Do you propose we tag arabic script and latin script with the same template? Why would we not want to separate the two? Even the directions can get messed up. Also the text on {{Ku}} should be multi-lingual (in all dialects).

-- とある白い猫 ^ちぃ？ 13:58, 5 June 2012 (UTC)

Scripts are not dialects. The ISO script standard is w:ISO 15924, which tells us that Arabic is Arab and Latin script is Latn; per the RFC language tagging standard we seem to be at least a de facto user of, that would be ku-Arab and ku-Latn, just like Hant and Hans are Traditional and Simplified Han ideographs.--Prosfilaes (talk) 20:47, 5 June 2012 (UTC)

Why would we do that? Why would we want to invent a brand new standard? Why cannot we simply use the existing ISO standard codes for the individual dialects? Could you please name a few reasons? In the case of kmr, ckb and sdh, script changes with the dialect. -- とある白い猫 ^ちぃ？ 01:27, 6 June 2012 (UTC)

It's not a brand new standard, as I explained in the message you replied to. Stop bringing up scripts, if you don't want to tag scripts. This is the standard way to tag the script the text uses. In fact, it is the only way to tag scripts for Kurdish; according to the IANA language subtag registry, while you can assume that ru means Cyrl and en means Latn, kmr, ckb and sdh do not have Suppress-Script labels and thus can not be used to imply script in any standard way.--Prosfilaes (talk) 05:31, 6 June 2012 (UTC)

•  Oppose Let the ethnic speakers hash this out. White Cat is just stirring his usual nonsense. -Nard (Hablemonos)(Let's talk) 00:55, 4 June 2012 (UTC)Let's see where this goes -Nard (Hablemonos)(Let's talk) 04:17, 4 June 2012 (UTC)

  My usual nonsense? How nice of you. Doing that means one dialect will be superior over the other there are more kmr speakers but ckb is the only official dialect. -- とある白い猫 ^ちぃ？ 01:20, 4 June 2012 (UTC)

The matter won't be decided here, and I wonder why you even raised it here (unless you think that a Wikipedia should get a different domain name just to make a Commons template more symmetric...). -- AnonMoos (talk) 03:43, 4 June 2012 (UTC)

The matter should be decided here. This is commons not Wikipedia. This has nothing to do with domain names. Also even if domain names mattered, there is no zh-hans or zh-hant Wikipedia and we do use those which do not match the domain. -- とある白い猫 ^ちぃ？ 03:53, 4 June 2012 (UTC)

Being a user and editor of the ku.wikipedia, it's still, after a year, difficult for me to understand White Cat's intention and persistent interest in changing the name "ku" to "kmr". The actual ku.wikipedia is receiving and is welcoming articles in any major Kurdish dialect in Latin script. There is nothing confusing about this for a Kurdish speaking user!! I am sure of the fact that if White Cat (とある白い猫) knew Kurdish, any of the "mutually unintellegible dialects" s/he's referring to, s/he would understand how much the Kurdish dialects intermingle with each other and that there is no dialect superior to an other. I agree with the above, that let the Kurdish speaking community here on Wikipedia sort this out, and that is if there were a problem... --MikaelF (talk) 06:45, 4 June 2012 (UTC)

From what I understand, White Cat is not wanting to change anything on kuwp, but rather the way that Commons treats the variants of the Kurdish languages on Commons in translation and informational templates. And it would appear that White Cat has some valid reasoning in wanting to create the "kmr" template for use on Commons, whilst also keeping the "ku" template. russavia (talk) 07:10, 4 June 2012 (UTC)

The proposal here has no impact on ku.wikipedia or any non-commons project for that matter. This has to do more with technical handling of language codes and templates here at commons that are not visible to the reader and the label of such parameters (what text would be shown for the label)

Have you read this work by UCLA Language Materials Project? There are linguists whom even regard ku and kmr as separate languages (McCarus 1992). Language Committee approved ckb wikipedia's creation over linguistic differences in the dialects (ckb, kmr).

How do we expect native Kurdish speakers to sort this out when they need a non-Kurdish language to communicate if they only know the dialect they speak? Even the script they'd use (arabic or latin) would be an issue. What prevent's us from participating if we know the third language they are using? Also vast majority of this problem has to do with technical aspects.

I am sure it is confusing to a first-time visitor to Commons whom finds it difficult to read script he or she is not familiar with. You are giving superiority to kmr if you mark it with the macro-language code. The de-facto default currently on Commons for Kurdish is latin script and kmr dialect since vast majority of the uses of {{Ku}} shows this. There are only two uses of {{Ckb}} meaning Sorani dialect is either immensely underrepresented or tagged with {{Ku}} which adds to the confusion.

-- とある白い猫 ^ちぃ？ 12:40, 4 June 2012 (UTC)

How do we expect native Kurdish speakers to sort this out? Is this White Man's Burden or Japan Knows Best For Asia? Nothing prevents us from participating, but it seems right now a lot more like making a decision for them. --Prosfilaes (talk) 21:15, 5 June 2012 (UTC)

This is a technical problem and it has more to do with how bots, templates and auto-translation codes operate. We could have expressed language codes in database numbers, hexadecimals or even hieroglyphs. We preferred to use ISO 639-3 codes and the codes for the individual dialects (kmr, ckb, sdh) are clear. I am yet to hear one reason why we shouldn't use individual ISO codes for the individual dialects. -- とある白い猫 ^ちぃ？ 01:27, 6 June 2012 (UTC)

Because it's none of your business how the Kurds tag their data. Because you're trying to force other people to tag things in the way you want, and they seem disinterested in it, with the best result being that a bot is going to go around examining new edits and taking a correct tag ("ku") and converting it to a possibly incorrect tag (since distinguishing language of short text strings by bot is a hard to impossible job, even on standardized distant languages like English and German, much less unstandardized Kurdish dialects.) Because it makes everyone's day to have someone else lecture them about their language.--Prosfilaes (talk) 05:31, 6 June 2012 (UTC)

• With Artificial Intelligence language identification isn't that difficult of a job (even by hand Latin text is Kmr, Arabic is Ckb with less than 1000 total uses of the template). With AI identifying languages like English and German had been trivial for quite some time. You know, actually a good deal of the uses of {{Ku}} is probably by bots whom tag images based on the interwiki links which actual speakers were not involved. Ku.wikipedia used to have multiple dialects but now it only has one (with the exception of something like 15 pages).
• Our Kurdish language content isn't COM:OWNed by the native speakers of the language, we do not resign content to to their native speakers. You are quite deterministic of "what Kurds want". A good portion of ku.wikipedia community (in 2007) went quite far (to the point of declaring all Zazaki speakers also speaking Kurmanji/Kurmanci) in trying to declare Zazaki as Kurdish even when the actual speakers of Zazaki did not want it. Furthermore (in 2011) there was a ku.wikipedia user that complained about stub creation at diq Wikipedia years after it's creation.
• Moreover (in 2010) ckb users decided to separate under better terms which is proof that they want to be an independent wiki. Main reason for separation was the differences of script which was why ckb Wikipedia was created. The Board of Trustees and language committee approved ckb not ku-Arab. The dialect is distinct enough to have a separate wiki. Also the use of ku-Arab could be controversial if you think about it as the word Arab can be associated with a different ethnicity.
• Might I add there is an underrepresented sdh dialect speakers on Wikimedia sites.

-- とある白い猫 ^ちぃ？ 11:37, 6 June 2012 (UTC)

Also, based on your source from above I read:

• Subtag: ku | Description: Kurdish | Added: 2005-10-16 | Scope: macrolanguage
• Subtag: kmr | Description: Northern Kurdish | Added: 2009-07-29 | Macrolanguage: ku
• Subtag: ckb | Description: Central Kurdish | Added: 2009-07-29 | Macrolanguage: ku
• Subtag: sdh | Description: Southern Kurdish | Added: 2009-07-29 | Macrolanguage: ku

What exactly is the problem?

-- とある白い猫 ^ちぃ？ 11:58, 6 June 2012 (UTC)

One: language detection is formally impossible, like many other AI problems, and in practice the problem is very real with short strings. Is Roméo et Juliette French? Possibly, but it's also the name of an opera as listed in the English and Portuguese Wikipedias. And those are languages with standardized orthographies; is Romeo va Juliet supposed to be Turkish or Vietnamese?

Right; when making changes to content of use to one group of people, them wanting something is a clear violation of COM:OWN. The English speakers should feel free to make whatever changes to the non-English content of Commons we want, because hey, we're the majority!

If you use quote marks, you could actually try and quote me. I didn't say anything about "what Kurds want"; what I said was that Kurds are currently tagging their data with ku, and there's no Kurds coming here that are saying to change that.

So basically you're for proper tagging except when you're not. The standards say that you can assume nothing about the script of ckb. Don't invent controversy to get your way; if you want to label a piece of text as being in the Arabic script, you have to add -Arab to the language tag unless the language is Arabic, Persian, Pashto or Urdu.--Prosfilaes (talk) 20:08, 7 June 2012 (UTC)

•  Oppose As a Sorani Kurdi speaker and user of ckb wikipedia, I'm againist to change codes. We (users of ckb) don't have problem about codes. Because, ku.projects are for all Kurds. For example; I can create Sorani articles by latin alphabet in ku.wikipedia. ku code represents all of us. If Kurds have problem about codes, they can ask to change. We don't need to some people to decide for us. I hope, you have respect to our decision. Thank you.--Calak (talk) 09:13, 7 June 2012 (UTC)

  This is commons though, not a ku.project or wikipedia. Also "ku.projects" should be for everyone not just a particular ethnicity. How would a visitor whom does not know how to read latin characters know what to read at "File:Mahabad Dam.JPG"? -- とある白い猫 ^ちぃ？ 15:39, 7 June 2012 (UTC)

  Huh? That's plaintively absurd; even if you don't read Latin characters, it's trivial to scroll down that page until you find a language you can read. Are you telling me you can't figure out what File:Imari Jar DES.jpg is about because it doesn't say English on the page?--Prosfilaes (talk) 20:08, 7 June 2012 (UTC)

  Why even mark different translations at all? You seem to have a fundamental problem with how commons marks languages. We want to mark languages and if needed the individual dialects. You have not stated a single reason why this should not be done. I have listed plenty of problems why dumping mutually unintelligible dialects (with 2-3 different writing scripts) into one template is problematic. -- とある白い猫 ^ちぃ？ 21:17, 7 June 2012 (UTC)

  Rather, you've ignored my reason; that any improvement is negated by the fact that you're overriding the judgment of the Kurds on how to handle their own language. I don't want the Kurds running around changing all the English tags to be en-US or en-UK, and in turn I will not interfere with their use of ku. And for about the 45th time, using those dialect tags to distinguish between scripts is wrong. Period. ku-Latn and ku-Arab are the ways to distinguish between Kurdish in the Latin script and Kurdish in the Arabic script. Even if you tag something ckb, you still need to tag it ckb-Latin or ckb-Arab if you want to make a script distinction.--Prosfilaes (talk) 21:50, 7 June 2012 (UTC)

  Kurds do not get any special say on commons template structures any more than Palauans. ku template is not "theirs" to decide. Commons templates have no bearing on how people handle language(s) they speak. {{En-US}} and {{En-UK}} do not exist so your point is moot.

  It really helps to read about the topic you are commenting on. ckb dialect uses Arabic script only. ckb content should be tagged with {{Ckb}} not with anything else.

  -- とある白い猫 ^ちぃ？ 00:13, 8 June 2012 (UTC)

  I think I've wasted enough time on discussion. If you try and unilaterally force your will down everyone else's throats--because apparently only White Cat gets a special say on Commons template structures--I will revert you, and drag you before the Administrator's Noticeboard.--Prosfilaes (talk) 00:55, 8 June 2012 (UTC)

  I oppose script-based tagging. This isn't done on commons and there is no consensus to start a brand new standard. Do you edit templates often? How do you propose technical difficulties be addressed? -- とある白い猫 ^ちぃ？ 01:12, 8 June 2012 (UTC)

•  Oppose I fully agree with Prosfilaes above. White Cat, you see plenty of problems by the use of all the mutually unintelligible Kurdish dialects, because you don't know any of them. Thank you for the references about the Kurdish language, but do listen to the users of the language and respect their decision. Again I oppose to this proposal as much as Çalak above, and also to White Cat's (とある白い猫) proposal to change the name of the Kurdish Wikipedia to Kurmanji Wikipedia. --MikaelF (talk) 17:36, 8 June 2012 (UTC)
  • No, I proposed the adjustment of the database code based on the content on the wiki. Kurmanji (kmr) is a dialect of Kurdish and is hence Kurdish. Sorani (ckb) is another dialect of Kurdish and is hence Kurdish. "ku" is just a database value just like "kmr" or "ckb" or "sdh". We use ISO codes to mark databases but we could have used numbers. -- とある白い猫 ^ちぃ？ 20:41, 9 June 2012 (UTC)
    • とある白い猫 is just a database value too, but I see to recall someone making a big fuss over it recently.--Prosfilaes (talk) 01:28, 18 June 2012 (UTC)
      • Ah my username. What about it? -- とある白い猫 ^ちぃ？ 15:11, 19 June 2012 (UTC)
• Any more comments? -- とある白い猫 ^ちぃ？ 21:31, 17 June 2012 (UTC)
  • Yes; learn how to let a subject drop.--Prosfilaes (talk) 01:28, 18 June 2012 (UTC)
    • Not quite. -- とある白い猫 ^ちぃ？ 15:11, 19 June 2012 (UTC)

White Cat blocked

White Cat has been warned by me for not changing the description from ku to one of the dialects, based on this discussion of not only not being supported by the community but also for not being a native speaker. He has continued to do so, so I blocked him for 1 day and will keep blocking until he stops. User:Zscout370 ^{(Return fire)} 19:04, 8 June 2012 (UTC)

The block has been lifted by Geni, pending on him not making such changes in the future. User:Zscout370 ^{(Return fire)} 19:27, 8 June 2012 (UTC)

Issue was raised at user disputes but it seems there is no oversight on the matter. -- とある白い猫 ^ちぃ？ 20:31, 14 June 2012 (UTC)

Merge extensions of {{Information}} to it

Templates such as {{Location}} and {{LargeImage}} often are not placed correctly or bots/users insert content in between them. These should be integrated into {{Information}} so that they appear properly where they are supposed to. The fields can be hidden with parser functions. -- とある白い猫 ^ちぃ？ 16:47, 2 June 2012 (UTC)

There were many proposals over the years to expand {{Information}} template, including some by me, but there seem to be general lack of support for expansion of that template. Also adding extra fields would not be sufficient, some bot would still have to go through few million of images and add values to the new fields. --Jarekt (talk) 18:23, 4 June 2012 (UTC)

I can operate the bot if needed. A carbon copy of "Information" template can be created (Information2, Information(detailed), whatever) which would merge all of these fields. First step is to list all of the extensions, is there such a list somewhere? -- とある白い猫 ^ちぃ？ 00:29, 6 June 2012 (UTC)

Technically it is not a big challenge, the issue is usually trying to gain support of other editors and if one gets such consensus than logistics of running the bot. There are 11M files on Commons using {{Information}}. Editing at recommended non-urgent speed of edit every 10 seconds, you should plan for ~10k edits per day. To go through 11M files would take you ~ 3 years. Of course not all images might need an edit, but it still takes time. --Jarekt (talk) 01:04, 6 June 2012 (UTC)

I'd target files tagged with {{Location}}, {{LargeImage}}, etc instead. Do you have a list of the templates? Can you determine their total transclusions? -- とある白い猫 ^ちぃ？ 20:05, 6 June 2012 (UTC)

Here is the list of most linked to templates Special:MostLinkedTemplates. You can also get total transclusions count by clicking transclusion count in Special:WhatLinksHere pages. --Jarekt (talk) 20:21, 6 June 2012 (UTC)

I really don't want to plow down these. Are all the relevant templates really not covered in a help page of some sort? ---- とある白い猫 ^ちぃ？ 01:22, 7 June 2012 (UTC)

{{Location}} is one of 4 location templates. If these aren't created/added by bot, users have a fair amount of problems doing them manually.

Thus, I don't think {{Location}} should be included into {{Information}} directly.

For a consistent look, you could go through file description pages and place it directly below {{Information}} (or include this in some other cleanup). Identifying and suggesting fixes for bots and tools that could be improved to place it there would also help. --  Docu  at 15:12, 10 June 2012 (UTC)

Oh certainly, normal users shouldn't be inconvenienced. A bot can regularly look for new uses of {{Location}} (and other similar templates) a bot can merge it to {{Information}} regularly. The idea is that {{Location}} orchestrates where the content supposed to appear. Would this be more acceptable? -- とある白い猫 ^ちぃ？ 03:48, 11 June 2012 (UTC)

I don't see the advantage of merging them. If you place it right after {{Information}} it already appears as if it would be part information. For bots it should make no difference if they place it within or just right after {{Information}}

One of the ideas of {{Location}} is that users can edit it. It's easier to do that if it's not within {{Information}}

Users already get puzzled if edits of texts in {{En}} within {{Information}} don't work as expected. --  Docu  at 09:03, 17 June 2012 (UTC) (edited)

The thing is they are often not near {{Information}} and people add content in between them. There are bots that add content right after {{Information}}. Dismissing problems does not fix them.

After the migration parameters from related templates would be directly passed to {{Information}}.

Consider this sample usage. If merged you would merely migrate the parameters to {{Information}}.

• To me {{location dec|50.67413|4.39857|region:BE}} is confusing because the parameters aren't labeled. What is 50.67413? Longitude? Latitude? Some secret code? While what the first parameter does is obvious to you and me, it is not so obvious to a new user. With named parameters what goes where is more obvious.
• If the goal is to assist new users templates such as location should be labeled and for the sake of simplicity merged with {{Information}}. What is more confusing to particularly new users starts with actually knowing about {{Location}}'s existence, then figuring out where to place it, and then finally figuring out how to actually use it. I don't see how using a separate template makes anything easier even to an experienced user like me.
• Users nowadays prefers using the upload wizard so new uploads would not be impacted by this, the script merely would need to be adjusted so this is even less of an issue.
• Segregating the related templates (that must be put near each other) offers no advantage whatsoever.
• Users can still use {{Location}} and a bot would grab them and merge them with {{Information}} regularly.

-- とある白い猫 ^ちぃ？ 00:26, 18 June 2012 (UTC)

• I don't know that users 'prefer' using the upload wizard, they just use what they're given, and if new here probably haven't worked out how to avoid it yet ;-)
• A version of the location template for new users, which has labeled parameters, may be useful, I think that what would be even more useful would be a wizard (perhaps toolbox entry, or gadget) that assisted users to enter location information (working out or asking them what format their information was in, or getting it from EXIF data (although there is a bot that does that)).

It also occurs to be that unless users normally carry about with them a GPS device, they probably don't know the co-ordinates anyway, so they presumably consult a map (google etc) to work it out, so that function could be integrated into such a wizard (didn't User:Dschwen have such a tool?)

• For users, merging the templates has no advantage, and just makes things less flexible.
• The location templates work quite happily where-ever they're put, I don't see that it particularly worries new users. --Tony Wills (talk) 02:11, 18 June 2012 (UTC)

• I'm not sure that there is an agreed placement/order of templates, but if there is, or we can get a consensus then that is a good job for a bot. When the location template is rendered adjacent to the infomation template the surronding box merges into one info box - so you can get a nice standardised effect without having to merge templates. Normal practice seems to be to have a bot that watches for newly edited image pages and updates them then - that saves embarking on an exercise to update perhaps millions of files at once.
• Also good if the bot checks that it hasn't edited the image recently, to avoid getting into edit wars with other bots ;-)
• Getting an agreed order of templates (perhaps it could be in a file that relevant bots automatically consulted) would be a good idea if we want consistancy in presentation (mind you adding {{Information}} templates to all images first would help :-)
• Editing the {{Information}} template will invalidate the caching of every image page using it (11 million?), not something to be done without pressing need.

--Tony Wills (talk) 02:11, 18 June 2012 (UTC)

• There was a sweep before to standardize (internationalize) image headers so that they became {{int:filedesc}}. This is a similar shift but with a more noticeable impact in terms of improvement.
• An agreed list is pointless because any user or bot can break the order. This happens frequently enough. No one can tell me the list of templates relevant to the {{Information}} let alone tell me the order they should be in.
• Only pages that have {{Information}} and some other related template (such as {{Location}}, {{LargeImage}} etc.) would be affected so the number should be a lot fewer than 11 million. This has been said before. Not all uses of {{Location}} has {{Information}} on them.

-- とある白い猫 ^ちぃ？ 09:48, 18 June 2012 (UTC)

The use of these templates is not mandated anywhere, they are used by convention and because people think they are useful. People sometimes create new versions of this template for particular uses. Perhaps the easiest path is to create a new template with useful features that people want (perhaps including features others have wanted to add in the past) and promote its adoption. At some point in the future the community may decide to merge the templates.

I'm not sure what relevance the reference to {{int:filedesc}} is, apart from recognising that some things are standardised by bots?

An agreed order simply gives bots (and people) a standard to use when there is no other reason to place the templates any other way. It will not enforce only one way to order them. There are no stone tablets from above describing how image pages should look, it is a continuosly evolving thing (which is why we can even consider adding more fields to a standard template). The only important thing is that the images be described in ways that are useful to people wanting to use them. Unlike bots, humans are pretty flexible when it comes to formatting, they can recognise the information whether the location is put before, within, or after the information template - exact placement is really a rather trivial cosmetic thing. --Tony Wills (talk) 22:09, 19 June 2012 (UTC)

How about using the other_fields parameter for {{Information}} for this? We can create a version of {{Location}} (and others such as {{LargeImage}} maybe) that return only a row (instead of an entire table - with {{Information field}}) and simply pass it to |other_fields=. That way we also don't need the CSS hack to let the templates look like one table (in MediaWiki:Filepage.css). Also this way we keep {{Information}} from becoming too big, and as far as bots go, it does make it so that the Location things are within the {{Information| * ... *}} transclusion. –Krinkle^talk 22:11, 19 June 2012 (UTC)

I was thinking of suggesting that, but it appears that you can only have one "other_fields" entry (it seems to just use the last one it finds in the template), so that you can only use that for one extension to the info template. I like the way the CSS hack looks, it is a very flexible approach. I'm not sure how messy and universal the code is, but it seems to work fine and is a neat way to extend the info box. I think that for some images it is actually appropriate to have location ahead of the description, eg photographs of a location (landscape, streetscape etc) where the most useful information and major descriptive item is actually where the photograph is of. For a lot of other images, location is rather inconsequential information and might as well be tacked on the end of the info box. --Tony Wills (talk) 03:10, 20 June 2012 (UTC)

Standards please. It is very unhelpful when the bar moves around so much. -- とある白い猫 ^ちぃ？ 05:15, 20 June 2012 (UTC)

Please explain. Unhelpful to who? Yes, it is nice to have all the image pages looking the same, but it is rather arbitary where any particular item is placed. Humans have little problem scanning down a page to find what they want. --Tony Wills (talk) 22:22, 21 June 2012 (UTC)

Updating {{Information2}}

Template already has a filed for location. Perhaps "Large Image" field could be added to it. And a bot can apply it to pages with {{Information}} and {{Location}} and/or {{LargeImage}} -- とある白い猫 ^ちぃ？ 22:41, 19 June 2012 (UTC)

I think having a special purpose information template is fine if there are a set of images that have extra specific info that we would like to know for every member of that set. Eg the info template {{Artwork}} for art-works. You can then have extra fields that prompt people to add the missing important information. So I support having this sort of template that reminds people to add location information where that is an essential part of the description, eg landscapes, cityscapes, streetscapes. --Tony Wills (talk) 03:10, 20 June 2012 (UTC)

One thing I will suggest is this be integrated into the upload wizard so that if user specifies coordinates {{Information2}} is used instead of {{Information}}. Also would you support expansion of {{Information}} to include {{LargeImage}}? I already implemented code for this at {{Information/sandbox}}. The thing is unlike {{Location}}, {{LargeImage}} is a binary question and {{Information2}} extends {{Information}}. -- とある白い猫 ^ちぃ？ 05:09, 20 June 2012 (UTC)

Some time ago, someone went through some of the alternatives to {{Location}}, replaced them with {{Location}} and then deleted them. {{Information2}} seems a recent experiment and just seems to undo all that effort. --  Docu  at 06:14, 20 June 2012 (UTC)

I did it once (although most of the deleted templates are still around categorizing images into Category:Media with erroneous locations). I agree that recent experiments by user:Zolo with {{Information2}}, like moving {{Location}} template inside, are still in experimental phase (no documentation, not tests or examples). I think they waited for resolution to this discussion. I think they can be performed while using templates from {{Location}} family (possibly modified), so they might be still compatible with the current system. --Jarekt (talk) 13:01, 20 June 2012 (UTC)

Yes this was mainly because I found it made more sense to have the coordinates next to the name of the place, but since it is unlikely that we will change all files to a new format, I guess we can get rid of the (and probably merge {{Information2}} with {{Photograph}} too). --Zolo (talk) 08:27, 21 June 2012 (UTC)

Define location for {{Location}}

Rather than bothering users with having to edit templates within templates, could just agree on a location where to place {{Location}} in relation to {{Information}}? Somehow I thought the agreed place was just below {{Information}}, but it seems that this isn't mentioned on {{Location}} or {{Information}}. --  Docu  at 06:00, 20 June 2012 (UTC)

 Agree I think we can add it to both. --Jarekt (talk) 12:37, 20 June 2012 (UTC)

 Disagree This is unenforceable. Numerous times the two are no where near each other and/or content is added in between. Why can't we unify templates? I honestly do not see the harm. Instead of using weird CSS hacks, why aren't these merged as they are meant to be near each other? According to devs performance is not an issue provided the code is thoroughly tested before-hand. {{LargeImage}} can be integrated in with trivial ease (I already have placed the code for this in the sandbox) and {{Location}} can be integrated in with some effort (template seems complicated due to auto-translate). -- とある白い猫 ^ちぃ？ 21:33, 20 June 2012 (UTC)

Ordering of information gives us something that looks nice, and makes information easier to find if there is a lot on the page. What is this talk of "enforceable", who wants to enforce file description formatting? If we can agree on normal ordering of templates, then bots can be modified to respect that and give us some uniformity rather than working against each other.

I see no reason or advantage to merging anything into {{Information}} that is not essential information for every image. {{LargeImage}} and {{Location}} are not relevant to every image, whereas 'Description', 'Date', 'Author' etc are.

I much prefer having simple, self contained, autonomous, independant building blocks (the various templated information boxes), that can be re-arranged or swapped with another innovative idea. For instance there may develop a variety of ways of presenting location information (eg maps with annotations), merging {{Location}} into {{Information}} just tends to add inertia to such changes.

•  Comment I think we can document guidelines for template placement. For instance alerts such as {{LargeImage}} should come before the {{Information}} template --Tony Wills (talk) 22:22, 21 June 2012 (UTC)
  • I don't disagree that ordering is important. But the issue here is better solvable if the templates that are meant to be together are merged or at least something like {{Information2}}/{{Photograph}} is used (though I do share the redundancy concern). As for template ordering I would wish to see {{Assessments}} be used immediately after {{Information}} for example. -- とある白い猫 ^ちぃ？ 23:40, 24 June 2012 (UTC)

June 3

EXIF data

Does anyone know if any data is removed on upload? There is concern that camera serial numbers are contained in it and this could be a privacy issue.Canoe1967 (talk) 21:31, 11 June 2012 (UTC)

I don't believe we remove any EXIF data. Many people would want their camera serial # preserved as evidence of authorship, so I doubt we'd want to remove that automatically. - Jmabel ! talk 23:16, 11 June 2012 (UTC)

I agree with that. The point that another editor brought up is in the case of those that don't want the number public. Is it technically possible to have an option on upload or warning that their personal data is possibly in the image? Even a link to a reliable EXIF editor may help. I didn't realize that my number was in my images until I saw that thread. I don't really care that my number is public because I actually have the receipt still. There is a link in that other thread to a site that can trace stolen cameras if you input an image or number. Canoe1967 (talk) 00:17, 12 June 2012 (UTC)

Removing some or all EXIF data should be technically easy, the tools exist. There are two trickier questions. One is at what stage the user should be asked and what to do with the original image - if the data is removed at Commons we will have a copy with the data included. The other is that it is hard to know whether the EXIF serial number is the only place where identifying information is recorded. E.g. printers (at least colour printers) mark every output page, supposedly to fight counterfeiting. I would not be surprised if similar information was hidden in the jpeg files. --LPfi (talk) 15:39, 12 June 2012 (UTC)

Yes, there are a few issues here. This is a sample image File:EXIF Canon 500D .JPG I made that contains the EXIF reader that came with the camera. I also just realized that some have GPS (I don't have the add-on GPS module so it is blank) This could cause issues if an uploader takes a picture 'my cat', 'my neighbour' etc. Then their location is stamped on the image within roaming distance of their cat. I don't have an issue with it but others do in the other thread. Commons talk:Deletion requests(the exif section) The thread was started over another issue and this issue came up in the thread. Others may wish to find a way to deal with the issue. I wonder if at this point we should choose a venue to discuss it as this one will get buried fast. I started one here Commons talk:EXIF I don't know if that is a good place for it?--Canoe1967 (talk) 16:04, 12 June 2012 (UTC)

I see where the suggestions are coming from. There are many things about EXIF that can be problematic from a privacy point of view, including geographical coordinates (as much as we like to have them). I'd think long and hard, though, before giving uploaders an easy way to scrub or modify all EXIF, as it's one of the best aids we have for detecting copyright violations. —LX (talk, contribs) 06:29, 13 June 2012 (UTC)

Is it technically possible to have the option to just remove serial number or geo data as an option on upload? I agree that the data is handy for copyvio and it shouldn't be too easy to remove all of it. I also like the fact that I can link to the camera model to see if images have been overly cropped before upload.--Canoe1967 (talk) 07:53, 13 June 2012 (UTC)

See bugzilla:20326. Bawolff (talk) 13:43, 15 June 2012 (UTC)

1. Tracing a serial number is not a crime;
2. Stalking IS a crime;
3. Tracing a serial number ≠ stalking anyone. I.e. one might ever find that some of the photos uploaded on commons have been taken by someone who stole their camera (ok, ok, is an extreme situation, but no less extreme than stalking someone simply starting from searching for someone's photo with the same camera serial number);
4. Thus we, at the most , can warn the uploaders about the hazard of publishing a file with EXIF data. Is not our task protecting uploader's privacy;
5. I do reckon, anyway, that an exception can be done for uploaders of such countries (like i.e. China, Iran, etc.) where rights are denied or significantly curtailed or where democracy is only officially stated but not respected (former soviet countries, some Arab countries, and so on) in order to avoid being maliciously traced. That's the most we can do as Commons. Not encouraging scrubbing EXIF data as widespread habit though. -- SERGIO ^{(aka the Blackcat)} 11:29, 16 June 2012 (UTC)

Systematically scrubbing EXIF data would not just complicate copyvio detection (and detection of falsified images) but compromise many legitimate educational uses (e.g. commercial apps and research have made extensive use of file geodata). Many consumers are interested in evaluating cameras based on sample pics, which is an application of model EXIF data, and many photographers interested in how a particular shot was produced have an interest in aperture, shutter time, ISO, etc. Uploaders interested in privacy are better served by using pseudonyms on their accounts. That said I'm all for giving uploaders the option to remove certain sensitive data at the time of upload, as long as such options are off-by-default. Dcoetzee (talk) 18:19, 18 June 2012 (UTC)

Apart from the discussion two weeks ago about two photos in the "my cat" category, today I noticed a problematic upload on English Wikipedia where someone presumably uploaded a picture which falls in the "my dog" category with a GPS position given in the EXIF. Maybe the upload guide at least should mention that EXIF metadata may contain an exact geographical position. There is no issue if you take a photo at an easily identifiable public place, but there may be an issue if you take a photo in your own home. Of course, any actions made on Commons would have no effect on English Wikipedia. --Stefan4 (talk) 12:20, 21 June 2012 (UTC)

It seems the geo data can be stripped. If that 'my dog' image is worthy of commons could admin move it here and remove the geo data in the move?--Canoe1967 (talk) 18:03, 21 June 2012 (UTC)

June 12

Attribution of externally re-used Commons content

The current edition of English Wikipedia's Signpost has an article about problems with Wikimedia content (particularly images) being reused without correct attribution, or in violation of licensing terms. en:Wikipedia:Wikipedia_Signpost/2012-06-11/Special_report. It includes quotes from our very own User:99of9 :).

Aside from flagging an article of interest, I'd like to see if we have any ideas on what might help reduce re-use problems. For instance, we could in theory automatically watermark every (non-PD!) image somehow (Javascript?), and only provide the unwatermarked image when users click the download button. That might seem extreme (and not easy to do, probably) but it would effectively prevent the click-click-got-the-image-bye-then of users grabbing the image without being confronted with the need to respect licensing terms. (It's too easy to ignore the text on the file description page, especially for users who don't understand and don't really care.) Other ideas? Rd232 (talk) 20:20, 12 June 2012 (UTC)

Could we create a list page that has sites using images from commons that violate the rules? We could list all their emails and just pressure and expose them into changing their policies? Bad plan. See reasoning further down in article.--Canoe1967 (talk) 20:40, 12 June 2012 (UTC)

Here is a list of improperly used images: Category:Images used by media organizations but violating license terms. InverseHypercube 22:00, 12 June 2012 (UTC)

That idea seems pretty silly given our own watermark policies ;-) It's also against our purpose, making media freely re-usable as easily as possible -- many uses are damaged by watermarks and that would be a bad thing to try to enforce. Maybe adding an EXIF tag or something is possible, but it's also nice to store the bit-for-bit original versions. Springer did partially attribute some of their images correctly. Perhaps we really need better documentation on what is expected for people who re-use works. It has been suggested to change the CC license tags here to emphasize the usage requirements. But I'm sure that anyone who looks closely will find plenty of examples of derivative works on Commons where the author of the underlying work is also not attributed correctly (or perhaps the CC-BY license was applied to a derivative of CC-BY-SA, that kind of thing). Everyone makes mistakes. Carl Lindberg (talk) 20:52, 12 June 2012 (UTC)

In case it wasn't clear, the watermark would only be shown in the preview on the file description, not in the "download for reuse" files. Rd232 (talk) 00:19, 13 June 2012 (UTC)

What I think might be useful is, instead of the individual uploader having to approach the copyright violators themselves -privately, is to have a tool where they can send them an email via the Wikimedia Foundation. This would have the advantage that standard form letters could be composed that would capture the recipients eye. Anyone that works in a busy office knows that a lot of stuff that comes from private individuals just gets deleted -almost before it gets read. A comment to the effect that we keep a black list of copyright violators (easy to set up) might also help -without it sounding like a threat as it would be a fait accompli already and their PR department might not be happy to know that they are on such a publicly readable list. Links to our licensing terms can be included on the form letter. --P.g.champion (talk) 21:07, 12 June 2012 (UTC)

That's not going to happen - see Commons:REUSE#Enforcing_license_terms. I did draft something resembling a form letter (Template:License enforcement request) but it can only come from the copyright holder. In theory it might be possible for uploaders to send emails from UserX@wikimedia, but even that's probably too much connection to the WMF that the WMF would want that. And sending emails on users' behalf via a main WMF address is out of the question; policing of the facility alone is a nightmare just to think about. Rd232 (talk) 02:06, 13 June 2012 (UTC)

Also if we all use something like this (which should be added to the upload tool), it will not only give re-users an idea of how to attribute the image it but it cleary shows a “ © “ symbol.

DescriptionVillage pump
Date	12 December 2012
Source	Own work
Author	John Doe
Attribution (required by the license) InfoField	© John Doe / Wikimedia Commons /
InfoField	© John Doe / Wikimedia Commons

If a re-user 'aint told he wont know! More info at Commons:Credit line. --P.g.champion (talk) 21:35, 12 June 2012 (UTC)

(Edit conflict) See also a discussion on the Swedish village pump. A major Swedish newspaper published two Commons photos with improper attribution (credited to "Wikimedia Commons", original licence not listed). In this and many cases, the problem seems to be that newspapers don't know how to attribute Commons users. --Stefan4 (talk) 21:10, 12 June 2012 (UTC)

You know, P.g.champion's suggestion inspires me to think that maybe what we need is a giant symbol at the top right of every file description page which indicates or PD. Just to make it visually much clearer this thing is copyrighted (if it is). This should be integrated somehow with the reuse icons; clicking the symbol should give you a similar popup that explains the basic "you can use it under certain conditions" idea. Rd232 (talk) 00:19, 13 June 2012 (UTC)

I like this idea! Clear and concise - and everyone should know what © means. --Philosopher ^{Let us reason together.} 00:27, 13 June 2012 (UTC)

Agreed with all of these broad ideas. Education and clarity is going to give us the most benefit, with the least risk.

Having previously gone through the loop of clearing Commons content for commercial re-use (from both sides), I'd also find it a little easier with better signposting to the "How to" and the "Success stories" pages. Andy Dingley (talk) 01:51, 13 June 2012 (UTC)

(Edit conflict)everyone should know what © means - well, not necessarily; people might think "oh I can't use it" and go away before understanding the actual licensing. In fact, I'd accompany the C symbol with a tagline something like "usable without charge if correctly attributed as shown". "as shown" would refer to the recommended attribution, which would appear directly under the main preview image (above all other text, including image data about pixels etc). Javascript might be able to do this using the Information template. This way, it would be very clear what is expected from reusers, because we're showing it (on a sort of "monkey see, monkey do" principle which might seem insulting as a guide for action if we didn't know how readily people ignore quite simple instructions). Rd232 (talk) 01:57, 13 June 2012 (UTC)

@Canoe1967 - I'm horrified by your proposal of offering email addresses to a lynchmob of halfwit wikivigilantes. That's going to set open media back by years! Remember that this is a project with no competence requirements on its editors and where even Commons admin(s) don't understand basic ideas like a CC licence being irrevocable. I've already suffered commercial embarassment and harm from two wikivigilantes who took it upon themselves to hunt down cases where my IP was being breached by evil corporates (it wasn't). One was a well-known WP idiot, known for his ability to worm his way into any English publically-funded project and cause havoc, the other was an apparently respected Commons contributor who appears to have disagreed with me over a trivial DR, then to have gone out of their way to find trouble to stir up. In both cases the media wasn't even sourced from Commons, although it is available here - they'd been given separately licensed copies of it, in one case at quite a bit better resolution than I was willing to upload to Commons under a free licence. I've also been pursued by a Commons vigilante who was checking out my own attributed use of CC media from Commons and then took it upon themselves to harangue me for using copyright (and credited) media from Flickr too. Once again, this had been cleared by a separate agreement directly with the photographer.

Commercial use and skipped attributions are a bad thing -- but stirring up that sort of hornet's nest would invite an absolute disaster! Andy Dingley (talk) 01:49, 13 June 2012 (UTC)

I did the /s thing to my statement above. It probably is a bad plan.--Canoe1967 (talk) 05:26, 13 June 2012 (UTC)

Those experiences really underline that not only is it only the copyright holder who can enforce copyright (which is well known, I think) - but that others trying to do so may be actively harmful (less obvious). Rd232 (talk) 02:01, 13 June 2012 (UTC)

• I am amazed at a discussion of Commons freely licensed material is considering use of the instead of . Maybe the copyleft symbol is not as widely recognised but it is so obviously related to copyright that there shouldn't be much doubt about what it is about. Creative commons licenses are about subverting the idea of copyright which seeks to restrict the use of material, by using it to maximise the use of material - to make it part of a common heritage that all can use. There are of course a minority who try and use awkward GFDL licenses etc to restrict the use of their material, but that is not in the spirit of Commons. --Tony Wills (talk) 02:55, 13 June 2012 (UTC)
  • The copyleft image might be a better idea than the copyright image - I'd forgotten about it, actually. Please be careful, though, that you don't confuse "creative commons" with "free use" - if I release my work as "attribution required," that is substantially different than releasing it as "CC-BY" - someone who is releasing an image as "CC-BY" is releasing it under a particular legal license. --Philosopher ^{Let us reason together.} 03:45, 13 June 2012 (UTC)
  • Creative commons does not have a monopoly on the idea of copyleft, and unilateral declarations about "the spirit of Commons" seem divisive to me. CC-SA licenses are arguably not copyleft enough. --Avenue (talk) 04:04, 13 June 2012 (UTC)

Never suggested CC was the only copy-left license. Wikimedia policy to migrate images from GFDL to CC may have been divisive and some who clung (and still cling) to GFDL 1.2 licenses have stated they are doing so to specifically to thwart distribution (specifically commercial use) - most certainly not in "the spirit of Commons" ("Commons" as in CC, Wikmedia Commons, and "Reclaiming the Commons"). I don't remember anyone clinging to GFDL licencing of images on the basis it was more copy-left than CC-SA (but I may have missed that one :-). --Tony Wills (talk) 11:45, 13 June 2012 (UTC)

I haven't found anything on-wiki, but there was a hearsay comment along those lines here. Ancient history perhaps. --Avenue (talk) 15:27, 16 June 2012 (UTC)

CC-BY-SA is a copyleft license; CC-BY is not. It's not a universal solution. But it might help in some situations. Carl Lindberg (talk) 12:05, 13 June 2012 (UTC)

•  Question Common practice on WMF projects is not to attribute or give the license on the page on which the image is displayed (e.g. a Wikipedia article), but to link the image to the file description page where the full attribution and licensing information can be found. Is this usually adequate to meet license terms? If it is adequate on WMF projects, is there a reason it would not be adequate for external reusers also (link the image to the file description page here)? Thanks, cmadler (talk) 13:14, 13 June 2012 (UTC)

  In short: yes, but it's a bad idea to do so. Non-fiction books often provide image credits on a separate page at the end of the book. Linking an image to a page that provides the credit is widely considered the online equivalent of that and a means of attribution reasonable to the medium in question. Outsourcing your copyright compliance to a third party is generally a bad idea, though. When Commons has an outage or if the image is renamed without a redirect for some reason, otherwise legal uses can suddenly become illegal. —LX (talk, contribs) 08:50, 14 June 2012 (UTC)

  There are some advantages to this approach however: corrections to attribution metadata on Commons would be inherited, so that sites linking to us would fall into compliance while those that don't may remain out of compliance. Dcoetzee (talk) 18:07, 18 June 2012 (UTC)

• Responding to OP: although I generally assume good faith, in cases where no attribution is offered despite the file description page clearly specifying the desired attribution, I can only assume the content reuser has no understanding of or interest in proper attribution, at least in the context where the reuse was done. User interface changes will do nothing to deter the user who is looking for the quickest possible solution. The only real solution I can think of for such people is embedding visible watermarks/attribution bars in the image itself by default, which would be effective but I regard as a detestable solution. Dcoetzee (talk) 18:29, 18 June 2012 (UTC)

Attribution requirement where the file is used

creditline here

• Someone writes some nice and awesome JavaScript that adds a partial overlay to the thumbs in WP-articles showing attribution information in case a work is not PD.
• This partial overlay is only shown when the file is hovered intentionally.

Requirements:

• Commons:Village pump/Proposals/Archive/2012/05#Clear author indication

-- RE rillke questions? 20:32, 13 June 2012 (UTC)

Bots should stop misguiding people

One major problem with attribution that we see is that even those reusers who at least make some effort to provide attribution don't understand whom to attribute. People often look at the upload log instead of the {{Information}} template (if available). We also have problems with users uploading other people's work while claiming that doing so makes them the copyright holder.

The bots that transfer files from English Wikipedia and other projects compound this problem on a daily basis by perpetuating the misunderstanding that uploading a file makes them the author. We have hundreds of thousands of files stating "Author: Original uploader was (some user) at en.wikipedia". We seriously can't actively mislead people and then act all surprised when they follow our lead.

So: make the bots stop this nonsense. If it's clear who the author is, put the information in the author field without confusing rubbish around it. If it's not clear who the author is, don't fill the author field with unrelated confusing rubbish. —LX (talk, contribs) 08:50, 14 June 2012 (UTC)

Agreed. I suggest to move the original uploader somewhere out of the "author-field" we don't have a database.... Sometimes it's helpful to have this information, or at least a link to the "source file" so one can lookup the uploader. -- RE rillke questions? 10:55, 14 June 2012 (UTC)

Most files moved to Commons have a "Original upload log" section that contains this information. /Ö 21:38, 15 June 2012 (UTC)

Seconded. Also, just a thought. The Upload [http://commons.wikimedia.org/wiki/Special:UploadWizard] screen that gives useful tips before uploading, just says in the last box “We can't accept work from others without their explicit permission. Thank you for your help: This is important.” Would it not be useful to point out that it is the uploader claiming false attribution that is at risk from having legal proceedings taken out against THEM and not WC. Both WP & WC psyche has an anathema against providing anything that could be construed as being legal advice but in this case I think upoaders should be made aware that it is they that would suffer the penalties – and have this as the first tip they see? Maybe a glossary defining the WC meaning of ambiguous terms (Author, Source, etc.) would also help to remove any excuse for getting things mixed up. --P.g.champion (talk) 15:58, 14 June 2012 (UTC)

Pardon me for being late to this conversation: I can program my bot to remove the "original uploader" text if you'd all like. It already removes it if the uploader unequivocably is not the author. What I can do is this: if the bot is unsure who the author is, it can place the name of the uploader in comments, something like this: <!-- {{user at project|Magog the Ogre|wikipedia|en}} REMOVE THESE COMMENT TAGS IF THE UPLOADER HAS INDICATED S/HE IS THE AUTHOR -->. But I definitely would want community consensus for that, because I would quite possibly get some blowback on my talk page if the bot is commenting it out when the author is the uploader. Magog the Ogre (talk) 00:00, 17 June 2012 (UTC)

Magog the Ogre, that would be great (my suggestion was instead to move the "original uploader" info to the source entry instead of the author), I believe this would make a positive difference. Ariadacapo (talk) 07:01, 17 June 2012 (UTC)

I agree that "original uploader" information belongs in the "source" field rather than the author field (except where "own work" is claimed?). cmadler (talk) 14:24, 21 June 2012 (UTC)

Ok, for me. -- RE rillke questions? 11:19, 19 June 2012 (UTC)

 Comment I think {{Information}} code is greatly outdated and should be improved. It simply needs a few more fields. An author filed and a separate uploader filed would be helpful. Also code to transfer files from other wikis to here perhaps be revised to better handle these new parameters. -- とある白い猫 ^ちぃ？ 14:07, 18 June 2012 (UTC)

We don't need more template-mess but a separate database field in MW for attribution information, geo-location, ... Otherwise we/Commons users will be never able to process and evaluate these data efficiently. -- RE rillke questions? 11:17, 19 June 2012 (UTC)

Unfortunately we currently only have the "template-mess". It does not appear likely that we will ever get such a database so we might as well improve what we got. -- とある白い猫 ^ちぃ？ 17:10, 19 June 2012 (UTC)

But do you agree in general, that separate database fields for some information would be desirable for files? Then we could at least open a bug/ discuss the details. I also don't like that anonymous users can vandalize license-tags. This can cause legal implications. Using AbuseFilter does not sound efficient. But being able to protect such a license-database-field from anonymous editing does. -- RE rillke questions? 15:33, 21 June 2012 (UTC)

• I think we should try again with those buttons right next to the image: "Reuse this image", then pop up some clear instructions with copyable html for attribution. I can't remember why it was removed last time, but if we worked on it a bit, I think it would be the best solution for the user. Go to one of our file pages with fresh eyes, and imagine being a reuser confronted with a wall of templates and headings. --99of9 (talk) 13:45, 19 June 2012 (UTC)

• I very much agree with 99of9's fresh eyes approach. 'We' know WC but to a neonate, the whole thing is not intuitive. WC was designed by geeks interested in photography but not all up-loaders and re-users are that sad enough, to to be on our wavelength. There are other people unlike us out there (yes really, I've met some – they try and sell me double glazing or life assurance policies and such like). They need clear, unambiguous instructions. --P.g.champion (talk) 14:24, 20 June 2012 (UTC)

Maintaining (and thus editing) SVGs' text like wiki articles

Administration (and thus user editing) of SVG-files like wiki-articles seems to be an even more appropriate header

After a week almost nothing happened, I like to warm up this issue once more: Whom must I contact on (commons-)wikimedia, or to which sub-community of wikipedia must I go to explain my wish/demand/proposal of this to get an expert peer-reviewing and a realization hopefully:

I like to see (in generally replacing every) "File:*.svg" media presentation and especially the technically/logical administration for the user like an article-page, such that anyone can simply modify the svg-code by text-editing. Of course a valid rendering can only occur with a valid SVG-syntax, but this is in principle the same problem as for any articles! And if you are afraid of too much mistakenly(?) chaos with invalid SVG-files, permit it firstly only users which have a few days (some article-editing) expirience. But this is not necessary in my personal oppinion -- we already have many protected SVG-files -- as long as we have (as usual) the revert button.

The main difference to an article is that it is not interpreted as a wiki-article syntax for when the page is called, but it is interpreted as a wiki-SVG syntax for default display!. The difference to SVG-1.1. is simply: it starts like any legal SVG-1.1-code, but after the final </svg>-statement there follows the Wiki-special description text which is now also presented below on the page "File:*.svg" after displaying the rendered image.

I think to realize such a feature an expert Wiki-programmer should only need at most a few hours to create the necessary context -- correct interpretation and display of this kind of SVG-file. But we get ride for this "special download" for unstructured media of huge amount of data each time you like to make any (small or not) correction to an existing SVG-file. :-( A side effect is: we have also simplified the internal wiki-administration structure a bit. This may also take over later for other structured (XML(?)) content, IMHO. Achim1999 (talk) 11:31, 13 June 2012 (UTC)

summary

The page "File:*.svg" shows up as usual, but if you press the edit-button (if it is not protected, then you have only the view-button), you switch into article-editing state. You get for editing the content which consist of

• the raw SVG-code (the content of the *.svg file)
• followed by a template which generates the currently immediately below the image seen part

Size of this preview: 800 × 400 pixels. Other resolution: 320 × 160 pixels.

...

...

This image rendered as PNG in other sizes: 200px, 500px, 1000px, 2000px.

-stuff

• the text which now already is given for modifications when editing "File:*.svg"

Achim1999 (talk) 17:24, 13 June 2012 (UTC)

"After a week almost nothing happened" - where was this previous discussion after which nothing happened? --Saibo (Δ∇) 18:06, 13 June 2012 (UTC)

Commons:Help desk#Modify an uploaded SVG-file. -- Asclepias (talk) 18:59, 13 June 2012 (UTC) Thanks, converted to a perm link. --Saibo (Δ∇) 19:53, 13 June 2012 (UTC)

I headed over to the bugzilla:5899 and posted a link to these conversations. I also marked the bug as "REOPENED" - not sure if I'm technically supposed to do that, but maybe it'll bring the bug to the attention of the devs there. --Philosopher ^{Let us reason together.} 22:42, 13 June 2012 (UTC)

---

As has been discussed before, editing of SVGs as text would be more harmful than helpful unless the full range of tools for text is available (independent version histories, diff listings, watchlists, etc.). Also, it would be advisable to disable the edit privilege for those who do not have permission to upload files (anonymous IPs, those whose accounts are less than 4 days old, etc.). AnonMoos (talk) 04:09, 14 June 2012 (UTC)

Sorry, it is really a bit off-topic, but your personal judgment that editing of SVGs as text would be more harmful than helpful unless (here we shall have the full set of tools ...) is too subjective, even if you have not this tool-set of maintaining article by the users, IMHO. To open your eyes: Compare a typically English-text article page and a SVG-code-article page. If we make a minor ("random or similar" -- the definition is up to your intelligence what is appropriate in this context :-) ) change in both pages, the SVG-text page can't not be rendered and you see nothing or a black rectangle or a red error message and thus knows something must be wrong! And a minor tricky change, changing the "dark red" of a disc to "light red" is not very important, changing "red" to "blue" would be obviously at first glance and a well-informated user will correct this very soon! In the case of the English-article page you either read instead of the correct word "well-known" the word "bull-shit" or the "word yxnmre" or the word "not agreed", or ... . Then the typically user can only recognize in the case "yxnmre" some sort of vandalism, in the case "bull-shit" bad language, but in the case "not agreed" there is a good chance that he got tricked and believe this wrong information! :-( Thus the statement editing English-article-text is more harmful than helpful (compared to strictly syntax-checked-text), would support the opposite opinion in this case -- and this case is for sure a real danger, not a minor artifical idea! So, be careful to claim subjective judgment as objective correctly. ;-) Thank you. Achim1999 (talk) 10:20, 14 June 2012 (UTC)

BTW: this is the reason why typically (e.g. in jurisdaction) if things are defined by a picture and a describing text and there is a contradiction between both, the text-information takes prior over the picture-information if one must decide. Achim1999 (talk) 10:31, 14 June 2012 (UTC)

Whatever -- if it's cumbersome to keep track of exactly what each edit is (and the only effective feedback is whether the SVG displays or does not display), then that would be a recipe for disaster, and I would be vehemently opposed to any such system of SVG textual edits without the proper accompanying tools. AnonMoos (talk) 22:53, 14 June 2012 (UTC)

Whatever -- your statment is meaningless, because we would have all tools for articles, because I have demanded this hereby! ARGH Achim1999 (talk) 23:23, 14 June 2012 (UTC)

Please try to maintain some minimal degree of self-consistency, because if you're incoherently flopping around all over the place, it's very difficult for others to evaluate or even understand your ideas. I will vigorously and vehemently oppose any proposal to open up SVGs to text editing without appropriate tools for viewing an understanding such edits (comparable to Wikipedia article editing tools), and its far from clear to me whether or not your proposals include this. Certainly your notion that we'll notice there's a problem only when an edited SVG fails to render does not inspire great confidence... AnonMoos (talk) 00:46, 16 June 2012 (UTC)

I like the idea proposed by Nicholas in first suggesting the bug - though I don't see anything in the SVGEdit extension referred to at the bug that suggests that that idea was followed through. --Philosopher ^{Let us reason together.} 04:31, 14 June 2012 (UTC)

How to (comfortable) editing SVGs as text is a different thing than I proposed here! I want to have the full range of tools for text is available (independent version histories, diff listings, watchlists, etc.). and this is trivial, because it is really a (kind of) article page! :-/

The difference is only when displaying such a page! Please don't mix up these two different aims. You may always write an editor for SVG-text or not, totally independent of my proposal! ;) And what I want is not to resolve a bug, but to implement a new feature or better philosophy(!) in maintaining SVG- and to be visionary, general (human-readable / xml) structured media-files! :) Achim1999 (talk) 09:55, 14 June 2012 (UTC)

Could you do me a small favor, Philosopher? Because I can not editing bugzilla.wikimedia.org, don't I?, please correct the sub-link there to the (by me changed, hopefully apropriate) correct section-title.

A further point: We need not a test-wiki-embedding, IMHO. It can be tested much simpler: Make it ready to work in generally, BUT when clicked on edit-button, firstly the actual chosen wiki-page is checked against a small list of selected addresses (SVG-files), and if it is NOT among them do the old (current) behavior. So the developer or a small chosen set (hopefully including me) can use this only for a few selected SVG-files which are in this hidden(?) list. And this list can be secretly increased and lastly be removed and the default behavior reverted to the new maintainance for all SVG-files. Keep things simple, avoid superfluous work! ;) Achim1999 (talk) 13:25, 14 June 2012 (UTC)

(i) I would prefer to seperate file content (in a new namespace, like Media:) and description page (in File: namespace). To separate those seems to be more useful, and will avoid bots to replace stuff in the SVG code.

(ii) How have you calculate 4 hours of work? A correct alpha-quality integration of a SVG editor to Commons would request 2 to 3 weeks, 2 developers (2 days evaluation and planning, 4 to 6 days to deploy existing extension code, 3 to 4 days to write unit tests and maybe some UI tests, 2 days to prepare and deploy a testing environment, then 1 week with the community to debug all the stuff). --Dereckson (talk) 14:13, 14 June 2012 (UTC)

to (i). I would not! Because it causes mainly artifical problems for nothing! There must be a criterion to distinct SVG-article from say English-articles (SVG is like a further language!) to get displayed the SVG-article correctly as SVG-graphic which is (of course) different from rendering an English-article page when displaying it -- or an arabic article :-) ! Thus bots can use this existing criterion, too. In the simplest case it would be a different category, like talk, template, category or whatever page which robots already (should) know to distinguish -- call it SVG.

to (ii) Sorry, this is not my problem! I want not to have a special SVG-editor, ARGH! I estimated the needed real-time only for recognisation of SVG-articles when displayed! We already HAVE the article-logic-maintenance/administration! It is a rather simple change. :-/ Achim1999 (talk) 14:48, 14 June 2012 (UTC)

I don't understand why you want the change you want. In any case every time you edit and save an svg you would have to create an entry in the version history and the upload log for the same reasons as you would with articles. --Cwbm (commons) (talk) 22:38, 14 June 2012 (UTC)

Because I want to be able to modify, especially small changes, simply. Now you also have not to download/upload a whole article page (or user-page, or talk-page or ...) if you like to change some words! Now you see no differences for File:*svg to previous versions, the whole tool-stuff which already exists can not be used to your comfort for SVG-files! :-( Achim1999 (talk) 23:23, 14 June 2012 (UTC)

Say I want to fix a typo or move an image slightly to the right, this would be helpful. svgs should be stored as text rather than as binary files perhaps as that way we can even have diffs to see what exactly changed. Upload would treat svg files differently. -- とある白い猫 ^ちぃ？ 00:09, 18 June 2012 (UTC)

Making SVGs easier to edit is a fine idea, but it's unclear how you would diff text that is laid out in 2D space, or how you would deal with it when the resulting text overflows the space reserved for it in the original image, leading to changes in layout, etc. You really need the ability to edit the SVG in a much richer way than is suggested. I think a decent short-term solution is enabling Extension:SVGEdit. In the mean time, files do have file revisions, and visual examination can clearly identify the differences between versions, so that seems to work fine. Dcoetzee (talk) 18:05, 18 June 2012 (UTC)

Sorry, I dislike to insult you, but you miss the topic:

• as said several times this is not a request for a featurefull (or not) SVG-editor. :-/
• ...visual examination can clearly identify the differences between versions... Exactly this is NOT the case! Why exists the diff-philosophy for text-pages on wikipedia? There has happened a bad design-decision in earlier times for SVG-files and thus users and wikimedia has again and again pay the price for it! :-(
• you are forced (if you can't urge to a system-admin to act behind the scene) to upload a full new SVG-file if only a few characters needed to be change in a current SVG-file. Everybody would shake his head (at best) if this would be forced for an article-page, or talk-page, or user-page, or ... !
• given these version-control-tools, which already exists and are well-proven, then a further step might be to discuss and/or implement a special SVG-editor (capable of syntax-check editors already exists for many CS-languages), if people agree on it.
• BTW: Ever look at an article-page? It's text is also laid out in 2-D space! Achim1999 (talk) 10:00, 22 June 2012 (UTC)

I would also like to see the change in code via diff for version control. -- とある白い猫 ^ちぃ？ 19:17, 18 June 2012 (UTC)

Category not listing images properly

Category:Brick houses in Indiana has 554 images at the moment (I'm thinking of splitting it soon!), but when I view the first page, I get a message of "The following 202 files are in the current category" instead of the normal "The following 202 files are in this category, out of 554 total", which I've always gotten before on the first page, and which still appears on subsequent pages, such as page 2. Why? Moreover, why 202 instead of the normal 200? The parent Category:Brick buildings in Indiana appears to be working fine, giving me "The following 200 files are in this category, out of 547 total" even on the first page. Nyttend (talk) 11:36, 14 June 2012 (UTC)

I suspect the problem is with File:Andrew F. Scott House.jpg and File:Houses in the Old Richmond Historic District.jpg. These two images show up as first ones in the category, even if you go to page 2 or 3. MKFI (talk) 12:34, 14 June 2012 (UTC)

Sounds like my question from three months ago. Someone answered with a link to a bugzilla page. May be the same bug. -- Asclepias (talk) 19:41, 14 June 2012 (UTC)

If a category says "The following 202 files are in the current category" with no total number of files listed, that means mediawiki has detected the category table has an inconsistent total count (Sometimes bad things happen and the total count becomes out of sync). In this case it is most likely not actually inconsistent, just the returning 2 extra files triggers the inconsistency detector. Most likely what is occouring is a db inconsistency in the categorylinks table, where an image is listed as being a normal page (Basically when we output a category, we get first 200 files,first 200 pages, and first 200 subcats, and then sort them by namespace after. If they have wrong type when we sort them afterwards one of the types will have more than 200 items, and always stay at top when paging its section). Looking at the api output we get [1]:

      <cm ns="6" title="File:Andrew F. Scott House.jpg" type="page" timestamp="2011-07-07T15:47:21Z" />
      <cm ns="6" title="File:Houses in the Old Richmond Historic District.jpg" type="page" timestamp="2011-07-07T15:59:26Z" />
...

So MKFI is indeed correct that that is where the problem lies. The timestamp is from june july 2011 which i think was roughly when 1.17 was depoloyed which is one the categorylinks table was being changed around. This is probably some artifact from doing that. Removing all categories from those images, saving the page, and re-adding the relavent categories should fix the issue. Bawolff (talk) 13:54, 15 June 2012 (UTC)

Removing and re-adding all the categories? Ok, thanks, I will try that. (Although I don't understand why that is required to reset the page type data.) But I have a question. Does that mean removing also all the templates through which the files are categorized, such as the source templates and the license templates? Can I just blank the pages and revert? That would be more simple for fixing many files more rapidly. Will that work? (Assuming it's allowed to fix files like that without it passing for vandalism.) -- Asclepias (talk) 15:27, 15 June 2012 (UTC) P.S. Answering my own question: I tested it and it works [2] (although the anti-blanking filters make it less easy). -- Asclepias (talk) 15:53, 15 June 2012 (UTC)

Another question: Is there a way to identify all the files that were affected by that bug and fix them once and for all? Or must we wait until we happen to bump into each of them individually? (Can we estimate how many files are affected? A few hundred? A few thousand?) -- Asclepias (talk) 16:09, 15 June 2012 (UTC)

I feel such files are very rare by virtue of very few people complaining about them (Case in point this thread is happening a year after the issue occoured). I might be able to run a query on the toolserver this weekend [not on my normal computer right now] to find other similar files (Not sure if it would be efficient enough to give meaningful results quick enough. However if they all have timestamps around July 7, 2011 I could just look at categorylinks from around then). I may have been wrong in my previous statement about the timestamp co-inciding with the category schema changes, because the category schema changes for 1.17 happened on march 6, 2011 according to the log. (Perhaps that's one the issue occoured and something else updated the timestamp on the categorylink. Or maybe something else happened on July 7). Bawolff (talk) 16:32, 15 June 2012 (UTC)

btw, the reason one has to remove and re-add the category is that a ?action=purge doesn't touch the categorylinks (or other links) and a null edit will only compare the sortkeys of the categories and won't look at cl_type. Technically one only has to add/remove the affected category, not all, but sometimes its easier just to add/remove all of them. Bawolff (talk) 16:32, 15 June 2012 (UTC)

Huh, that's odd - Category:Brick houses in Indiana was added way before its timestamp, there are no edits to that page on the july 7 2011 timestamp, and its directly added category so no template changes should have changed the timestamp. /me confused how it has that timestamp. Bawolff (talk) 16:54, 15 June 2012 (UTC)

That's also a mystery to me where the timestamps come from. Those files and those categories have no edits around July 7, 2011. From your above comments, I thought you were saying that that was normal and the timestamps did not have to do with any edits but with something else, but apparently not. :) -- Asclepias (talk) 17:02, 15 June 2012 (UTC)

Hmm, on July 6 the maintinance scripts namespaceDupesWT.php and cleanupTitles.php were run on commons [3] I wonder if that's related somehow. In theory an old maintinance script which manually modified the categorylinks table could cause this (Since page is the default for cl_type, and cl_timestamp will magically update on a row change if no value specified). However neither of those scripts touch the categorylinks table, so that seems unlikely. Bawolff (talk) 17:22, 15 June 2012 (UTC)

Thank you for those very useful explanations. Yes, it's probably easier to just remove and re-add everything. Before editing the file I linked above, I looked at all the categories where that file was included and all those categories with more than 200 files were affected. If it's not too much trouble to run the query and list the files, I think that would be useful. I've noticed about thirty files with that problem, but that's only me and I wasn't really looking for them at that time, so I suppose there are probably much more. -- Asclepias (talk) 17:02, 15 June 2012 (UTC)

Bugzilla:35609 has a link to a list of files with this error. /Ö 21:23, 15 June 2012 (UTC)

Ah, nice list, thanks for the link. It's not that bad, considering that some files are listed multiple times, once for each category in which they are included. So now, do we go through that list and do the remove/re-add trick on those files or do we wait for someone to do something about the bugzilla discussion? -- Asclepias (talk) 22:59, 15 June 2012 (UTC)

My query on the toolserver said 48,331 catgorylinks rows are wrong (have wrong cl_collation field. Some of those actually are normal pages and not images so aren't as noticable). The updateCollations.php maintinance script should fix the issue easily though. Bawolff (talk) 18:45, 16 June 2012 (UTC)

Since they all have cl_collation set to empty string, they can easily be fixed by having the devs run updateCollation.php. For comparision purposes, there's also about 15 000 such rows on enwikipedia Bawolff (talk) 19:35, 16 June 2012 (UTC)

I had a new file which wasn't listed in the category I'd added 20 hours ago.

Now it suddenly does.

So it's a delay issue,

or someone ran the fix just now?

--Ikar.us (talk) 20:55, 23 June 2012 (UTC)

Anefo - collection of 140.000 Dutch press photos

I have started a large upload project for the Anefo collection. This is a collection of 140.000 Dutch press photos that today have been released under a CC-BY-SA by the Nationaal Archief. I'd like to ask help in categorizing these images. The images can be found in Category:Uncategorized images from Anefo. Each one has a description (in Dutch), and at the bottom a few suggested categories have been added based on the metadata given with the file. However, these suggestions are not always good, they are in Dutch, and there might be other good categories. Thanks in advance! - Andre Engels (talk) 13:26, 16 June 2012 (UTC)

I created Category:Anefo temporary redirects for some of them. --  Docu  at 09:55, 17 June 2012 (UTC)

Andre, please pause, open a page at Commons:Batch uploading and read Commons:Guide to batch uploading. You're now making beginners mistakes. Multichill (talk) 12:14, 17 June 2012 (UTC)

For example it would be good if it were possible to templatize stuff like "nummer toegang", "bestanddeelnummer" or the source. That way localization would be possible. But I don't know, whether the original data allows to reliably templatize it. --Slomox (talk) 15:36, 17 June 2012 (UTC)

This is fantastic: we have hardly 1200 images and already 950 suggested categories. Just to make sure that we don't run out of (avoidable) work ? --Foroa (talk) 16:59, 17 June 2012 (UTC)

See also Commons:Nationaal Archief - mention this project there? Regards, HaeB (talk) 22:41, 20 June 2012 (UTC)

Pictures by Harold Maxwell-Lefroy

Hi, could somebody upload with robot this images from book ? Every picture is under public domain (check here)Indian Insect Life: a Manual of the Insects of the Plains. Thanks Dominikmatus (talk) 20:33, 17 June 2012 (UTC)

 Done Category here Dominikmatus (talk) 23:20, 22 June 2012 (UTC)

Segregating the corpse images of animals

I really do not want to see images of dead kittens when browsing Category:Kittens, I think these should be a subcat of Category:Kittens (something like Category:Dead kittens or another suitable name) these subcats of animals can be linked together so Category:Dead kittens and Category:Dead birds would share a parent (so it is a many to many relationship). We do not have a lot of these images but I feel this would be an improvement. -- とある白い猫 ^ちぃ？ 21:34, 17 June 2012 (UTC)

• You are presumably as capable of setting up such categories as anyone else. - Jmabel ! talk 23:42, 17 June 2012 (UTC)
  • Yup, but I want to hear from the community. I am not proposing censorship, just re-categorization. -- とある白い猫 ^ちぃ？ 00:07, 18 June 2012 (UTC)
    • As long as it's a subcat (subkitten?) I can't imagine anyone objecting. - Jmabel ! talk 03:23, 18 June 2012 (UTC)
      • Oh the Pun! :D -- とある白い猫 ^ちぃ？ 21:42, 20 June 2012 (UTC)
• I support the idea of such sub-categories. It supports the idea of least astonishment/editorial judgement. I have once uploaded a photo of a dog that had been killed from a shot with a rifle. That has given several unpleasant reactions from other users. I have the feeling that the response have been triggered by shock over seeing something that was not expected in the category for the perticular breed of dog. Had it been found in a subcategory, users who are shocked by seeing such photos do not have to see it, and other users know what to expect when unfolding that specialized category. There are probably many other examples and subject areas, where this can be relevant for people who has certain phobias for instance, such as arachnophobia. --Slaunger (talk) 11:44, 18 June 2012 (UTC)
•  Comment This is basically the same situation as the one discussed in Commons:Categories for discussion/2011/10/Category:Nude or partially nude people with electric toothbrushes. --Stefan4 (talk) 11:57, 18 June 2012 (UTC)
• Go for it. Especially if there are at least 3 such images, it seems like a genuinely useful and noncontroversial subcat to me. Dcoetzee (talk) 17:59, 18 June 2012 (UTC)
  • I would welcome some assistance since there are far too many images and it is a needle in a haystack kind of search. A lot of files in Category:Dead animals should also be migrated to more specific categories for individual species. -- とある白い猫 ^ちぃ？ 21:44, 20 June 2012 (UTC)
• By all means, create and populate the category. --Auntof6 (talk) 21:53, 20 June 2012 (UTC)

Date

Why does this old sculpture (1st century) look so good and fresh? Has it been refurbished or just carefully preserved? Pass a Method (talk) 22:59, 18 June 2012 (UTC)

Because it's not from the 1st century, except for the darker upper part, which was a sculpture of Domitian. The rest is a modern "restoration". -- Asclepias (talk) 23:32, 18 June 2012 (UTC)

Huh? The statue of Nero is a statue of Domitian? Are we talking about the same image? Rmhermen (talk) 01:48, 19 June 2012 (UTC)

Well, that's what some of the flickr comments about the photos of this bust seem to imply from a quick look, but that could be only part of the story. I just saw that this other flickr image has an interesting, perhaps more complete description. It says: "Portrait of Nero reworked as Domitian and later restored in the modern era as Nero (beg. of 17th c.)". That would seem to make sense. The Capitoline museum's page about this bust does say that the sculpture is from the 17th century and that only part of the face is ancient, but the page doesn't tell the story of that part. You can likely get more complete and definitive answers about the story of this sculpture if you ask at the Wikipedia reference desk or at one of the related Wikipedia project pages. -- Asclepias (talk) 02:43, 19 June 2012 (UTC)

June 19

Personality rights

File:Jayne Mansfield.jpg has a personality tag. I am under the impression that film or film trailer screen shots don't require a personality right tag. User:Megapixie is of a different opinion. Commons:Photographs of identifiable people has no explicit direction about this particular issue. What is appropriate? Aditya (talk) 06:28, 19 June 2012 (UTC)

The tag is purely informational, it does not change the rights of reusers and it is not demanded by Commons policy. Thus it is never required. On the other hand, while trailer screen shots hardly can have any privacy issues (other than if the trailer itself has), I think there is no reason they wouldn't have personality rights issues if used in unsuitable context. The actors have probably not given any carte blanche for being used in commercials and I cannot see how the trailer itself could be regarded as such. --LPfi (talk) 07:46, 19 June 2012 (UTC)

But, COM:IDENT mentions the possibility of reuse anywhere, it only deals with consent to be photographed, and that too applies only to certain cases. It is not required at all for a public personality (i.e. a movie star) in a public space (i.e. a mainstream film) without breaching any moral barrier (i.e. a commercial film trailer). As far I can see of the US laws, a published picture can be used commercially too (no carte blanche needed; see: Commons:Country specific consent requirements). Aditya (talk) 09:47, 19 June 2012 (UTC)

The linked requirements page says you usually do need permission for commercial use in USA. Having consented to use in a film (and related posters, trailers etc.) does not give any right to use the image in unrelated commercial contexts. Other countries (such as mine) are even stricter. Thus the warning template is justified. --LPfi (talk) 16:22, 19 June 2012 (UTC)

Personality rights (also called publicity rights) are about using someone's name or likeness in a commercial situation like advertising -- using somebody famous to promote your product, etc. They are not the same thing as privacy rights, at least in the U.S. Those rights are generally never given out without a fee (you have to pay someone to promote your product), and can last past death in some places. In the U.S., it is defined by state law, so it can and does differ between states. Sometimes it's common law (and that usually expires at death), and some states have passed statutory laws which create an inheritable right, such as the w:California Celebrities Rights Act in 1985, which protects the rights 70 years after someone dies, and Indiana passed one which lasts 100 years after someone dies. Courts have ruled that those law were not retroactive (i.e. did not apply to someone who died before the enactment), though I think California recently made theirs retroactive in response to one of those judgments (Sect. 3344.1). So... Mansfield's estate or heirs may have some rights in California at the least, but probably not most places. Carl Lindberg (talk) 16:25, 19 June 2012 (UTC)

Help: Choosing a lens

Hello,

I am looking for a new camera. I found very good prices for Nikon D200 and D300S, but I wonder which lens(es) I should buy with these bodies? Thanks, Yann (talk) 13:44, 19 June 2012 (UTC)

That would depend on your budget and the type of pictures you wish to take. I have a Canon. I just bid low on Ebay for lenses for mine. They are used, but cost about 1/2 the price of new ones. My camera came with and 18-55mm. I ended up with two more from Ebay, 80-200mm and 100-300mm. I didn't intend to win both, but I may trade one off at a camera store for a good macro lens, memory stick, etc. I mostly use the 80-200mm and the 18-55mm for closer work. As to the cameras, the 300s has more mp. If it were me I would go that route, and avoid kicking myself later for getting the lower model. You may wish to see how the images look before you decide on a lens. If the camera doesn't come with a lens then you may wish to start with a wide range zoom. 28-200mm type thing. It may cost more but covers 2-3 lens ranges.--Canoe1967 (talk) 16:15, 19 June 2012 (UTC)

Well, if you want to take a multi-purpose lens, I would suggest that (1) AF-S DX NIKKOR 18-105mm f/3.5-5.6G ED VR. or (2) AF-S DX NIKKOR 18-200mm f/3.5-5.6G ED VR II, lens with Nikon D300S body may be taken. Most of the general photographic works are possible and a very popular body and lenses also. -- Biswarup Ganguly (talk) 16:19, 19 June 2012 (UTC)

First regarding the bodies, I'd stay away from the D200. It was launched in 2005, and sensors have come a long way since then. I'd also take a good, hard look at the new D3200, which is is nearly half the price (and weight) of the D300S, but outperforms it in several ways (twice the nominal resolution and better video performance, for instance). The D300S does have better build quality and battery capacity (when new, anyway) and a built-in AF motor, so you're not restricted to AF-S lenses.

Lenses are a matter of preference. I find myself wanting to go wide more often than I want to get close, so the 16–85 stays on most of the time, unless I'm using my 35 prime. Since the 16–85 eclipses my 18–55, the latter hardly gets any use at all. When I do want to get close, the 55–200 usually doesn't get close enough, but it's at least easier to lug around than the 150—500 Sigma behemoth (and that one's broken at the moment). In short, if I had a DX body and no lenses today, I'd start out with the Nikon Nikkor AF-S DX 16-85/3.5–5.6 G ED VR and the Nikon Nikkor AF-S DX 35/1.8 G. An external flash and a good tripod would also be high on my list. —LX (talk, contribs) 11:06, 23 June 2012 (UTC)

Thanks LX, yours are most useful advices. Actually, I first thought to buy a second-hand professional camera (at least for the body), instead of a entry-level new one. Now I see that may not be the right thing to do.

My main subject are portraits and events. My question was about the quality of the lenses matching a certain camera design. It would be a pity to get a professional body, and a lens of poor quality. Yann (talk) 14:49, 23 June 2012 (UTC)

I think most of the popular lens makers may be close. Ziess may still make the best ones but they cost more than my car. You should be okay if you get a lens made by the camera body company. I know there are crappy lens companies out there and the quality may go up and down over time. The same as stereos, cars, guitars, etc. Check out these really expensive ones. http://lenses.zeiss.com/photo/en_DE/home.html --Canoe1967 (talk) 16:04, 23 June 2012 (UTC)

To be honest, I wouldn't call any of the cameras we've discussed so far professional grade. I'd reserve that for the one-digit FX (full-frame 35 mm equivalent) models like D3 and D4 or, to some extent, the high-end three-digit FX models like the D800 and D700. Any camera with a DX sensor (APS-C equivalent) is unlikely to seriously outperform a DX lens, although the D3200 is pushing the capabilities of the 18–55 mm kit lens. Professional cameras aren't for everyone, though. They tend to be large, heavy and based on relatively old technology. You pay a lot for build quality to survive bashings and thousands of shutter releases per day. For event photography, I'd personally make weight and low-light performance a priority (and yes, I'm biased in favor of the D3200, as it'll probably be my next purchase). For the lens, I'd get something with a built-in AF motor regardless of the body – faster focus that way. I'd look for a zoom lens with a wide maximum aperture through the whole range or a fast prime. That's hard to find, though. You could go with a Nikon Nikkor AF-S 70–200/2.8 G IF-ED VR II, but then you're paying serious cash for an FX lens and only using a small portion of the glass. Gangulybiswarup's suggestions are probably more reasonable. For portrait photography, prime lenses are the way to go. I love my 35 mm, and they're practically giving them away. :) —LX (talk, contribs) 17:22, 23 June 2012 (UTC)

I was tempted by a Canon EOS 5D selling for less than 900 US$. The Nikon D300S is selling for 430 US$. Yann (talk) 18:02, 23 June 2012 (UTC)

I've got a AF-S DX NIKKOR 18-200mm f/3.5-5.6G ED VR II and it stays on the camera pretty much all the time. Bear in mind that some of the non camera lens manufacturers make pretty good lenses usually at rather better prices. Tamron springs to mind and I've had and used an 18-200 of theirs quite extensively.

It really does depend what you mainly want to do with it and I'd echo LX's comment on a good prime lens - my Nikon 35 f/1.8 is stunningly sharp, very fast and for the quality amazingly cheap. I would certainly look at Ebay for lenses - a good lens will hold its value far better than the body probably. --Herby ^{talk thyme} 17:30, 23 June 2012 (UTC)

June 20

Can't stay logged in

I can log in, but going to any other page (even watchlist) logs me back out. What can I do? Ntsimp (talk) 17:20, 20 June 2012 (UTC)

Have you tried from another computer? That may sort whether it is this system or yours. You may want to try another IP computer as well, but I doubt that makes a difference. Does it do the same on sites like en:wp if you have accounts there?--Canoe1967 (talk) 18:26, 20 June 2012 (UTC)

Thanks for the help. It's all resolved now; I had somehow disabled all cookies. Ntsimp (talk) 21:40, 20 June 2012 (UTC)

You are very welcome. I always enable all cookies, turn off firewalls and anti-virus, etc. This gives me a really good excuse to buy a new computer and give the old one to someone that I don't like.

This section is resolved and can be archived. If you disagree, replace this template with your comment. --Canoe1967 (talk) 00:04, 21 June 2012 (UTC)

June 21

English-speaking users.have a better interface

Sorry if that has already been discussed but I noticed that when using an English interface, I get at least to nice things I do not have with the French interface:

1. A thumbnail of the image when previewing a file description
2. A "transclusion count" in the "What links here" of templates.

Is that a known bug ? Is is supposed to be fixed some day ? --Zolo (talk) 08:31, 21 June 2012 (UTC)

That is "known" - yes. The second one (the first one is probably similar): Our customization MediaWiki:Linkshere adds that link to the English version. For visibility in other languages the respective /langcode subpage has to be created. The real bug here is that we have no possibility (AFAIK) to easily add some link template to all languages (even if it shows up in English then). This would solve the problem: On Special:WhatLinksHere there should be some inclusion (like Template:Anon-check-links) which is not translated via Translatewiki. Hint: you can find out the relevant MediaWiki pages by using the language code qqx. --Saibo (Δ∇) 13:06, 21 June 2012 (UTC)

Ok thanks. I thought that when translations where missing, we got English translations (which is what happens in the left-hand menu). About case 1, I do not see how it happens, it is just a thumbnail of the image, so there should not be any language problem. --Zolo (talk) 13:57, 21 June 2012 (UTC)

I had a look now but cannot find out where the preview image comes from / which code produces it. --Saibo (Δ∇) 14:33, 21 June 2012 (UTC)

Where does case 1 happen? On the file description page, or somewhere else? I've never had issues like that when switching language interfaces (as I've done quite often). It's just possible it's a cousin to the problem I've had for absolutely ages on one of the computers in my household: no Commons images (in any language). At all. Anywhere. (Not even the Commons logo top left.) But all other websites are OK... Rd232 (talk) 14:52, 21 June 2012 (UTC)

Yes this is when editing an image description and previewing. I get a preview of the image itself with my interface in 'en' or 'de' but not when it is in 'en-gb', 'de-AT' or 'fr'. --Zolo (talk) 16:28, 21 June 2012 (UTC)

Occurrence of issue 1: 0. set your interface lang to fr or vi (uselang param not possible!), 1. open, 2. hit preview, 3. no preview image is shown. If you try that with en or de there is a preview image.

To really solve issue 2 I think the devs should add include a mediawiki message linkshere-project-tools right after linkshere (that is similar to Sp-contributions-footer-anon which is also empty per default/not translated in translatewiki). That can be kept empty per default (and in translatewiki) but get used by multilingual projects like ours. On that page we could do our usual {{LangSwitch}} tricks which falls back to English if no translation is provided. Agree? Better ideas? Cheers --Saibo (Δ∇) 16:41, 21 June 2012 (UTC)

#1 is defined in MediaWiki:Previewnote following a suggestion by Mattes. --  Docu  at 17:51, 21 June 2012 (UTC)

Thanks! So it is is the same issue as above: translatewiki localized messages and only in some languages the preview image has been inserted (of course - it is hard to edit all languages and will lead to no updates from TW). --Saibo (Δ∇) 20:23, 21 June 2012 (UTC)

Unless it's changed in MediaWiki, one could argue that the translation at TranslateWiki should remain w/o the preview image. --  Docu  at 05:47, 22 June 2012 (UTC)

Arguably MediaWiki should just display the image on preview, without it being part of any sort of interface message. Bawolff (talk) 13:27, 22 June 2012 (UTC)

Agree. BTW there is a request for this at Bugzilla:11243 (2007-09-08). --  Docu  at 07:54, 23 June 2012 (UTC)

June 22

Valued image in wrong category?

I have just checked the warthog photos on commons, correcting several identification (long story short: the widespread P. africanus was formerly included as a subspecies of the more localized P. aethiopicus, meaning that some mistakenly still use the latter name when "their" warthog actually is the former -- if requested I can provide a longer explanation of the various features that separate the two, seeing that one user used a feature incorrectly when reviewing the photo).
A photo I corrected is File:Muenster-100720-15883-Zoo.jpg, but I did not correct the identification in the "Valued image" template. Should it be left as a valued image of a category it doesn't belong in, be corrected to the Phacochoerus africanus (the species it really shows), be removed entirely as a valued image, or something else? RN1970 (talk) 03:45, 22 June 2012 (UTC)

I have notified the VI project to get this fixed. Thanks, cmadler (talk) 14:24, 22 June 2012 (UTC)

Thanks. RN1970 (talk) 15:29, 22 June 2012 (UTC)

Need OTRS...

...this image? (File:Plity Gris.jpg) --Metrónomo (talk) 05:50, 22 June 2012 (UTC)

Hrm. Uploaded in early 2005, before OTRS existed. Different standards then. Might be impossible to determine if existed on the web prior to March 2005. Carl Lindberg (talk) 06:09, 22 June 2012 (UTC)

"Copyright free (Granted permission by the author)." means that ru.wiki there should be some kind of authorization? --Metrónomo (talk) 06:35, 22 June 2012 (UTC)

Means that the uploader either is the copyright owner (and the image is PD-self), or they got permission from the author, meaning it's PD-author. That was the claim anyways. Carl Lindberg (talk) 07:10, 22 June 2012 (UTC)

See link COM:GRANDFATHER... -- AnonMoos (talk) 11:51, 22 June 2012 (UTC)

OK, I will use PD-author. --Metrónomo (talk) 19:59, 24 June 2012 (UTC)

How to have multiple uploads of the same image deleted?

The first upload of THIS IMAGE was of poor quality and I replaced it with a higher resolution image which accidentally generated 2 identical uploads because of an upload glitch. I would like to replace with a fourth upload (the best), but before doing so, I would like to have the last two deleted. What is the right process in such cases in general, as older images of my uploads are unnecessary. — User talk:Ineuw 21:16, 22 June 2012 (UTC)

If you are just talking about multiple uploads under the same name, there's no point to deleting them. Even if an admin "deletes" them they are still on the server, so it makes work without saving any space.

If you uploaded under a different name, use {{Duplicate}} on the page for the name you want deleted; see documentation of that template for how to indicate what it is a duplicate of. - Jmabel ! talk 21:37, 22 June 2012 (UTC)

Thanks Jmabel. They are multiple uploads under the same name. So I'll just leave them as is. — User talk:Ineuw 06:49, 23 June 2012 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Jmabel ! talk 21:37, 22 June 2012 (UTC)

Template:Deminimis

User:Gestumblindi suggested a {{Deminimis}} template at Commons:Village pump/Copyright/Archive/2012/04#"De minimis" box template? with a reply from User:Cmadler, and so I decided to make one. Please improve it as you see fit; I have first used it here on File:Louvre at night centered.jpg and here on File:Wildlife Centre entrance.jpg. -84user (talk) 21:29, 22 June 2012 (UTC)

Made a change and another. --Saibo (Δ∇) 23:41, 22 June 2012 (UTC)

The tag which was already on that image is probably more appropriate. Not sure that is really de minimis, but more a theory I think termed the "theory of the accessory" or something like that. Carl Lindberg (talk) 05:19, 23 June 2012 (UTC)

Can/should it be internationalized? Also, as I mentioned previously, I think maybe it should link to Commons:Reusing content outside Wikimedia and mention that, while we think it's accurate, reusers should make their own determination. cmadler (talk) 13:24, 25 June 2012 (UTC)

That reuse help page applies to all images and is linked in the info template's permission field (if existent; it is existent if the de minimis template would be put there). --Saibo (Δ∇) 16:39, 25 June 2012 (UTC)

Question on North Korea / Rodong Sinmun copyrights

On the en.wiki for , we are trying to see if there's a free image of Kim Jong-un to use. An editor has discovered an image of him from the NK state-run paper , our discussion now is whether this can be considered free or not. The editor has pointed to Template:PD-DPRKGov (on commons) suggesting this applies to works put out by the paper, though the paper's website has copyright notices. Is there any advice that commons can supply towards this? --Masem (talk) 23:50, 22 June 2012 (UTC)

The template not suggests this. A photo in a newspaper is not a document of state management and it is not copyright ineligible news/fact or bulletin. --Martin H. (talk) 00:14, 23 June 2012 (UTC)

I'm the user Masem to whom Masem was referring. My argument there ran as follows. First of all, by way of context, the full text of the relevant DPRK law, as referenced in the template, is here [[4]]. It does state that photographs are generally subject to copyright, but the relevant Article 12 limits the applicability of that section in the case of all copyrighted works, and does not make any special exemption in the case of photographs, hence there is no reason to suppose that photographs as a category of work are not covered by that exemption (and indeed, every reason to suppose the reverse). Moreover, whilst the term "documents of state management" is not defined, one of the examples it does specify is "current news and bulletins". When the news is to the effect that Kim Jong Un is the head of the state and his appearance is as portrayed in an accompanying photograph, that would indicate to me that such a photograph constitutes current news covered by the exemption.

But the claim that a picture I referenced of Kim Jong Il that another user immediately had deleted does not constitute a document of state management puzzles me still further. As is stated here [[5]] - on a page that also contains two examples of images of Kim Jong Un released as official portraits by the DPRK, and thus I would argue per the above could be candidates for inclusion under the template I linked - it is a legal requirement that all DPRK citizens display and venerate that very portrait in their own homes. If it's a fundamental law of the DPRK state that a certain image must be displayed and venerated by its own citizens, how can it be argued that that image is not a document of state management? Lordrosemount (talk) 23:03, 23 June 2012 (UTC)

PD-DPRKGov is invalid, see Commons:Deletion requests/Template:PD-DPRKGov. Since the law was changed recently, it's non-commercial only. -- Liliana-60 (talk) 23:48, 23 June 2012 (UTC)

First of all, the law is not here but here. The former link is just a budget translation of the law (meaning that it contains lots of errors). Secondly, the Korean text implies that a "document of state management" (

국가관리문건

/

國家管理文件

/

kukka kwalli mun'gŏn

) is a literary work whereas a photo is an artistic work. Third, "current news and bulletins" (

시사보도물, 통보자료

/

時事報道物, 通報資料

/

sisa podomul, t'ongbo charyo

) are not "documents of state maintenance" but separate things which are also excluded by this part of the copyright law. I would still guess that "current news and bulletins" have to be literary works, though, due to the use of

報道物

and

資料

--Stefan4 (talk) 18:40, 24 June 2012 (UTC)

Football Line Ups

Hey!

I did some week ago an line up for the football match between the swedish clubs AIK and IFK Göteborg. (2010 Svenska Supercupen) And the thing is, it's not good. If you take a look at it you'll see there's an black spot at IFK Göteborgs half. And the shirts aint good either...

So my question, exactly how do you do tactical line ups, where do you find the shirts? I'm using Inkscape

Thanks, Hastaro (talk) 22:32, 23 June 2012 (UTC)

The black spot wasnt there when I uploaded the file, so I have no idea how it got there.--Hastaro (talk) 22:41, 23 June 2012 (UTC)

(unindent) I uploaded File:AIK - Göteborg Supercupen 2010 inkscape plain.svg which has the first "flowRegion" element removed and Commons appears to render that correctly. However, neither Firefox nor Opera had any problems with your version, so I guess the problem is due to mediawiki's software renderer. If anyone wishes to fix the original version, the flowRegion text I removed appears after the "Hysén" element and looks like this:

<flowRegion
             id="flowRegion3158"><rect
               width="22.731783"
               height="13.371637"
               x="478.70462"
               y="399.82626"
               id="rect3160" /></flowRegion>

-84user (talk) 12:16, 24 June 2012 (UTC) Also, the football shirt shapes are rather large (internally) raster images and not vector shapes - that might be what causes the poor appearance. -84user (talk) 12:28, 24 June 2012 (UTC)

Hey, thanks for the answer! Do you know where I can find the football shirts that's used on almost all the line ups? I cant find them anywhere. And yes, the size of the shirts I used was way to big.

And thanks for fixing the black spot.--Hastaro (talk) 17:20, 24 June 2012 (UTC)

By the way, the Inkscape "flowtext" nonsense is a well-known longstanding problem (I've personally probably fixed at least a hundred such images) which is almost always what's responsible for unexpected black rectangles in a rendered SVG. See Commons:SVG Check for diagnosis... -- AnonMoos (talk) 05:13, 25 June 2012 (UTC)

June 24

Removal of original uploader information

I was thinking about having OgreBot 2 remove the original uploader information from the author field of {{Information}} templates. We discussed the issue above (#Bots should stop misguiding people), but it's not getting many eyes, so I'm rehashing it here. I want to get community consensus for this. I will list some of the pros and cons below:

Explanation of process

• OgreBot 2 goes over all of the uploads on a given day and looks for poorly formatted information to clean up. This usually involves internationalization (e.g., "selbst fotografiert" -> {{Self-photographed}}), but can also be clean up of bad bot moves (User:Magnus Manske can't be arsed to respond to even the simplest requests;[6] it's bad enough we might consider writing an alternative bot and ask the Toolserver to take his one down).
• When OgreBot 2 detects that a file has been uploaded from a local project, it already removes the uploader information altogether if the licensing templates indicate the uploader isn't the author (e.g., [7]).
• When OgreBot 2 detects that a file has been uploaded from a local project, it already changes the author field to indicate the uploader is the author if it can unambiguously tell from the licensing templates (e.g., [8])
• When OgreBot 2 detects that a file has been uploaded from a local project, sometimes it isn't sure who the author is. Currently, in cases like this, it just leaves the original uploader in the author field. The following discussion is about these cases.

Pros

1. Frequently, the uploader is not the author, and having the information present is wrong altogether. Thus, we are fixing an inaccuracy. Example: [9] [10] [11] [12].
2. It serves to avoid confusing the reader with extra information.
3. The information is usually down below in the original upload log field anyway
4. There are times when not even a human reader can figure out who created this file. (Example: [13]: who created this SVG code, which is copyrightable?. Or [14]; no author was ever explicitly stated by the uploader). We should not be including the information if it is possibly wrong.
5. It can remove redundancy and pretty up the description page. Example: [15].

Cons

1. Sometimes the uploader has already indicated that s/he is the author in the textual description instead of in the information field. Removing the original uploader would make the template incorrectly state the author hadn't been specified. This is especially common with older uploads and uploads from smaller projects. Examples: [16] [17].
2. Sometimes the uploader actually had indicated the authorship at the local project, but the bots are poorly written so they didn't properly transfer the information. (Example: [18], which you can tell from the old version of the file here, in that the page at sr.wp transcluded sr:Шаблон:Двојна лиценца, which is equivalent to the {{Self}} template on Commons).

Proposals

1. Do nothing
2. Remove the uploader information altogether
3. Replace the uploader information with comment tags giving an explanation: e.g., something like this: <!-- REMOVE THE COMMENT TAGS AROUND THE FOLLOWING IF THE UPLOADER HAS INDICATED THAT HE OR SHE IS THE AUTHOR --> <!-- {{user at project|Magog the Ogre|wikipedia|en}} -->

Discussion

It is my opinion that this information should be removed or placed into comment tags. Magog the Ogre (talk) 00:52, 24 June 2012 (UTC)

 Support #3

I really appreciate your efforts for cleaning up file description pages of files moved from local projects.

In my opinion, only information that is relevant for readers and re-users (i.e. information on image, attribution of author) should be included in Template:Information, in order to avoid confusing them with irrelevant extra information. The following should not be included in there, because it is not relevant and redundant (contained in the original upload log or next to the thumbnail in the file history):

• Who transferred the file to Commons, from which project, using which tool and when.
• The date of the original upload, especially if there is information on the date of creation of the work.
• The original uploader, especially if there is information on the author available or it's unimportant because of the age of the work (PD).
• Permission = [just a rehash of the templates under the licensing section in the language of the source project]

There is obviously not yet consensus on these point. This cleanup edit was reverted by the user who moved the file (and is an admin on Commons).

I want to stress that I really dislike Template:User at project. Replacing e.g. “Example user” by “Example user at English Wikipedia” IMO even violates the condition You must attribute the work in the manner specified by the author or licensor. Therefore, I think we should stop using this template, especially these automatic insertions by a bot or a script. --Leyo 06:39, 24 June 2012 (UTC)

You only want "own" in the source field for a transferred file? Do you also just want "no source given" for flickr uploads (those are also "transfers", more or less)? I think it is quite clear that the info template needs to get more fields to clearly describe all that information from the different point of views. --Saibo (Δ∇) 16:55, 25 June 2012 (UTC)

Yes, only {{Own}} or {{Self-photographed}}. Additional information in the original upload log is certainly sufficient. We could do the same for Flickr uploads. There are however two differences: (i) Flickr is a different website, whereas Wikipedias and Commons are both Wikimedia projects; (ii) the file description page in the source project looks exactly right (as the original local file description page) without information about the transfer in Template:Information. --Leyo 19:23, 25 June 2012 (UTC)

 Support #3

I am especially concerned about making re-use easier. Upload-related data is meta-information, useful for us, not for external re-users.

Thank you for your work cleaning up the disorder... Ariadacapo (talk) 08:59, 24 June 2012 (UTC)

If the bot can't determine whether it's really the author or not, I don't think it should remove that information. It would be even harder for reusers to dig into the history to get who was the uploader in a different wiki (where the file will be deleted), in order to ask that guy who made it or decide if he looks like the author (yes, there are usually wikitext copies of the upload log, but harder to parse or may be missing, not to mention a bot who could be tryng to extract that information). I'd place the original uploader in a template like {{original uploader-author unknown|Example user|project}} which expanded to We have no information about the author of this file. It was originally uploaded by Example user at English Wikipedia, he should be able to provide more data. and properly categorised it ({{Original uploader}} could be repurposed for that) -- Platonides (talk) 14:24, 24 June 2012 (UTC)

• I agree with Platonides' suggestion. cmadler (talk) 13:31, 25 June 2012 (UTC)

I am often appalled by the metadata of files moved from other wikipedias, and I really appreciate the cleanup you are already doing. It would be great if you could also use it to tackle already uploaded files. I see for example a lot of PD-Art files with the only author information being the original uploader and "Original upload log" section (which is quite useless for those files). As with any bot edits there is a trade-off between value added by the changes and potential damage by bot's bad edits, in this case removing useful information. Different users have different threshold for how many bad edits they can take for how many beneficial ones. And this one is getting too close for me. I think that if bot can not determine the author than it should leave the information about the original uploader. I am also concerned about the cases with multiple authors, like photographs of PD-old monuments. In such cases we might need both the name (and hopefully license tag) of the sculptor and the photographer or original uploader if photographer is not known. How does bot currently handle such cases? --Jarekt (talk) 13:55, 25 June 2012 (UTC)

 Oppose any bot action. Your JS script did suppress useful information in the past (e.g. "internationalized" accurate source descriptions into just "{{Own}}") - I do not like to see a bot automatically doing that. Is there a reason why you did not mention all that "cleanup" you intend to do in the "proposals" section? Please clearly list what you want to replace. Keep in mind that nice looking file pages can simply hide that the case is not very clear. Also please don't mess with already manually "cleaned up" transfers. Bots should only be used for uncontroversial changes. --Saibo (Δ∇) 16:55, 25 June 2012 (UTC)

The hell? That is a total red herring. The cleanup JS is an entirely different animal. Talk about the proposal at hand. Magog the Ogre (talk) 21:57, 25 June 2012 (UTC)

And I was more than clear about what exactly was entailed in the bot request. You had your chance to oppose the bot, and you didn't. I gave plenty of notice, more than what was required. I have no idea why you're bringing other edits by the bot into question, as they have nothing to do with this. Now, either put up or shut up: if you don't like the bot's edits, put a nobots tag on the page. Magog the Ogre (talk) 22:00, 25 June 2012 (UTC)

I think 3. is broadly a good idea, but there are various issues raised. Maybe the best way to handle that is with a series of limited test runs, so that we can all see what happens in different situations, and identify edge cases that need further discussion on what should be done. With limited test runs subject to careful review summarising the results, we can be sure that any errors arising will be fixed by the bot operator or others, so I don't think this can be objected to. Rd232 (talk) 22:18, 25 June 2012 (UTC)

Special:UserLogin languagelinks

At Special:UserLogin there are a lot of languagelinks (which reload the page in the specified language when clicked). A suggestion was made (at MediaWiki talk:Loginlanguagelinks) to restrict this list of links to the most used / most important languages. Toolserver preference statistics can be used to identify the most used languages (click on Users to sort them). So: do we want to restrict the number of languages? If so, how many links do we want to have? There are currently 32 at Special:UserLogin; Commons:Language templates list a lot more than that, and Category:Language templates has 343 members. We surely want to stop adding language links at some point. Comments? Rd232 (talk) 14:42, 24 June 2012 (UTC)

What is the advantage in restricting it (apart from ongoing maintenance)? The "most important" language is probably one's own language (even if only spoken by two people ;-). --Tony Wills (talk) 08:57, 25 June 2012 (UTC)

Status quo is OK for me (it was someone else's idea to reduce the number of links). But there has to be a limit, because if we make languagelinks for all languages, it'll fill up the login screen... Rd232 (talk) 12:28, 25 June 2012 (UTC)

We should also respect the accept-lang-header sent to the server. Some users may not set their language in the prefs (for various reasons): User:Multichill/Browser language statistics (needs renewal, asked Erik Zachte). -- RE rillke questions? 09:58, 25 June 2012 (UTC)

That's presumably a MediaWiki issue. I don't know anything about accept-lang, and the only bug I can find is Bugzilla:21672. Are you sure MediaWiki doesn't do this? Rd232 (talk) 12:28, 25 June 2012 (UTC)

MediaWiki does not do anything with accept language (Unless the situation has changed in the last few months. Usually the excuse is cache fragmentation, and the fact accept-lang is often incorrect). Javascript can do stuff with accept-lang by querying the api which can return what accept-lang header the browser passed in (I believe that commons already does this with the nice message asking me if i want to view the page in british english). Bawolff (talk) 19:40, 25 June 2012 (UTC)

p.s. relavent bugs are bugzilla:3665 and bugzilla:33677 Bawolff (talk) 19:46, 25 June 2012 (UTC)

Template:Copyright by Wikimedia/tg

Anyone understand Template:Copyright by Wikimedia/tg? The creator has no other contributions, and it doesn't exactly look like a valid translation. I hesitate to delete it without confirmation though. Thanks, Rd232 (talk) 21:18, 24 June 2012 (UTC)

User has a few contributions on tg and ru wiki, so I think we have to assume good faith unless there is evidence otherwise. Perhaps ask on tg Village Pump or embassy etc? --Tony Wills (talk) 08:49, 25 June 2012 (UTC)

June 25

Excessive use of Personality rights template

I am thinking of removing {{Personality rights}} from all categories except Category:Personality rights warning. Images may contain personality rights, not categories.

Additionally I find some of the uses not necessary. I can of course remove them but I want to have some second opinions. For instance Tracy Caldwell Dyson in Cupola ISS.jpg is physically in international extraterresial territory. US personality rights or US laws have no jurisdiction. It is taken in the ESA built Cupola module and it would be very difficult to determine what countries laws we are to follow. In the case of 11-11-20-talk-with-sue-03.jpg the use is more jaw dropping.

I understand the purpose of this template and I support the intended use but I see far too many unnecessary uses. "Better safe than sorry" logic shouldn't override common sense.

-- とある白い猫 ^ちぃ？ 05:01, 25 June 2012 (UTC)

There are some bogus uses (see just now File talk:Paul McCartney Arms.svg‎), but it's almost never out of place when added to the description page of an identifiable photograph (including a clear view of the face) of a living or probably-still-living person who has not signed a model release (or similar document)... AnonMoos (talk) 05:08, 25 June 2012 (UTC)

(EC) I have removed the template from the notepad image, nobody is depicted. Regarding the ESA pic, the template is not only about US law, there are personality rights laws in most countries (although I have no idea which apply in space). I would leave the template on that photo. I'm not sure about categories, if the entire category is about a person, I suppose it makes sense to have a warning for reusers on it. --99of9 (talk) 05:10, 25 June 2012 (UTC)

And we just have to wait before someone starts nominating shitloads of these images because "there is no consent". Multichill (talk) 10:07, 25 June 2012 (UTC)

"Consent" is only necessary when you use a photograph to claim that someone is endorsing or affiliated with something which they have not in fact endorsed or affiliated themselves with. The personality rights template is in fact a warning to potential image reusers, in exactly the same way as {{Trademarked}} and {{Insignia}}. It is not a copyright matter, and does not affect our ability to host images on Wikimedia Commons... AnonMoos (talk) 12:30, 25 June 2012 (UTC)

I think Multichill is referring to privacy-related {{Consent}} (which does lead to some deletions) rather than publicity-related consent. {{Personality rights}} is about the latter, but there's a fair overlap between images in both sets if they're taken in private situations. --99of9 (talk) 13:05, 25 June 2012 (UTC)

Well, if he meant something other than {{Personality rights}} in a discussion which had only been about {{Personality rights}}, then he should have clarified... AnonMoos (talk) 18:59, 25 June 2012 (UTC)

IMO the personality rights template is missing in thousands of file description pages, especially with children (example). --Leyo 06:23, 25 June 2012 (UTC)

Going back to the original question, I think it is OK to remove {{Personality rights}} from all categories except Category:Personality rights warning, after they are added to images in the category that might need it. Those should be added on by image basis, not by category. --Jarekt (talk) 13:03, 25 June 2012 (UTC)

This can be done though I'd imagine most (if not all) of the files themselves contain the template but I will make sure. -- とある白い猫 ^ちぃ？ 17:57, 25 June 2012 (UTC)

Personality rights is not an issue of where the photo was taken, it matters where you want to use the person's likeness or name. If you are promoting a product in the U.S., you cannot use the image to connote that Tracy Caldwell Dyson likes the product without her permission. That basic concept is shared by most countries around the world. The template is absolutely appropriate for that image regardless of where it was taken. I'm ambivalent about using the tag on categories, but frankly, the protection also extends to the person's name as well. It's just that since it applies to basically every living person (and in some jurisdictions, much longer), it's really a pervasive situation that people really should be aware of without having to remind them. It's true of just about any photograph of a person, unless they died in the 1800s or something. I'm sure it could be legitimately added to a couple million photos here. File:11-11-20-talk-with-sue-03.jpg was a mistake though. Perhaps a copy-paste from other uploads where it was appropriate. Carl Lindberg (talk) 15:50, 25 June 2012 (UTC)

I am under the belief vast majority of the incorrect taggings are from bulk uploads were a mixed variant of files are uploaded. This alone is not a problem but if too many files have a bogus warning it quickly gets ignored. -- とある白い猫 ^ちぃ？ 17:57, 25 June 2012 (UTC)

• Some of this thread was brought up by the WMF representive. I think most agreed to discuss it here: Commons talk:Photographs of identifiable people section 13. It seems to have stalled out though.--Canoe1967 (talk) 17:52, 25 June 2012 (UTC)
  • I think that discussion was more to do with privacy rights than personality rights. cmadler (talk) 18:19, 25 June 2012 (UTC)

There was discussion of both. I think many get the two mixed up, including the OP. I changed the header to match that after discussing it with him.--Canoe1967 (talk) 18:24, 25 June 2012 (UTC)

Page move

Can someone move Category:Geochelone nigra abingdoni to Category:Chelonoidis nigra abingdoni. I searched the VP history and it said that newbies can't move a page, but I'm not a newbie but I can't do it either(now move option available). Anyway, move it or let me know what to do next! Regards, SunCreator (talk) 22:53, 25 June 2012 (UTC)