Commons:Village pump

From Wikimedia Commons, the free media repository
Jump to: navigation, search

Shortcut: COM:VP

Community portal
introduction		 Help desk Village pump
copyright • proposals		 Administrators' noticeboard
vandalism • user problems • blocks and protections
↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓
🌐 Village pumps for other languages
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.

Please note

  1. 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.
  2. Have you read our FAQ?
  3. For changing the name of a file, see Commons:File renaming.
  4. 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).
  5. 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

Search archives

 

Start a new discussion

Stone village pump in Rinnen village (pop. 380), Germany [add]
Centralized discussion
See also: Village pump/Proposals • Archive
Template: View • Discuss  • Edit • Watch


Oldies[edit]

Should content pages consist of galleries only or also include File pages?[edit]

Historically, the count of "content pages" here at Commons (shown at Special:Statistics and accessible through API requests) has included only pages in the main namespace ("galleries") containing at least one wikilink (matching the classic definition of an "article" used on most Wikimedia wikis). The count of "uploaded files" has been a completely different thing (one that, admittedly, most people care about a lot more than the number of galleries).

Now, following a change I pointed out almost 2 weeks ago, the definition of "content pages" includes both galleries and File: pages containing at least one wikilink. This means the content-page count will increase (almost) as fast as files are uploaded (assuming they result in "File:" pages containing at least one wikilink, which I believe is true when the Upload Wizard is used). As a result, the content-page count has jumped to around 530,000 as I type this — an increase of around 300% since June 6th.

Unfortunately, this current count is almost completely meaningless, since it contains only qualifying (wikilinked) "File:" pages created after the settings change of June 6th. (Already-existing "File:" pages were not "retroactively" counted.)

To get a "meaningful" content-page count, we will need to have the entire wiki recounted from scratch — something that is being done periodically to every Wikipedia, Wiktionary, Wikiquote, Wikisource, Wikinews, Wikiversity, and Wikivoyage, but to my knowledge has never been done to Commons.

I stress that this will need to be done whether we accept the change that was made on June 6th or not. However, we need to decide which definition of "content pages" we want to go with before the recounting is done (since it will be a relatively [or maybe extremely] long and resource-intensive process).

Specifically, then, we need to decide between the following options:

  1. The count of "content pages" should include only galleries in the main namespace. (i.e., request a revert of the June 6th settings change and recount the wiki)
  2. The count of "content pages" should include both galleries and pages in the "File:" namespace. (i.e., accept the June 6th settings change and recount the wiki)

Some things to note about the two options:

  • The first option is how things have been done for several years, up to 6 June 2017. The current count under this scenario "should be" around 130,000 (based on the count before June 6th) and represent how many wikilinked galleries we have. Using this definition would have the debatable benefit of separating the count of galleries entirely from the count of uploaded files.
  • The second option is how things stand as of 6 June 2017, but as just explained above, the current count (around 530,000) is now a mixture of galleries and only-recently-created "File:" pages. It is impossible to know what the count "should be" under this scenario, but I'm guessing it's at least several million. (For comparison, the count of uploaded file is just shy of 40 million.) After recounting, using this definition would have the debatable benefit of eliminating "File:" pages lacking links to, say, uploader userpages and/or local pages explaining licensing terms.
  • It is (also) debatable whether the existence of links on "File:" pages (or even gallery pages, for that matter) is even a meaningful way of qualifying such pages as "content". Thus, we may want to consider switching to the "any" method of content-page counting (counting all pages in "content namespaces" rather than only those containing a wikilink).
  • As discussed in the Phabricator task that precipitated the settings change, the intent of the change was to allow Special:Random and Special:Nearby to work with both galleries and files. Currently the navigation menu (left side of page) contains a "hardcoded" link to Special:Random/File rather than Special:Random. With the change, Special:Random now brings up (presumably) either a file or a gallery page. Is this desired? Do we care? (As for Special:Nearby, I can't say much since I've never worked with that.)

So… comments? Should I open an RFC about this? - dcljr (talk) 04:30, 21 June 2017 (UTC)

@Dcljr: I agree that a "content page" on a media repository should probably include the media itself but what practical effect would this have? We already have a magic word for the number of files and it's shown on the Main Pages, so anyone could easily have an idea of how big the repository is. —Justin (koavf)❤T☮C☺M☯ 04:54, 21 June 2017 (UTC)
The "content pages" count shown at Special:Statistics is also accessible through {{NUMBEROFARTICLES}} on-wiki and tracked at stats:. Many people also gather "content pages" counts for various Wikimedia Wikis (including this one) through the API. If the wiki is going to report its count of "content pages", however defined, it should report the correct count, right? That's all I'm saying. We just need to decide which "correct count" we want to use. - dcljr (talk) 05:16, 21 June 2017 (UTC) Edit: Oops… I forgot: stats: uses it own, different definition of what constitutes "content pages", and does not rely on wiki-reported counts. - dcljr (talk) 06:36, 21 June 2017 (UTC)
I don't really care one way or the other, but if the File: namespace is included, the Data: namespace should probably be included as well. --El Grafo (talk) 06:54, 21 June 2017 (UTC)
Clearly the change should be reverted (+1 to dcljr).--Kopiersperre (talk) 13:02, 23 June 2017 (UTC)
@Kopiersperre: "Clearly" because why? - dcljr (talk) 21:21, 29 June 2017 (UTC)
What about file pages that don't use [[normal links]] but do have other kinds of content? When I upload images (I'm just past twenty thousand of them), I tend not to use normal links; instead, I provide lots of {{w}} links to en:wp. For example, my most recent upload, File:Marlbrook near Glasgow.jpg, transcludes {{w}} six times in a 32-word description. Nyttend (talk) 18:32, 24 June 2017 (UTC)
Interwiki links do not qualify pages as "content pages" under the "link" definition being used here at Commons, only "normal" internal wikilinks. Specially processed links like [[Category:]] (to place a page into a category) or [[File:]] (to display a file) don't count either, although the "normal wikilink" versions starting with colons, like [[:Category:]] and [[:File:]], do count (but we don't want to use this fact to "game" the system into counting pages that would otherwise not be counted — we should choose the settings for counting method and content namespaces that best reflects our current practices/opinions about content). - dcljr (talk) 22:11, 25 June 2017 (UTC)
Just a note to say I'm investigating how to reset the count. Will do that regardless of the decision around the value however my goal is to make sure the chosen value is well documented (since it is not obvious) to avoid this happening again. Note that the page Special: Nearby and default behaviour of Special:Random and other things depend on the value. The former will be broken (and probably disabled) if we need to switch it back. Something to consider. Jdlrobson (talk) 14:25, 26 June 2017 (UTC)
I don't know what Jdlrobson is finding out about fixing the count, but it looks like the opinions expressed here are leaning towards accepting the settings change (mostly because of a lack of strong feeling either way) — especially since the only user who has explicitly said the change should be reverted (Kopiersperre) has not provided any reason why that should be done. I am concerned, however, that the sysadmins might not want to go to the trouble of recounting the wiki (which may take many hours—I'm not really sure) without more input from the Commons community about this. If I do decide to open an official RFC, do I have to move the discussion away from this page? - dcljr (talk) 00:39, 5 July 2017 (UTC)
I'll investigate what's needed to reset the count and get back to you. No RFC necessary. Note, there are no deployments this week so this is not likely possible until next week. Jdlrobson (talk) 18:05, 5 July 2017 (UTC)
Update this has now been done. The count should be correct again and now includes file pages. Jdlrobson (talk) 22:57, 5 July 2017 (UTC)

Statistics is just one part of it. At the very least reverting such a change would fix timeouts in Special:shortpages and special:longpages, in the short term (https://phabricator.wikimedia.org/T168010). It is pretty obvious that aside from counting pages like that, it now also fetches files. So it is now timing out due to the fact that it is an inefficient query page, and also due to the many stored files (which is combined with pages in namespace 0). 22:58, 5 July 2017 (UTC) —Preceding unsigned comment was added by 197.218.89.210 (talk) 22:58, 5 July 2017 (UTC)

Why does it not surprise me that an actual argument is offered right after the recounting is done? (!!) Fortunately, it looks like recounting doesn't, in fact, take hours (AFAICT), so whatever needs to be done to fix whatever problems remain, the wiki can (apparently) be quickly recounted again in the future, if necessary. - dcljr (talk) 00:55, 6 July 2017 (UTC)
BTW, the English Wikipedia also has a huge number of pages to look through (although all in NS0), and it doesn't seem to have any problems showing "live" lists of en:Special:ShortPages and en:Special:LongPages. Why is Commons unable to handle it? - dcljr (talk) 00:58, 6 July 2017 (UTC)
@Dcljr: English Wikipedia has ~5.4M pages to sort through, we now have ~40.5M pages to sort through. Perhaps another index or two would help.   — Jeff G. ツ 01:11, 6 July 2017 (UTC)
Touché… Presumably, any "good ideas" would be welcome at the relevant Phabricator task. (Not knowing much about it, my only suggestion would be to make it cached instead of live.) - dcljr (talk) 07:49, 6 July 2017 (UTC)
@Dcljr: Thanks, I commented there.   — Jeff G. ツ 16:29, 8 July 2017 (UTC)

Interested parties (which I continue to wish were more numerous!): Note that the problem causing Special:ShortPages and Special:LongPages to fail seems to have been fixed, but another problem has been reported at phab:T170687 (after being discussed briefly in phab:T167077 and phab:T168010):

  • Special:ShortPages is no longer useful for vandalism/test-edit fighting because it now contains a ton of very small File: pages (containing only short template calls) that are (presumably) nevertheless well-formed pages.

Some folks at Phabricator want more input (at phab:T170687) from the Commons community about what has changed around here (especially the functionality/usefulness of other Special pages) as they consider what might be done in response to this problem. @Jdlrobson: Please add whatever additional information you think is important for the community to consider. - dcljr (talk) 12:03, 15 July 2017 (UTC)

According to mw:Manual:$wgContentNamespaces, the following special pages are potentially affected by changes to that variable (which is the settings change we've been talking about): Special:Random, Special:Nearby, Special:Statistics, Special:AncientPages, Special:DeadendPages, Special:FewestRevisions, Special:LonelyPages, Special:MostCategories, Special:MostInterwikis, Special:ShortPages, Special:LongPages, Special:UncategorizedPages, Special:WithoutInterwiki. So, have people noticed any of these pages losing (or perhaps gaining) utility after the settings change of June 6th? - dcljr (talk) 13:19, 15 July 2017 (UTC)
I think the best thing for now is to revert the change that leaded to all these problems, so that we could finally use Special:ShortPages again. It will show a lot of test-pages now the report has been out of service for several weeks. And then maybe reapply the change as soon as it is in a state in which it does not break several reports. Jcb (talk) 21:26, 15 July 2017 (UTC)
Reverting breaks various other things, so that's not really an option here. We've heard Special:ShortPages is not useful in current form - so fixing that is now the top priority, but please let us know if there are other special pages that are unusable. Right now we're considering making it possible to use Special:ShortPages on individual namespaces e.g. you'd be able to get reports of all short file pages or all short pages in the main namespace or all short pages in any other namespace. Would that be useful? Would that solve this problem? Jdlrobson (talk) 16:39, 17 July 2017 (UTC)

Template User:Fæ/IWM[edit]

Shouldn't this be in the template namespace (used more than 51,000 times)? @Fæ: for your information. --тнояsтеn ⇔ 05:41, 6 July 2017 (UTC)

Project specific ingestion templates don't have to be as there are no rules. The template is 4 years old and I would recommend others use standard templates. --Fæ (talk) 07:45, 6 July 2017 (UTC)
could you please modify the template to accept wikidata field ? Slowking4 § Sander.v.Ginkel's revenge 02:58, 8 July 2017 (UTC)
What do you mean with "ingestion templates"? --тнояsтеn ⇔ 07:55, 10 July 2017 (UTC)
@Thgoiter: It's how we describe a custom template created to replace the standard information template for batch upload projects. People often use these if the standard templates do not have fields that appear to match their source metadata. Over the years I have moved against this as it has built up a maintenance headache should we wish to standardize image pages, such as harmonizing with wikidata. See Category:Data ingestion layout templates for lots of examples. --Fæ (talk) 06:53, 15 July 2017 (UTC)
OK, ingestion didn't make sense to me here but I'm only EN-3 ;-) Aside from the question whether a custom template is useful or not, back to my starting point: is the user namespace the right place for a template that is used that widely? --тнояsтеn ⇔ 07:10, 15 July 2017 (UTC)
The answer is maybe not, however we are talking about a stable collection that has been here for several years. Unless this is a current material issue, there is more risk in shaking the tree for the sake of it, compared to admiring the tree and walking on. --Fæ (talk) 07:22, 15 July 2017 (UTC)

Self promo[edit]

Hugo Komba Homme d'affaires Congolais.jpg

Who is this? And is this not self promotion?Smiley.toerist (talk) 10:22, 7 July 2017 (UTC)

Well, if you think the description is promotional, you can edit it. Or if you consider the whole image not to be realistically useful for an educational purpose, you can nominate it für deletion as being out of COM:SCOPE. In both cases IMHO not really a topic for the village pump. --Rudolph Buch (talk) 10:45, 7 July 2017 (UTC)

I suppose there is no abundance of businesspeople of Kinshasa at Commons, so very much in scope. The description should be improved, though. --LPfi (talk) 21:00, 7 July 2017 (UTC)

  • The up loader’s user name goes against policy. Note: both hands are in view and are so are not operating the smart phone, so up-loader is almost certainly not Hugo Komba Homme himself. So I don't think we even need to get into whether it this image is self-promotional (this is not WP so different guidelines apply here) – the image licence though, is gravely suspect. Suggest we put it up for deletion due to total lack of provenance. So, a thank-you to User:Smiley.toerist for questioning it.P.g.champion (talk) 16:10, 9 July 2017 (UTC)
    • P.g.champion, you maybe mean Commons:Username policy, that link was for the policy of a different project. I can't quite see how a person having their full name as a username is against policy though, can you explain more? seb26 (talk) 17:29, 9 July 2017 (UTC)
    • The image seems intended for promotional use by HK. It could have been taken with a timer, with somebody else pushing the trigger or as a work for hire, but I think demanding proof about such details, when allowing publishing on Commons should have been an intended use case when making a contract, is nitpicking. --LPfi (talk) 16:21, 13 July 2017 (UTC)

Personal documents hosted in Commons for Wikipedia article development?[edit]

Thanks @Daphne Lantier, Maile66: for starting this conversation with me.

Wikipedias of all languages have perpetual problems with people wanting to share personal information. Here are some examples of issues which continually arise:

  • name corrections, either for spelling, name changes for marriage, name changes for any other reason
  • gender changes, as for individuals who were known by one gender and now are known by another
  • mundane job changes, as when Wikipedia reports that someone works for one organization but then they join another
  • marriages, as when Wikipedia reports that people are married, but then they get divorced, or marry someone else, or whatever
  • residency

There is currently no particular name for this class of information on Wikipedia. Lots of this appears in an "infobox", which is the box on the right side of the screen (desktop view) for biographies. This information typically also appears in the body of the article.

When information enters Wikipedia it comes from reliable sources. Wikipedia editors avoid doing original research to seek out this kind of information from primary sources. However, once this information gets into Wikipedia, then a sort of liability arises in which the subjects of biographies sometimes object to Wikipedia carrying outdated information. To correct this, many people seek to offer proof to correct Wikipedia.

At Commons:Deletion requests/File:Stewart and Constance Lake's marriage certificate.jpg I have someone's submitted proof of a marriage. The user submitted this primary source of information to advance discussion at en:Veronica Lake. Lake as a United States actress and celebrity. The document purports that she had a marriage after she left the public eye. This marriage was never published or the source of any media documentation. A Commons user requested that the document be deleted for being a hoax. There has never been a discussion on whether the document is or is not a hoax. I am not sure if Commons even should host such discussions. Currently, the marriage certificate is deleted.

There are a few issues here -

  1. I do not think anyone in Wikimedia projects wants to get involved in original research. However, it might be a cross-wiki concern if the public seeks to submit primary documents as evidence to change articles. Should the Commons community form an opinion on this?
  2. In this case, the user has a document which they want to share to update some fact in Wikipedia, in this case a marriage. Is it within Commons' scope to host such a document?
  3. In this case, some wiki community members have made the claim that the document is a hoax. This does not rise to the level of accusation, but instead, the argument was that the documents tell a very different story than other published sources and without extraordinary evidence and research, some people would feel challenged to accept the information in this document. In what ways should the Commons community issue opinions on whether documents of this sort are authentic?

At Commons:OTRS private ticket:2015121110001052, a user writes in requesting that the files be undeleted.

Could I get thoughts from others on what should happen next? Blue Rasberry (talk) 18:46, 7 July 2017 (UTC)

  • I think that where these have bearing on Wikipedia articles, they are probably within Commons' scope.
  • As for the specific document, though, if it is not a hoax then the copyright claim that is on it as a watermark is copyfraud. You can't copyright a marriage certificate. - Jmabel ! talk 19:09, 7 July 2017 (UTC)
Indeed the document itself, if blank of any infos should be {{PD-CAGov}} as it comes from the California Department of Public Health. Christian Ferrer (talk) 19:27, 7 July 2017 (UTC)
  • Technically, any file that's in use on Wikipedia is in scope for Commons, in the absence of copyright problems. Also, if it relates to a notable person I assume it would always be kept. However, I'm not sure that this is a great process to use. Commons has no way to determine if a particular file is a genuine copy. Some kind of process like OTRS could be used, where people can establish their identity (somehow) and provide the information while keeping the actual documents semi-confidential. This would probably be useful for all kinds of "personal correspondence" type information on Wikipedia. --ghouston (talk) 08:11, 8 July 2017 (UTC)
  • In scope. The educational value of primary sources can be assessed by their validity or notable non-validity (like the fake Hitler diaries). Consequently anyone uploading a public record like this would do well to include an explanation of sourcing which may be verifiable. Marriage certificates in the USA or UK are pretty easy to verify, someone should put the spadework into verification if they care about it. As for giving obituaries more credence than a marriage certificate, unlike registrar verified certificates which can be retrospectively checked, there is no review process and many obituaries will contain mistakes, propagated myths and hearsay. --Fæ (talk) 08:20, 8 July 2017 (UTC)
  • I'm not sure what procedures journalists use for verification. If they are interviewing somebody, I'd hope they are reasonably certain they are talking to the right person, and not somebody impersonating them. But it may be that such impersonation isn't something they encounter often enough that they need to bother making any formal checks (unlike on Wiki projects where the choice of user name isn't much guarantee of anything.) I'd also guess they just record what the person says without insisting on verification, e.g., if they obtain any information like educational or vocational history. The articles they write then become acceptable references for Wiki purposes. If there were trustworthy Wiki journalists who could go out and interview people, after verifying their identity, would that be any less reliable than something published in traditional media (which does of course make mistakes)? --ghouston (talk) 03:09, 9 July 2017 (UTC)
  • One thing that should be mentioned here, is a tip off in this uploader's claim. Please see Talk:Veronica_Lake#Notes_from_Stewart_Lake.2C_the_last_husband_of_Veronica_Lake. The person says his name is Lake, and that he is the reason she changed her name to Lake. He says they were together from 1955, and got married in 1971. Her career under the name Veronica Lake is well documented. 1941 Life magazine article she was known as Veronica Lake then. American Film Institute catalog of feature films is a database of the film industry, and lists back to her earliest movies when she originally used the name Constance Keane (her stepfather's name). It does not take OR to figure out she was known by the name Lake most of her life. Maile66 (talk) 11:59, 9 July 2017 (UTC)
Not sure why Pristurus deleted my post, but I'm adding it back. Maile66 (talk) 19:57, 9 July 2017 (UTC)
Sorry, my mistake. It happened unintentionally. --Pristurus (talk) 20:45, 9 July 2017 (UTC)
It is likely that they had an older tab open with their reply, as they accidentally deleted other comments made after the fact. I have attempted to fix this in my latest revision with this comment. seb26 (talk) 20:49, 9 July 2017 (UTC)
No harm, no foul. Thanks for explaining. Maile66 (talk) 22:07, 9 July 2017 (UTC)
  • @Bluerasberry: If the end result here is no clear directive, the above suggestion that this be fielded by OTRS seems like a good way to go. Whether or not any submission is a hoax, I'm sure Commons doesn't want to upload something that is. Anybody with a computer can create something that looks like an official document but isn't. The user above who suggests the uploader should include an explanation of sourcing which may be verifiable, seems reasonable. I don't see how it's your responsibility to figure that out. Especially since on Wikipedia the uploader has made threats of legal action. OTRS might be a better way to go. Maile66 (talk) 11:46, 11 July 2017 (UTC)
  • @Bluerasberry: Gaming the system, noticed because of my AIV work on Wikipedia. Posting this on the Commons VP thread for the record, and my Commons talk page so it's there indefinitely for my own reference. I just noticed on the Veronica Lake talk page how this went down, and I think some safeguards should be in place so it doesn't happen this way again. The original uploader got you to be the one to post to the talk page. In such a situation, the person who contacted you will not be reverted/blocked from that talk page. It falls on your posting, and you did nothing but respond to a request. That loophole needs to be changed so it doesn't happen again. Maile66 (talk) 12:10, 13 July 2017 (UTC)

July 08[edit]

How do I add images that appear in two categories to a third category?[edit]

Hi

We want to include images taken in Biosphere Reserves in the national Wiki Loves Earth competitions in the Wiki Loves Earth Biosphere Reserves competition.

Please can someone tell me how to copy any images that are in a subcategory of Category:Biosphere_reserves_by_country that are also in a subcategory of Category:Images_from_Wiki_Loves_Earth_2017 to Category:Images_from_Wiki_Loves_Earth_Biosphere_Reserves_2017.

Please note that Category:Images_from_Wiki_Loves_Earth_Biosphere_Reserves_2017 is already in Category:Images_from_Wiki_Loves_Earth_2017

There are likely 1000s so doing it manually isn't an option.

Many thanks

--John Cummings (talk) 14:24, 10 July 2017 (UTC)

If I knew such a tool, I would be so happy. --MB-one (talk) 11:28, 13 July 2017 (UTC)

Purpose of Template:Custom license marker[edit]

What’s the intended purpose of template {{Custom license marker}}? (ping @Matma Rex). — Speravir – 21:39, 12 July 2017 (UTC)

@Speravir: Its utility is marginal, at best. It indicates that, while preparing to upload, the uploader chose from the Upload Wizard a license which was not one of the defaults. Multiply that marginal utility by 539091 transclusions, and you might have something. However, given the demise of the Upload Wizard's cat, this template could probably go off into that good night without significant loss. We would probably need a VPP to have the Upload Wizard stop using it and possibly related templates. It is also a security risk.   — Jeff G. ツ 22:40, 12 July 2017 (UTC)
“Utility marginal, at best” and “this template could probably go off into that good night without significant loss” are actually my thoughts, as well, and my intention for asking here. — Speravir – 22:55, 12 July 2017 (UTC)
UploadWizard actually inserts {{subst:Custom license marker added by UW}}. I agree it is silly. It's been here since forever though (phab:rSVN103557), and apparently was discussed back in the day on Commons:Village pump/Archive/2011/11#Multi-file selection and more for UploadWizard (I got this link from that template's description page). If you want it gone, please just file a Phab task and I'm sure Multimedia folks be happy to oblige (I mostly work on VE these days). Matma Rex (talk) 14:23, 13 July 2017 (UTC)
@Speravir, Matma Rex: Thanks, I raised a concern at phab:rSVN103557 as an initial step.   — Jeff G. ツ 15:50, 13 July 2017 (UTC)
Honestly, probably no one will ever see it there – we don't use Phabricator's Diffusion (diff viewer) much, it's just yet another mirror of the repositories; we mostly use Phabricator's Maniphest (task/bug tracker). And this is a change written by a person who hasn't been active for years (and doesn't even have an account on Phabricator). Just file a task, they get looked at. Matma Rex (talk) 17:22, 13 July 2017 (UTC)
(Edit conflict) @Jeff G., Matma Rex: Thank you, both. So, the intention was fine, but no one seems to care about it anymore. (And I could have safely delete it in these cases I stumbled over it.) Because this is some kind of license review, it probably at least should have been mentioned in COM:LR and perhaps been added to {{LicenseReviewMenu}}. BTW, Jeff, internal search: file: hastemplate:"custom license marker". And also ping @NeilK, though his latest activity in all Wikimedia projects was here on Commons in January this year. — Speravir – 17:46, 13 July 2017 (UTC)
Proposal for removal of Custom License Marker from Upload Wizard
The Upload Wizard currently adds {{subst:Custom license marker added by UW}} to file description pages it helps create. This results in {{Custom license marker}} with time parameters filled in being added to those file description pages when substed. It was supposed to add those file description pages to dated subcats of Category:UW uploads using a custom license, but that never happened, so now there are ~543,034 files in Category:UW uploads using a custom license which no one has checked. This practice of template addition should cease, for reasons explained above.

Custom License Marker votes and discussion[edit]

  • Symbol support vote.svg Support as proposer.   — Jeff G. ツ 12:27, 14 July 2017 (UTC)
  • Symbol support vote.svg Support as the one who started this thread. — Speravir – 22:26, 14 July 2017 (UTC)

July 13[edit]

On Wiktionary[edit]

Can someone create a {{on Wiktionary}} as a complement to {{on Wikipedia}} ? -- 65.94.42.131 05:06, 13 July 2017 (UTC)

Where do you want to use it? Ruslik (talk) 20:22, 13 July 2017 (UTC)

Uploading photos with OTRS-pending template[edit]

I am trying to upload som pictures under License: CC0, and with a OTRS-pending template. I've read some "how to's" but I'm afraid to make a mistake. So here's my question: Am I supposed to put the template {subst:OP} to the "Source" field when uploading? On COM:OTRS it says: "place the tag {subst:OP} ("OTRS Pending") on the file description page", is that the same? And how will I or the author get the e-mai ticketnumber? I might seem pretty lame, but I've never uploaded a photo to Commons before:) --Sabine Rønsen (WMNO) (talk) 09:32, 13 July 2017 (UTC)

Sabine Rønsen (WMNO), yes, the {{subst:OP}} template is the best thing to do, and those parts of the page are indeed referring to the same thing. When you send an email to OTRS, you will get an automatic response saying "email was received" and it will assign you a ticket number which you can keep for your reference. That's all you do to the file page, OTRS agents will do the rest. When it has that template on the page, other users know that it is essentially a grace period because OTRS is not instant and is backlogged at the moment so there are lots of images waiting weeks. So it will not be deleted instantly.
As for whether or not you need OTRS, it's only required if you are uploading an image that (a) is not your own work and (b) it was published elsewhere online or in print beforehand with "All rights reserved" or without an accompanying free license. Are these photos your own work? Just jump in and upload them, select your license, and that's it, no OTRS required. Feel free to ask anymore questions about this if you are unsure. seb26 (talk) 13:48, 13 July 2017 (UTC)
@Sabine Rønsen (WMNO): I've approved the OTRS ticket in question, and modified the file description pages accordingly. --Jonatan Svensson Glad (talk) 22:12, 15 July 2017 (UTC)
Thank you seb26 and Jonatan Svensson Glad! That was really helpful:) --Sabine Rønsen (WMNO) (talk) 07:21, 18 July 2017 (UTC)

Setting a convention for when DMCA notices are required[edit]

Recent deletions of photographs, which were officially released by the White House, highlight how some of our most reliable sources of public domain photographs of notable people and current events can be challenged. The process for a copyright holder to challenge these releases should remain simple, but having the decision about our highest profile images being made behind closed doors in a non-legally meaningful and informal procedure does not sit well, and puts undue pressure on volunteers. I propose below that we agree a slightly higher, but reasonably non-bureaucratic, standard for the evidence required for the Commons community to accept that "irrevocable" releases of this type are correctly, and legally, withdrawn with associated public records.

Proposal for a DMCA notice requirement
Photographs or other media uploaded to Commons with reliable evidence of a public domain release from high profile government or government agent sources,1 where an alleged copyright holder has requested a withdrawal of the release, will require a public DMCA notice to WMF legal per wmf:DMCA takedowns. The Commons community may avoid this process in non-controversial cases by consensus in a deletion request, for example where the media is assessed as out of scope for the project.

Notes

  1. "high profile government or government agent sources" includes the White House website, all U.S. Federal agencies or federal funded bodies such as the Library of Congress, Government recognized national agencies of non-U.S. countries such as the U.K. Ministry of Defense (when an Open Government License applies) and widely used state supported sources such as multi-national agencies like UNESCO. Where there may be doubt that this requirement applies, it will be presumed to apply to any media from an official source when raised in a deletion request.
  2. For background on the DMCA refer to Digital Millennium Copyright Act.
  3. Case studies: Official portraits of Donald Trump, Mike Pence official portrait

Votes and discussion[edit]

  • Symbol support vote.svg Support as proposer. --Fæ (talk) 10:51, 13 July 2017 (UTC)
  • Symbol support vote.svg Support A step in the right direction. --Yann (talk) 11:45, 13 July 2017 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose Any agency, government body, or administration run by people not trained in copyright law which releases others' materials which could be covered by copyright law as its own should not be trusted to license those materials properly. It truly saddens me that this includes the current administration of the country to which I have pledged my allegiance. Requiring actual rightsholders to file DMCA takedown notices raises an unfair, costly, time-consuming, and public identity-revealing hurdle or barrier to enforcing protection of their rights, which is not what this project is about; we are supposed to be protecting the rights of actual rightsholders. I agree with Nick.   — Jeff G. ツ 12:38, 14 July 2017 (UTC)
  • Comment. I am not sure what you mean "public DMCA notice"? The law certainly does not require such notices to be public. So, what you are proposing may go against the law. In addition why the reasons for deletions are limited "media as out of scope for the project"? In some cases it may be fairly obvious that the media is not properly licensed. Ruslik (talk) 20:17, 13 July 2017 (UTC)
  • Symbol support vote.svg Support completely agree with nom. Corkythehornetfan (ping me) 21:44, 13 July 2017 (UTC)
  • Oppose Symbol oppose vote oversat.svg Strong oppose This sound like a good idea, but it might go against our current policies, and might be redundant. Only if we know a media is free, we can store it. Per COM:PRP we should delete files with resonable doubt, and despite the source, that can be gathered by information presented on or off wiki, such as on OTRS. If no such doubt exists (which in the example given it does), we will already not delete it (and refer to DMCAs; if copyright owner claimsit is a violation there is doubt). We should not single out specific sources which can overrule a well-established policy(PRP), which then in turn may make us keep a file where resonable doubt exists just because of the source. f doubt exists we should delete it no matter what. --Jonatan Svensson Glad (talk) 21:48, 13 July 2017 (UTC)
  • Symbol oppose vote.svg Oppose This is absolutely inappropriate, and the wording Fae has chosen is bloody awful. I would point out, firstly, that the images concerning Donald Trump and Mike Pence were never claimed as a public domain release (i.e resources produced by an employee of the Federal Government). The White House website claims they were released under the CC-BY-3.0 licence whilst the photographer claims he did not authorise their release under the CC-BY-3.0 licence. We're stuck in the middle of a contractual dispute between a photographer and The White House (and possibly, The Trump Organization) but we have no reason to believe the photographer is lying to us. I suppose we could ask for a DMCA notice but that's really not ideal - we're not here to be bloody minded, obstinate and awkward. We exist to provide free and open source content, not just to our sister projects, but also to third party re-users downstream. Those re-users may not benefit from the provisions of the DMCA and may not be eligible to receive a DMCA notice, to force a DMCA notice when a problem is politely brought to our attention is failing those re-users downstream. We should be protecting them by removing material quickly, efficiently and effectively when a legitimate concern is raised, even if a DMCA notice is not immediately forthcoming - that's why we have our Precautionary Principle (which this proposal would effectively undermine).
    The 'public domain release' wording is badly written. UK Government material released under the Open Government Licence is not a public domain release, it's a modified version of the Creative Commons Attribution licence (with which it's compatible) and the same applies for other Government released material from numerous agencies globally, where a standard Creative Commons licence or more general Attribution licences/permissions is provided. This means there's the usual Creative Commons disclaimers, right to terminate the licence etc, which also needs to be factored into this proposal.
    We also know Governments and their employees are often pretty lax at noting an image was provided by a supplier or outside agency. We pretty regularly remove material which comes from a Government feed, but is material we know was created by a third party - one example is excerpts from the manufacturer supplied aircraft maintenance instructions which is reproduced in NTSB and AAIB reports.
    I don't think playing hard-ball is going to be good for us and it's certainly not going to be good for our re-users. We should be encouraging early, open and productive discussion with people who have issues about 'their' material being used on Commons without permission, working to try and persuade them to release under a free licence, to make other material available or to change their policies on re-using material. Deleted material isn't lost forever either, it can be restored if/when clarification is sought and received. I do not think this is a constructive proposal, and certainly don't support it in its present form. Nick (talk) 09:48, 14 July 2017 (UTC)
    Feel free to recommend some wording changes, so it applies more narrowly. I'm not wedded to the specific words and I am not a lawyer. With regard to your comments about DMCA, if the copyright holder asks for a takedown it works, so scenarios you mention where complainants "may not be eligible" sound like courtesy deletions or complaints by non-copyright holders. The WMF, and hence Commons, shall comply fully with the DMCA so long as the project is hosted in the USA.
By the way, nothing in this proposal is "hard ball". It does not bypass the precautionary principle, in fact there's nothing to stop a file being removed in line with our policies even if we ask the claimed copyright holder to raise a DMCA. If a copyright holder really wants to stop a previously mistakenly released photograph from being propagated around the internet, especially after being hosted on Commons for any length of time, then any decent IP lawyer will tell them to fill out a simple, and free, DMCA notice to send to every host that publishes it. --Fæ (talk) 12:21, 14 July 2017 (UTC)
Such advice generally would not be free. The WMF outs complainants' names and websites.   — Jeff G. ツ 13:07, 14 July 2017 (UTC)
The point being that a complainant can waste their time on an IP lawyer, or they can just fill out the free forms. The WMF legal does not always publish everything if there are privacy issues, one could imagine this applying for, say, photographs with nude subjects. If a complainant were in doubt, they can correspond with the WMF about the notice before any public action was taken. --Fæ (talk) 13:13, 14 July 2017 (UTC)
  • Symbol support vote.svg Support All this proposal does is simply make what has always been done in practice MORE efficient. And this benefits BOTH the project and the copyright holders. The way the system has always de facto worked is that when you upload pics from a reliable or official source (e.g. Library of Congress), you go with the license that the site claims it is by default. You simply have to unless you find evidence suggesting otherwise. I don't know the exact statistics, but I bet out of the thousands of public domain images released by government sources, only a relatively very small number get the licensing wrong. Of course you're going to have outliers. And that's when the DMCA comes in as a good tool for this purpose. Spellcast (talk) 12:03, 14 July 2017 (UTC)
  • Symbol oppose vote.svg strong oppose per Nick, and because the comments by those in OTRS appear to show they have a clue whereas the keep comments at the DRs appear to show a lack of clue. -- Colin (talk) 14:27, 14 July 2017 (UTC)
  • Symbol oppose vote.svg Oppose "Government and government agent sources" are expected to maintain a higher standard. But here in both cases, they are found to be unreliable. Jee 06:10, 17 July 2017 (UTC)
  • Symbol oppose vote.svg Oppose Agree with Nick, also per COM:PRP. We don't need to desperately cling to any image that may have been associated with a free license by mistake or where there is a dispute; we should be cautious and always have potential re-users in mind. Gestumblindi (talk) 23:08, 18 July 2017 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose: This steamrollers basic community principles and is barely even coherent. It's obvious that some people didn't like the outcome of Commons:Deletion requests/Files in Category:Official portraits of Donald Trump and Commons:Deletion requests/File:Mike Pence official portrait.jpg, and that the "solution" is the nuclear option: Take away the right of the community to judge content on its individual merits on-wiki, undermining a basic pillar of every Wikimedia project. The proposal also just poorly-written, with unclear, self-contradictory language. It's a drama bomb waiting to have the fuse lit. So, one at a time:
    1. The principle is awful: This proposal blatantly protects license laundering and derivative works violations by the institutions who are least likely to face any accountability for doing it, under the utterly backwards theory that random lowest-bid web-design contractors who copy-paste a boilerplate licensing phrase from another website months in advance are somehow blessed with government authority to rule on copyright status, and Commons users, administrators, and OTRS members who deal with this sort of thing all day are all fools and need to be ignored. It proposes that the mere whiff of casual government website boilerplate garbage vetoes all the proof in the world, and the only way out is to get some specific copyright owner to harass the Wikimedia Foundation staff with a DMCA takedown notice, which most copyright owners would call legal action. This proposal directly undermines two of Wikimedia projects' basic principles that have been around since the early days:
      • that the burden of proof (verifiability on Wikipedia, licensing on Commons, etc.) is on the person wanting to keep the content, not the person wanting to delete it; and
      • that we do not resort to — let alone force someone into — off-wiki behavior or legal threats/action to get just and fair results on-wiki.
      One of the main reasons for Wikimedia's legal reputation, and why it doesn't get pounded by the copyright lobbyists, is that the Wikimedia projects are known to be self-cleaning: Getting copyright violations removed is nearly as easy as adding them, and the community has been doing this sua sponte since the founding, without even the need for a copyright holder to complain first. This is strengthened by the Commons:Project scope/Precautionary principle, which is that we don't put the burden on the copyright holder or license doubter; we put it on the uploader and those who want to keep the content. Despite Fae's repeated claims (also in previous deletion discussions) that his proposal doesn't violate the Commons:Project scope/Precautionary principle, this proposal is pretty much a direct attack on PRP: The proposal forces administrators to protect files, on the fake theory that "nobody will bother" to care even when lots of people already care, because the copyright holder hasn't actually burdened the WMF in the form of a DMCA takedown. And despite Spellcast's claim, it is not "what has always been done in practice": We've always deleted files that have more than frivolous/nominal doubts. And, more importantly than that, what we have always done in practice is allowed the community to decide individual content on the merits in deletion discussions. And we have always done everything possible to avoid a DMCA takedown on individual items that the community has doubts about. What we have never done is passed a policy that the community and administrators aren't allowed to consider whether content has a proper license or not, or that the community and administrators are prohibited from considering whether the copyright status is valid. We also, as far as I know, have never passed a policy declaring files to be public domain even in the face of evidence to the contrary, without consulting WMF's legal team and having their consensus agreement also (e.g. {{PD-Art}}), or banned an entire relevant topic and forcing all discussion to "go bother the WMF" without consulting the WMF and having their agreement (e.g. emergencies). And before someone says that it won't burden the WMF because there won't be that many files: If there won't be that many, then there's no reason for this new policy, other than to force a small number of files to fit a small number of users' wish to prevent discussion. Prohibiting discussion on a basic element of content is not an acceptable "streamlining" on any wiki.
    2. The wording's poor: The policy's wording itself appears to be misleading in the first sentence, and has self-contradictory clauses that make it interpretable as everything from null and void all the way to open season to ban anyone who nominates potential copyright violations that ever touched anything that vaguely looks like the government. I'm having trouble believing that Fae is even the author: It looks like it's written by someone who has gotten rusty on Commons policy.
      1. It says "reliable evidence of a public domain release from high profile government or government agent sources" but then has a footnote that says that it means "the White House" (which is exactly who consensus already decided was not reliable evidence in at least two cases), "all U.S. Federal agencies" (storm photos from citizen photographers on the NOAA website are regularly deleted on Commons), "or federal funded bodies" (every state and local governments? Planned Parenthood?), "such as the Library of Congress" (everything any Library of Congress division says is possibly public domain, even if it's obviously miscoded at the moment and someone notices it, is reliable and can't be deleted?)
      2. The footnote then says "Where there may be doubt that this requirement applies, it will be presumed to apply to any media from an official source when raised in a deletion request." What is meant by "where there may be doubt ... it will be presumed" — a rebuttable presumption (in which case it's not presumed because it's in doubt), or an irrefutable presumption (in which case it doesn't matter whether it's in doubt)?
      3. "where an alleged copyright holder has requested a withdrawal of the release" — So this only applies when the copyright holder has requested a withdrawal of the release. Excellent: That means we can still discuss and delete government works as copyright violations just like before, since this policy won't apply unless it's the copyright holder that has requested the "withdrawl". Except, something tells me that's not what was intended.
      4. "The Commons community may avoid this process in non-controversial cases by consensus in a deletion request" means it must be unanimous: If it's not, it's controversial; any controversy at all invalidates the discussion. Fortunately, we have the following:
      5. "for example where the media is assessed as out of scope for the project." Commons:Project scope#Must be freely licensed or public domain has obviously been part of project scope for as long as I can remember; I have no idea why Fae (or other long-time users who are voting to support this) wouldn't have caught this instantly. So works improperly declared by a government are still out of scope. So I guess this means this whole proposal is void, since "assessed as out of scope" is declared an explicit example of "non-controversial cases" and therefore "The Commons community may avoid this process" all the time. (Again, something tells me that's not what's intended.)
      So, in summary: This proposal is so badly worded as to be interpretable multiple ways at once, the result of which will be that people will nominate files without regard to it, administrators will start banning people for doing it, and what the community will do every time this happens will be exactly the opposite of "efficient". And in case it's not obvious, this policy means that the only route for normal users, bureaucrats, and OTRS members to appeal will be to bother the Foundation directly, which will probably make the WMF think that if Commons is willing to sign away their own scope, ban reporting of copyright violations on-wiki, and assign more burden (forcing DMCA as easiest path) to the Foundation staff without asking first, maybe Commons isn't fit to do its own job right now. --Closeapple (talk) 06:09, 19 July 2017 (UTC)
in conclusion: we have an un-elected clique at OTRS, who make decisions in secret, and who speedy delete, out of process. their workflow is broken, with large backlogs, because they are not open to new users who do not share their values. how expeditious; how efficient. better admin lock the deletion discussion, so uninformed non-admins cannot rage against the machine. do not know why people would not prefer this process to a DMCA. such a preference for a out of commons process must be out of order. there is a fight to be had here, about the fraudulent use of a CC license; but that is not our fight; we prefer to fight with the national portrait gallery, london.
"maybe Commons isn't fit to do its own job right now": they already think that - but we cobble together wikimedia with the commons we have; not the consensus collegial commons we might want. Slowking4 § Sander.v.Ginkel's revenge 18:29, 20 July 2017 (UTC)

July 15[edit]

Arabic translation of {{Delete}}[edit]

Help needed – could someone review this change? --jdx Re: 10:35, 15 July 2017 (UTC)

July 16[edit]

Strategy discussion, cycle 3. A new challenge[edit]

Hi! It's the third week of our Cycle 3 discussion, and there's a new challenge: As Wikimedia looks toward 2030, how can we counteract the increasing levels of misinformation? You can suggest solutions here. Earlier challenges can be discussed as well. SGrabarczuk (WMF) (talk) 12:15, 16 July 2017 (UTC)

@SGrabarczuk (WMF): The talk page for the page linked (here) is confusing, as after being created for a few weeks with the expectation of responses to other questions, there have been no comments by anyone. Are responses supposed to go there, because it seems very discouraging to write on a blank page? Thanks --Fæ (talk) 12:49, 16 July 2017 (UTC)
@Fæ:, I watch it anyway and if anything appears, I'll summarize that, and it will be taken into account. I'm a bit surprised that no one has written anything there - maybe because most users prefer to write on Meta? On the other hand, someone has to be first, so go ahead, please. SGrabarczuk (WMF) (talk) 14:06, 16 July 2017 (UTC)
I suggest redirecting it to the meta discussion. The question is relevant for Wikipedia, but rarely comes up as an issue on Commons. Thanks --Fæ (talk) 14:09, 16 July 2017 (UTC)
I'm not surprised. there is no interest in strategy here, only in the tactics of deletion. Slowking4 § Sander.v.Ginkel's revenge 19:21, 17 July 2017 (UTC)

My recent file moves[edit]

Recently, I have been moving a lot of files with punctuation errors, generally those involving spacing around commas. Although this may seem trivial, I am doing this for an important reason, that being that file names here have consequences elsewhere.

I am currently engaged in a project on Wikipedia to fix small but unsightly punctuation errors - mostly spacing issues around commas.

What we are supposed to have is:

Jones, Johnson, and Smith formed Smithco, Inc., in Provo, Utah.

Instead, we often see spacing errors like:

Jones,Johnson, and Smith formed Smithco,Inc., in Provo,Utah.

or:

Jones, Johnson ,and Smith formed Smithco ,Inc., in Provo ,Utah.

or even:

Jones , Johnson , and Smith formed Smithco , Inc. , in Provo , Utah.

There are literally tens of thousands of these to fix, and the most efficient way I have found to do this is to load large groups of articles through AWB (I generate batches of 150,000) and use a script to fix any pages in those groups that return such errors. Unfortunately, due to the structure of our coding, text in file names is not distinguished from text in the body of an article. A number of templates omit the "File:" part of the term, making it even harder to distinguish these from regular text while editing. In order to avoid thousands of false positives, the easiest thing to do is to just rename files that have the sort of punctuation errors that need to be fixed when found in an article. Otherwise, editors carrying out the same task in the future will continually come across the same apparent errors, and will waste thousands of edit's worth of time checking and dismissing them.

I also note that filenames containing basic punctuation errors tend to contain spelling errors or have other problems. In a number of cases, I have seen groups of images with very similar names except for a punctuation error - missing spaces and extraneous spaces or punctuation being the only features distinguishing the image names. This is a recipe for confusion. For example, File:Celtic settlement-Open-Air Archaeological Museum Liptovska Mara - Havranok,Slovakia....jpg, File:Celtic settlement-Open-Air Archaeological Museum Liptovska Mara - Havranok,Slovakia..jpg, and File:Celtic settlement-Open-Air Archaeological Museum Liptovska Mara - Havranok,Slovakia.jpg, each of which I moved to more distinctive titles without the punctuation errors. I would prefer not to allow the idea of minimizing file moves interfere with the real work of fixing minor errors which continue to make Wikipedia look amateurish.

Another editor (@Materialscientist:) has objected to these file moves on the grounds that "every move may result in a loss of file due to the imperfections of Wikisoftware", and has also suggested that they do not comply with file moving policy. I believe that they clearly fall under move rationale 3 (to correct obvious errors) and rationale 6 (maintenance and bug fixes, because these errors cause maintenance issues where the files are actually used). In quite a few of these cases, rationales 2 and 4 (changing ambiguous names and harmonizing files in a set) are also implicated. Finally, I have never "lost" a file in the literally thousands that I have moved in my career here (I have been moving meaningless two- and three-letter-acronym titles to titles identifying the subject for years, sometimes by the dozen, without incident).

I therefore would like to continue this task, but I will defer to the the community if there is a consensus that these file moves are improper. Cheers! BD2412 T 15:57, 16 July 2017 (UTC)

  • I would be better when such a file is just uploaded it is automatically flagged by software for a review. Ruslik (talk) 19:08, 16 July 2017 (UTC)
    • It would be absolutely ideal if Commons exercised some editorial review of filenames when files were uploaded - but discovering errors at that time would still necessitate moving the files. The same editors who make spelling and punctuation errors in text are likely to make those errors when uploading files, leading to the same editing issues. BD2412 T 20:14, 16 July 2017 (UTC)
  • Correcting punctuation mistakes in Wikipedia is very good, but it has nothing to do with filenames in Commons. The moves you have been made, as described, go against COM:FR (and, no, rationale 3 doesn’t cover typos in filenames, only misleading information), and you should stop doing it. The software you use should be able to detect what is a filename and what is not, and leave them alone; any false positives of that should be manually undone. -- Tuválkin ✉ ✇ 19:35, 16 July 2017 (UTC)
    • AWB is a text editor (probably the most widely used one outside of the native interface), and can't tell a filename from any other string of text. If you believe that this software should have this capacity, by all means please develop it. BD2412 T 20:11, 16 July 2017 (UTC)
      • You’re the one who needs that capacity, as you’re the one who’ve been renaming files en masse against the relevant guideline because of the lack of that it. But I venture that a relatively simple grep filter would be able to isolate most filenames within wikitext. -- Tuválkin ✉ ✇ 21:17, 16 July 2017 (UTC)
        • Yes I - and any other editors trying to fix comma space errors throughout the encyclopedia - need that capacity. However, since it doesn't seem to exist, how do we address the large number of filenames containing these errors? Surely it is not the function of Commons to serve as a permanent repository of typos and mistakes in file names? BD2412 T 22:47, 16 July 2017 (UTC)
          • Concerning your first question: As repeatedly said, it is necessary to escape off any non-linguistic content (such as filenames) before performing any kind of automatic proofing of a linguistic nature (incl. punctuation). Also I’m concerned that you keep mentioning «the encyclopedia», and I hope you’re aware that thare are more languages than English, and that Wikimedia Commons concerns itself with more roles than being a mere storage area to host Wikipedia images. Which leads to answering your second question: Filenames are not to be mistaken for any kind of articulated sentence, and one of the functions of Wikimedia Commons is to be a trustworthy media repository where third party reusers can presume filename stability, meaning that what was once available at File:OMG,typoes!!.gif will not later on (along with its additional info, incl. license) be lost to a 404 because it was renamed File:Oh,_my_God:_Typos!.gif. -- Tuválkin ✉ ✇ 16:31, 17 July 2017 (UTC)

Filenames are filenames and I've don't think I've ever been of the opinion that they are supposed to be representative of actual sentences or text to the point that they need to follow rules of grammar. Ideally, they should be as short and concise as possible and convey information clearly. They are never seen by end users unless they seek them out, so why should filenames be required to follow the rules of grammar if they are not to be read by the vast majority of users? Keep in mind Commons is also a multilingual project so the grammar that you speak of is assumedly only English grammar, and says nothing for the filenames that can be found (perfectly acceptably) written in other languages or scripts. Commons is not a text-heavy project itself, but while I can understand that they would cross over and affect Wikipedia work, Commons filenames do not appear anywhere except within [[File:]] and within galleries. Is AWB really not able to pick up on these instances and avoid corrections, even if you designate it to avoid text in templates? AWB is also meant to be a human-assisted program, meaning the user proofs their edits as they go. I think there's some responsibility there for a user operating an automated program to adapt their work accordingly, especially so when it concerns the unpredictable nature (in a programming sense) of written language and grammar. seb26 (talk) 01:08, 17 July 2017 (UTC)

The issue is one of efficiency. Yes, AWB is human-assisted, and edits are proofed as they are made, but that also means that every editor engaged in this task must proofread the same text that every other editor has already proofread, because you can't tell when someone has looked at the page and decided not to make an edit. That said, I am throwing in the flag on this task until it is technologically feasible to weed out false positives appearing as normal text with typos. BD2412 T 01:40, 17 July 2017 (UTC)
@BD2412: If you could configure AWB to ignore lines starting with "|image=" with possible surrounding spaces and having non-space characters after the equal sign, that would tackle the vast majority of instances of your problem in infobox templates.   — Jeff G. ツ 03:38, 17 July 2017 (UTC)
It is possible to entirely ignore such pages, but that would mean ignoring actual errors also to be found on those pages. BD2412 T 03:45, 17 July 2017 (UTC)
Jeff G. refered to lines, not pages. -- Tuválkin ✉ ✇ 16:31, 17 July 2017 (UTC)

┌─────────────────────────────────┘

  • We are aware that
  1. any filname includes at least one punctuation mistake, an unavoidable one, by always including a period immediately followed by a letter, and
  2. some punctuation correction attempts, such as of adding colons, will render a filename call broken and fail when one tries to enact it (movefile),
are we not? -- Tuválkin ✉ ✇ 16:31, 17 July 2017 (UTC)
Periods followed by letters occur in many correct text situations (even in textual descriptions of filename extensions). There are, however, very, very few circumstances in any language using the Latin alphabet where a comma is either followed by a letter or preceded by a space. That is the focus of the cleanup task in which I am engaged. BD2412 T 02:00, 18 July 2017 (UTC)

July 17[edit]

Commons Android app - IEG renewal proposal[edit]

Hi folks,

The Wikimedia Commons app (a community-maintained Android app that allows users to upload photos to Commons from their phone) was funded via an Individual Engagement Grant last year and has had several improvements and new features added to it over the course of the grant. Examples include a list and map of nearby places that need photos (based on Wikidata), category suggestions based on the image title and location, prevention of duplicate uploads, and a new tutorial to educate new users on what types of photos should or should not be uploaded. 20554 new files were uploaded via the app during the grant period with an overall deletion rate of 15.74% (11.7% in the final two weeks after the new tutorial was implemented), and 3485 images that were uploaded via the app were used in Wikimedia articles. The final report for the completed IEG can be viewed here.

While we are very happy with the progress made, users have requested many other improvements that we would like to make but were not able to fit into the scope of the previous grant. Thus we are proposing a renewal of the IEG in order to work on these. Highlights of the proposed improvements include:

  • Enhancing the "Nearby places that need photos" feature by (1) allowing users to upload their image directly from a location on the list or map, with suggested title and categories based on the associated Wikidata item, and (2) displaying the user's real-time position on the map to allow easier navigation to the location they wish to photograph
  • Improving user education by displaying Commons account and user talk notifications (e.g. picture nominated for deletion) in the app, adding a gallery of featured images, and adding various notices and explanations in the upload screen
  • A sleeker, more intuitive, and more interactive user interface - a floating action button for uploads, "Nearby places that need photos" in a tab alongside the user's contributions, and a panel to display Commons account notifications and information about the nearest place that needs photos
  • Various technical and quality-of-life improvements, such as two-factor authentication login, multiple uploads, preventing overwrites, and fixing memory leaks and battery drain issues

We would very much appreciate feedback and suggestions on the renewal proposal - our aim is to benefit the Commons community as well as other Wikimedia projects relying on Commons, so feedback from this community is extremely important to us. Please do take a look at our proposal, feel free to ask questions and make new suggestions on the Discussion page, and/or endorse the proposal if you see fit. If you would like to be part of the project, new volunteers and additions to our diverse team are always welcome - please visit our GitHub repository or Google groups forum and say "Hi". :)


Many thanks! Misaochan (talk) 10:12, 17 July 2017 (UTC)

(As a side note, this is not the app that caused the selfie-pocalypse several years ago - that was caused by the web app, which is very different from the native Android app, especially in its current incarnation. Ongoing stats for uploads and deletes from the Android app are available here)

See my comment on the mailinglist: https://lists.wikimedia.org/pipermail/commons-l/2017-July/007895.html --Steinsplitter (talk) 14:02, 18 July 2017 (UTC)
Thanks for your feedback, Steinsplitter. Honest question, not being sarcastic - do you think the Wikipedia mobile app would be anywhere close to where it is today (in terms of quality, usability, and userbase) if none of their developers were paid? Granted, we cannot claim to be on par with the Wikipedia app (in any of those aspects), but I believe the budget we are requesting is commensurate to our current output and I hope that one day we will approach that level of quality. I personally would support other Commons tool makers if they applied for grants to cover their development costs, if I hear of their applications. Misaochan (talk) 14:49, 18 July 2017 (UTC)

Creator:Jacob Toorenvliet[edit]

Imo the image should be replaced by this one, it is rather confusing now, looks to me as if Jacob Toorenvliet was a woman. Date of birth is 1641 on the image. Lotje (talk) 15:21, 17 July 2017 (UTC)

Hi, Go ahead. For changing the image, it is on Wikidata: d:Q663613. Regards, Yann (talk) 15:32, 17 July 2017 (UTC)
✓ Done and thanks Yann Lotje (talk) 16:47, 17 July 2017 (UTC)

Taiwan museum makes exhibit images free to download[edit]

This BBC report says that the National Palace Museum in Taipei "has placed 70,000 high-quality electronic images in a free-to-download archive [and] provides a database for users to download information on the history and use of the cultural artefacts". Can someone who reads Taiwanese check the licence on these please? At least one of the images shown in the BBC article is an historic, out-of-copyright 2D artwork. Andy Mabbett (talk) 15:41, 17 July 2017 (UTC)

There is an english version of the museum's website: FAQ, About Open Data, and a link to this page. No sign of a free license, only "free to use for educational purposes". --El Grafo (talk) 15:50, 17 July 2017 (UTC)
However since we belive in COM:PD-Art for 2D-works, we don't care about if they claim rights for publishing the wors if they are 2d works in the public domain. --Jonatan Svensson Glad (talk) 17:37, 17 July 2017 (UTC)

Mock-ups or scale models[edit]

Because of my poor English I cannot get the difference between "Mock-ups" and "Scale models" (1:1 for example). Can you please tell me, shoud this (c:Category:Mock-ups of Sputnik-2) category be named as Mock-ups or Models of Sputnik-2 (in this case scale is 1:1)?‎ --Stolbovsky (talk) 22:09, 17 July 2017 (UTC)

  • If it's 1:1, we wouldn't usually call it a "scale model" and even "mock-up" or "model" would be a bit unusual. Typically "replica". - Jmabel ! talk 23:30, 17 July 2017 (UTC)

Tech News: 2017-29[edit]

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

  • "Wikimedia Labs" is now called "Cloud VPS". "Wikimedia Tool Labs" is now called "Wikimedia Toolforge". This is to help clarify the purpose of these services. [1]

Problems

  • On some pages, the Table of Contents is not being shown. It will normally appear if you edit the page again. Investigation is currently ongoing. [2]

Changes this week

  • Octicons-sync.svg The new version of MediaWiki will be on test wikis and MediaWiki.org from 18 July. It will be on non-Wikipedia wikis and some Wikipedias from 19 July. It will be on all wikis from 20 July (calendar).

Meetings

  • Octicons-sync.svg You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 18 July at 19:00 (UTC). See how to join.
  • Octicons-tools.svg You can join the next meeting with the Architecture committee. The topic this week is: Migrate to HTML5 section ids. [3] The meeting will be on 19 July at 21:00 (UTC). See how to join.

Future changes

  • Page Previews, currently a Beta Feature, will be enabled for logged-out users for all remaining Wikipedias (with the exception of English and German) the week of 24 July. An A/B test will be run on English Wikipedia to collect data before approaching the community for further discussion. [4]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

22:59, 17 July 2017 (UTC)
  • "Cloud" — what an excellent word choice for this new name! Did you work very hard to come up with something alienating to many of us, or did it just come naturally? -- Tuválkin ✉ ✇ 23:56, 17 July 2017 (UTC)

July 18[edit]

Map of recently uploaded pictures[edit]

I want to see a map of all pictures uploaded to Commons in the last 24 hours. Is there such a tool?

WikiMiniAtlas does not seem to have that option.

Thanks! Syced (talk) 04:27, 18 July 2017 (UTC)

Special:NewFiles should help. In Vector skin you have a link on top left side. — Speravir – 18:59, 18 July 2017 (UTC)

Reference error keeps showing up in description page[edit]

Colpoclypeus florus (female). Stinger will inject toxin, causes the leafroller to spin extra-thick webbing, K10910-1.jpg

A reference error keeps showing up in this file despite several attempts and previews. Maybe I used some template incorrectly? Suggestions anyone? Thanks a lot! — bertux 15:35, 18 July 2017 (UTC)

Solved, thanks Yann! — bertux 16:24, 18 July 2017 (UTC)

Problematic uploads by now inactive user[edit]

How to deal with this? There is an Armenian user who was only active in late 2015, here and in Armenian wikipedia. I can not tell anything about the quality in the wikipedia, but the file uploads seem to have serious issues. I did not check every file, but every file I checked has issues:

  • All uploads are declared as own work, but all are in fact works of other people.
  • In parts the filenames are, eeehm, worthy of improvement (there are some incomplete rename requests; this is, how it caught my attention).
  • In some cases we could mark them as duplicate, but in most cases the filetype was changed.
  • Some images are probably copyvios from external sources, as far as I can tell.

I already started some deletion and duplicate requests, but have still some questions:

  • Should the user be blocked, or still AGF?
  • What to do with the duplicates, but in different filetypes: only fix author, date and licence or start a deletion request (the quality is usually poor, too)?

— Speravir – 21:31, 18 July 2017 (UTC)

Hi,
Most of the files are indeed not own works, as claimed: Commons:Deletion requests/Files uploaded by Ադելլա. A warning should be enough for now. Regards, Yann (talk) 22:07, 18 July 2017 (UTC)
Thanks so far. I will add remarks to files you mentioned in the request. — Speravir – 22:19, 18 July 2017 (UTC)

July 19[edit]

Technical schematics: PD or not PD?[edit]

There is an image I would like to upload to Commons of the Hindenberg airship located here. It is marked as copyright protected 2008 along with the name of the person who drew it, but of course saying something is protected and having it be protected are not always the same thing. My argument for the image being in the public domain is that it consists only of information— that unlike some other diagrams of the Hindenberg such as this one or this one, it contains no creative content, and that anyone creating an accurate technical diagram of the Hindenberg would end up producing the same image. Information cannot be protected by copyright, and the sweat-of-the-brow doctrine does not apply: there is no question that the image is complex and was difficult to create, but that doesn't mean it reflects anything about the author's personality (because as a technical diagram, it does not) and therefore, in my view, it is in the public domain, regardless of the author's claims to the contrary. But I am not certain how others would interpret these things. Thoughts? KDS4444 (talk) 19:11, 19 July 2017 (UTC)

  • I'd say copyrightable. Two different drafters will not usually produce identical images. But if you want expert opinion, you might do better to ask at Commons:Village pump/Copyright. - Jmabel ! talk 20:19, 19 July 2017 (UTC)
  • Technical drawings are usually protected by copyright because there is some room for creativity. You can, for example, use different line thicknesses or place text in different position or use different fonts. Ruslik (talk) 20:23, 19 July 2017 (UTC)
  • My understanding is that raster versions of fonts aren't actually copyrightable (per Commons:Licensing#Fonts), and as near as I can tell the line thicknesses shown in the diagram actually represent the relative thicknesses or minimalist outlines of various parts of the airship (e.g., the cables, the outlines of a piano, etc.) and are therefore factual and not actually creative. The author had creative license with regard to where on the image he placed certain labels as well as their size— this implies that a version of the image without these labels, with different labels, or with labels placed in different places but otherwise identical would qualify as either public domain (in the first instance) or as a newly copyrightable derivative work (in the second and third), no? I will also see if I can get some response at the copyright portion of the village pump. KDS4444 (talk) 22:13, 19 July 2017 (UTC)

Strange category redirects[edit]

I've stumbled upon a few categories redirected in a strange style (using both "#REDIRECT [[Category:...]]" and "{{Category redirect|...}}" on the same page); I decided to fix them (by removing everything except the "{{Category redirect|...}}" from the page).
I've also contacted the author of those strange-style edits (User talk:Beyond My Ken#Category redirects); he said that "one redirect is not sufficient" and reverted my edits (Category:Elastane, Category:Elastane fibers).
Some expert advice would be welcomed. --Djadjko (talk) 01:02, 20 July 2017 (UTC)

  • I certainly favor the soft redirect. @Beyond My Ken: can you explain why you disagree? - Jmabel ! talk 04:37, 20 July 2017 (UTC)
  • From what I understand, the reverter is annoyed by not landing directly on the destination category page when only a category redirect (=soft redirect) is used. #REDIRECT (=hard redirect) does just that. The soft category redirect is essential for bots to move pages to the target category; the hard redirect is more of an optional user preference. Having read Commons:Only use category redirects where necessary, I do wonder what the effect on the bots' transfer work is when a hard redirect is in place additionally. Couldn't find that anywhere though. --HyperGaruda (talk) 04:45, 20 July 2017 (UTC)
  • The explanation, which I had to give repeatedly over the years, is currently sitting on my talk page. Until the deficiencies in the system are corrected, both redirects are required in order to gain full redirect functionality. Beyond My Ken (talk) 05:15, 20 July 2017 (UTC)
  • This is my explanation from May 2016, referring back to a previous explanation:

    OK, here's what I wrote a few months ago:

    For instance, Category:23rd Street, New York City redirects to Category:23rd Street (Manhattan). If I put "Category:23rd Street" in the search box, I get a list of possible categories, headed by Category:23rd Street, New York City. So far, so good. However, if I click on Category:23rd Street, New York City, and it doesn't have a hard redirect, I get sent directly to the "New York City" page [with its category redirect] and not to the "Manhattan" page. To go there, I have to click on the category redirect. If, however, the "New York City" category has a hard redirect, then when I click on it from the list of possible categories, I am sent directly to the "Manhattan" page, which is where I want to be. The problem is that the category redirect is too soft to send me there.

    As I recall, the same thing is true of the Commonscat box on Wikipedia. If the Commonscat link sends me to a category redirected cat, I land there, but if that cat has a hard redirect, I'm sent to the redirected page. In short, the "category redirect" template needs to be rejiggered so that it will make those redirects properly. Until then, both the hard redirect and the category redirect are needed to provide a redirect under all circumstances.
    Beyond My Ken (talk) 05:18, 20 July 2017 (UTC)
  • So, if you want people to only use category redirects, make category redirects work properly, it's really that simple. Beyond My Ken (talk) 05:25, 20 July 2017 (UTC)
  • If I put "Category:23rd Street" (without the quotes) into the search box, the Manhattan category doesn't appear in the results, nor its redirect. --ghouston (talk) 05:41, 20 July 2017 (UTC)
@--ghouston, I see the Manhatten cat in the results - see here.
  • It's not in those results either. Strange. --ghouston (talk) 07:12, 20 July 2017 (UTC)
  • I get 84 results, how many you get? What are your settings here? --JuTa 07:25, 20 July 2017 (UTC)
  • 84 results, settings default, first result Category:23rd Street (Sacramento RT). --ghouston (talk) 07:58, 20 July 2017 (UTC)
  • Wait, I have Category:23rd Street (Manhattan) at position 21 in the full results. I thought I'd searched the full result set without finding it. --ghouston (talk) 08:00, 20 July 2017 (UTC)
@Beyond My Ken, thats exactly the behavior which is intented by the soft redirects, because, if images or other pages are categorized into it, and people klicking on it they dont wonder why the page they just came from is not in the category but the hint where the correct cat is located and the image they came from. Thats the reason why hard category redirects are "forbidden" in most wikis including commons.
regards --JuTa 06:59, 20 July 2017 (UTC)
Sorry, but I don't understand that - can you be more specific? Beyond My Ken (talk) 13:16, 20 July 2017 (UTC)
What I understood was if you land on a category redirect page, and are whisked away from it, there are chances that you won't be able to see the contents, pages/images that are currently incorrectly categorised into that category redirect, and if you came from category X and you are redirected to Y, you will not see the page you clicked on inside the contents of Category Y. seb26 (talk) 14:31, 20 July 2017 (UTC)
The template-style redirect turns into a subcategory if it's non-empty, so the contents are still available. --ghouston (talk) 21:54, 20 July 2017 (UTC)
I.e., that's only an objection to using the hard redirect on it's own (assuming the presence of the hard redirect doesn't somehow mess up the functionality of the template-style redirect). --ghouston (talk) 21:59, 20 July 2017 (UTC)

Copyrights[edit]

Does this image have any copyrights? Super ninja2 (talk) 06:58, 20 July 2017 (UTC)

  • Possibly. There's enough text there that it might reach the threshold to be copyrighted. - Jmabel ! talk 15:13, 20 July 2017 (UTC)

July 20[edit]

Strategy discussion, cycle 3. Challenge 4[edit]

Hi! The movement strategy discussion is still underway, and there are four challenges that you may discuss:

  1. How do our communities and content stay relevant in a changing world?
  2. How could we capture the sum of all knowledge when much of it cannot be verified in traditional ways?
  3. As Wikimedia looks toward 2030, how can we counteract the increasing levels of misinformation?
  4. and the newest one: How does Wikimedia continue to be as useful as possible to the world as the creation, presentation, and distribution of knowledge change?

The last, fifth challenge will be released on July, 25.

If you want to know what other communities think about the challenges, there's the latest weekly summary (July 10 to 16), and there's the previous one (July 1 to 9).

SGrabarczuk (WMF) (talk) 13:39, 20 July 2017 (UTC)

Category:Nocturnal Culture Night 11...[edit]

Hi all.

A new user (@Stefan Bollmann:) added almost 400 files in a mother cat' so now they're all in double in sub-cat (p.e.: File:Alec Empire Nocturnal Culture Night 11 2016 05.jpg is in Category:Alec Empire - Nocturnal Culture Night 2016 subcat of Category:Nocturnal Culture Night 11 added in Category:Nocturnal Culture Night 11) and I don't know where he's from to tell him in his native language (to be sure he'll understand) the rules of categorization. They were alrea&dy well cat' before...

May be a bot can undo what he did but I DON'T want to do that because that takes too many time.

Thanks a lot. --lol LW² \m/ (Lie ² me...) 16:58, 20 July 2017 (UTC)

Hey, you joker. I'm not a new user, I am the photographer and uploader of all the files and the creator of the origin category (and many others you destroyed in the past with your sub-categorizing fetish). Your annoying creating of sub-categories within the artist categories and especially your file-moving and draining of the origin category destroys all of the statistics, who are important for the project Wikipedia:Festivalsommer of the German wikipedia. We need for our evaluation the usage statistics (with the GLAM tools [5] (tool server unfortunately down at the moment)) for the festival photos per festival. But if someone comes along and drain the festival category the statistic works not anymore, because the category has 0 files. :( Thats very bad for our work. It makes no sense and is not practicable for (in this example) 46 sub-categories to get for each audience of each band a single statistic only for one festival, that we want to add at least to one statistic per hand work. We have one category per event and want the whole statistic for all pictures from this event. That's why it is very important, that all pictures stay within the original ca tegory, whatever categories the files get additional.
For this reason I added for each picture the origin category again, so the category is no more empty and statistics are available (if the tool server is new started). Because I thought, you are a big fan of this (in my view mostly superfluous, but that's another issue) sub-sub-categories, I made a compromise and have not drained your sub-sub-categories, but add only the origin category. So you lost nothing (all your sub-sub-categories stay full with files) and I lost not so much. Almost a win-win situation. For you in any case.
Greetings and I hope, you can now better follow, whats the problem with your kind of categorizing. Sorry for my little harsh chant, but I'm quite pissed off at the moment, because you made my work so hard. --Stefan Bollmann (talk) 21:53, 20 July 2017 (UTC)
Stefan Bollmann, IMHO subcategories are usually very usefull. For a compromise you could better create some "hidden" category for your technical needs and there will be no problem --Stolbovsky (talk) 22:24, 20 July 2017 (UTC)
The Project runs since 5 years. Sorry, but it is not workable for hundreds and hundreds of festival categories to create retroactive hidden categories und hundreds of new statistic links. Maybe in future times. We have this to discuss in the project. Furthermore I have suggested a compromise: The files can be sub-categorized a thousand times - I don't mind - only one main issue: they also stay in the original festival category. There is absolutely no need (or any rule) for empty festival categories. Greetings --Stefan Bollmann (talk) 22:43, 20 July 2017 (UTC) (Next two days I will not be online, I answer after my vacation to upcoming discussion input.)
By Commons policy, with some very rare exceptions (which don't apply here), an image doesn't belong in both a given category and one of its parent (or grandparent, etc.) categories. If you want something that will stay there for a purpose other than Commons' general purposes, public categories are a bad choice. You can create a set of "hidden/user" categories for this, or you can create one or more templates that use something other than our category system, but you don't get to decide that the category system works differently in "your" area. - Jmabel ! talk 00:38, 21 July 2017 (UTC)
Stefan Bollmann, the GLAM tool you linked to, it has a function "Search depth" which presumably allows you to configure how many subcategories can appear in your results. If you are getting 0 categories as a result, perhaps you have not yet modified this field to show subcategories. If this works, this is a best of both worlds scenario. seb26 (talk) 01:13, 21 July 2017 (UTC)

July 21[edit]

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&oldid=252536742"