Commons: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/05. Please note:
Purposes which do not meet the scope of this page:
Search archives: |
| Legend |
|---|
|
|
|
|
|
| Manual settings |
| When exceptions occur, please check the setting first. |
.svg){kind=link}
 |
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day. |
Oldies
Setting a convention for when DMCA notices are required
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.
Notes
- "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.
- For background on the DMCA refer to Digital Millennium Copyright Act.
- Case studies: Official portraits of Donald Trump, Mike Pence official portrait
Votes and discussion
Support as proposer. --Fæ (talk) 10:51, 13 July 2017 (UTC)- Support A step in the right direction. --Yann (talk) 11:45, 13 July 2017 (UTC)
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)
- Support completely agree with nom. Corkythehornetfan (ping me) 21:44, 13 July 2017 (UTC)
Oppose 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)
- Changing to strong oppose given Nick's comment below. --Jonatan Svensson Glad (talk) 10:18, 14 July 2017 (UTC)
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)
- Such advice generally would not be free. The WMF outs complainants' names and websites. — Jeff G. ツ 13:07, 14 July 2017 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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:
- 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.
- 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.
- 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?)
- 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)?
- "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.
- "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:
- "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)
- 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:
- 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)
- What do you mean by "out of process"? Who are these admins who you claim are locking deletion discussions? And do you complain about secret decisions when a file is kept because of an OTRS ticket also? We don't make those people who give permission post their real identities and proof of ownership publicly either. --Closeapple (talk) 02:13, 23 July 2017 (UTC)
- converting a DR to speedy without consensus, is out of process. here is a user page admin lock, where deletions are pre-determined Commons:Village_pump/Archive/2016/12#Governance_of_page_protection_rights - OTRS has a credibility gap. at least a DMCA has the name of the person prepared to go to federal court. but why be open, when you can cram down. Slowking4 § Sander.v.Ginkel's revenge 17:53, 24 July 2017 (UTC)
- What do you mean by "out of process"? Who are these admins who you claim are locking deletion discussions? And do you complain about secret decisions when a file is kept because of an OTRS ticket also? We don't make those people who give permission post their real identities and proof of ownership publicly either. --Closeapple (talk) 02:13, 23 July 2017 (UTC)
July 15
Commons Android app - IEG renewal proposal
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)
Mock-ups or scale models
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)
- I think it's a question of timing and usage. Mock ups happen early on in the design process. They may not be to scale or reflect the final realised design, omitting many details. Scale models are produced after a design has been finalised. Railwayfan2005 (talk) 20:37, 24 July 2017 (UTC)
Map of recently uploaded pictures
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
._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
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
Technical schematics: PD or not PD?
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)
- Who decided what specific elements deserved to be represented in the image? It's the drafter's choice, and another technical drawing might include more or less in the way of details. This isn't like {{PD-chem}}, where the precise content is standardised, and anything with a little more or a little less is outright wrong. Nyttend (talk) 11:47, 21 July 2017 (UTC)
Strange category redirects
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:
Beyond My Ken (talk) 05:18, 20 July 2017 (UTC)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.
- 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)
- This is my explanation from May 2016, referring back to a previous explanation:
- @--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)
- @Seb26: Click on Category:23rd Street, New York City. You are redirected to Category:23rd Street (Manhattan). Below the category name, you will find "(Redirected from Category:23rd Street, New York City)". Click on "Category:23rd Street, New York City". You will be shown https://commons.wikimedia.org/w/index.php?title=Category:23rd_Street,_New_York_City&redirect=no, which currently shows a hard redirect, a soft redirect, and no pages or files. This can be done with any hard redirect, or you can add "?redirect=no" to any hard redirect's main URL. — Jeff G. ツ 04:55, 21 July 2017 (UTC)
- @--ghouston, I see the Manhatten cat in the results - see here.
- I have temporarily moved File:7th avenue at 23rd Street , New York, Ny.jpg to the redirected category to see if Russbot picks it up and moves it automatically back to the main category. If it doesn't, we should get rid of using additional hard redirects. --HyperGaruda (talk) 07:53, 23 July 2017 (UTC)
Copyrights
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
Strategy discussion, cycle 3. Challenge 4
Hi! The movement strategy discussion is still underway, and there are four challenges that you may discuss:
- How do our communities and content stay relevant in a changing world?
- How could we capture the sum of all knowledge when much of it cannot be verified in traditional ways?
- As Wikimedia looks toward 2030, how can we counteract the increasing levels of misinformation?
- 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)
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. --
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 [1] (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)
- Hi @Stefan Bollmann: you please me calling me 'Joker'
. I didn't get deep in your history to know what you did before on Commons but I just saw your account is new (all is in red); may be you use many accounts but that's none of my business. All I see are those 400 files (and may be more)... - That's not my «fetish» or my «kind of categorizing»: I only follow what was done before for many other concerts cat' to harmonize thousand and thousand files. In this case YOU destroyed (kind of vandalism for some of us, no?) what was done.
- Now, you have some explanations about GLAM and you know what you have to do to make it rolling, don't you? And, of course, undo this double categorization.
- Thanks to @Stolbovsky, Jmabel, and Seb26: for their lights on this case. Have a good weekend, evryone.
LW² \m/ (Lie ² me...) 22:10, 21 July 2017 (UTC)
- So, back again. Glamorous still don't work. I think we discuss the usefullness of suggested solutions (hidden category, adapted search depth ...) better, when the statistic tool runs again. Generally meaning of 100% sub-categorizing should (in my opinion) not be part of this discussion, because it's another field. --Stefan Bollmann (talk) 12:00, 23 July 2017 (UTC)
- Hi @Stefan Bollmann: you please me calling me 'Joker'
- 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.)
- 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)
July 21
Gallery pages
Gallery pages have been much maligned, and I would agree that most of them are pretty useless. I just now took 45 minutes to create one for a topic that I don't think is well served by just its categories and subcategories: The Grotto (Portland, Oregon). I'd really love to encourage people to consider creating a lot more like this: if well curated, these can be a very useful annex to this site. - Jmabel ! talk 06:24, 21 July 2017 (UTC)
Fantastic title, but hard to decipher
.jpg)
It's some book by Euclid, I could (barely) read that, but could anyone with some knowledge of mathematics tell us which one? Thank you! (Hats off to the typographers of the Renaissance, though.) --Edelseider (talk) 06:43, 21 July 2017 (UTC)
- Euclidis megaresis philosophi platonici.
See also [2]: "The first printed translation from the Greek is that of Bartholomew Zamberti, which appeared at Venice in 1505. Its contents will be seen from the title: Euclidis megarēsis philosophi platonici..." --тнояsтеn ⇔ 10:45, 21 July 2017 (UTC) - This print is probably 1510 by Joannes Tacuinus de Tridino, based on one up for sale on Abebooks. OCLC 51276185 --Fæ (talk) 10:51, 21 July 2017 (UTC)
- Thank you very much! --Edelseider (talk) 11:57, 21 July 2017 (UTC)
Template for human remains
Greetings,
I am currently preparing a photography session at the Ethnographic Museum of Geneva [3], and have presented them with a sample of the work I envision [4]. Upon seeing Category:Deformed trepanated skull-ETHAM 019484, my interlocutor brought my attention to this page, which explains the legal and ethical implications of displaying items stolen from cultures oppressed by colonialism, especiallly when they are made of human remains.
Do we have a template to this effect, in the vein of Template:Personality rights? In the negative, should we consider one?
Thank you for your attention and good continuation! Rama (talk) 12:26, 21 July 2017 (UTC)
- I'm pretty sure we don't have that, and should. - Jmabel ! talk 14:36, 21 July 2017 (UTC)
- The page refers to displaying the human remains themselves. I'm not sure if the problems extend to photographs. --ghouston (talk) 04:00, 22 July 2017 (UTC)
- It would not be the exact same problem, but I do feel potential use for such templates. Some items might look comical at a first glance and without context, it might be useful to bring attention to the fact that they have a strong connotation and are constituted of human remains. Rama (talk) 08:49, 23 July 2017 (UTC)
- For instance the object depicted at Category:Marratampirivit overmodelled skull-ETHOC 010205 might look amusing at a first glance. It is not. Rama (talk) 11:31, 23 July 2017 (UTC)
@Rama: , about that Peruvian skull from Geneva, I just added the Category:Artificial cranial deformation in Peru, which is in itself a subcategory of Category:Artificial cranial deformation. So much for contextualizing a bit more - artificial deformation of skulls is not something only colonialized peoples and cultures have done, see this prehistoric item from bien de chez nous. :) --Edelseider (talk) 15:07, 21 July 2017 (UTC)
- Nice catch Edelseider, thank you! Rama (talk) 15:22, 21 July 2017 (UTC)
July 22
Japanese ribbons
_1Class_BAR.svg)
File:JPN Zuiho-sho (WW2) 1Class BAR.svg, File:JPN Kyokujitsu-sho 1Class BAR.svg, and their duplicates were overwritten in some sort of bulk update. I'm unfamiliar with this award system and the history, but it appears the update might contravene COM:OVERWRITE. It may be particularly problematic on articles like en:Order of the Rising Sun, where we now have ten categories of people over 140 years with visually identical awards. I'd like some help figuring out what to do with this. Should we revert them? Guanaco (talk) 06:18, 22 July 2017 (UTC)
- Also
- File:JPN Hokan-sho 1Class BAR.svg
- File:JPN Zuiho-sho (WW2) 1Class BAR.svg
- File:JPN Kinshi-kunsho 1Class BAR.svg
Guanaco (talk) 06:21, 22 July 2017 (UTC)
- Seems to me that a reversion is in order. @Uaauaa: can you explain why you did these as overwrites instead of uploading to a separate name? - Jmabel ! talk 17:44, 22 July 2017 (UTC)
- Also pinging original uploader Mboro, if you'd like to comment. Guanaco (talk) 18:04, 22 July 2017 (UTC)
- I have already explained why I overwrites it at User talk:Uaauaa#Duplicates.Do you have any further questions?--uaa (talk) 19:44, 22 July 2017 (UTC)
- @Uaauaa: What I'm seeing is that there are rosettes for these awards, or at least some of them. It may not be accepted to overlay the ribbon with a rosette as in the images, but it does provide a somewhat valid, visual method of distinguishing the different classes of awards. Your point of view is valid as well, and there's good reason not to display awards in any misleading fashion.
- In line with COM:OVERWRITE, I propose that we revert the images to their previous state. We then create a category and template marking them as non-historical visual representations. From there, the various wikis can make their own editorial decision of how they would like to represent Japanese ribbon bars. Guanaco (talk) 23:35, 22 July 2017 (UTC)
- +1. - Jmabel ! talk 05:50, 23 July 2017 (UTC)
I do not think the COM violation situation is preferable. However, it is more unacceptable to make up an imaginary ribbon. It is better to change links in all articles to the same file by bot editing and delete the remaining files. There are not many articles that need a visual way to distinguish between different classes of awards.It is not necessary for the honor field in the article of a person. Also, it is not preferable for articles like en:Order of the Sacred Treasure. If you just think you need it, you can create a new correct file for a few articles that need it. I think that it is preferable that a file with no ribbon and only rosette is preferred.--uaa (talk) 17:43, 23 July 2017 (UTC)
- I'm going to go ahead and revert these images and add {{Ahistorical award}}. Policy about respecting other wikis' editorial decisions won't allow us to use User:CommonsDelinker or similar to make your proposed change at a centralized level, but you can do what you will on other projects. Guanaco (talk) 18:12, 23 July 2017 (UTC)
Done. Guanaco (talk) 18:43, 23 July 2017 (UTC)
I am disappointed in your actions that forged false edits by ignoring my opinion. You have not explained enough to convince me. I will fix it again.--uaa (talk) 19:37, 23 July 2017 (UTC)
- @Uaauaa: Please fix it by replacing the images on Wikipedia with the originals, which I've linked via the template on each file page. Overwriting/reverting the images again would be against Commons policy. Guanaco (talk) 19:48, 23 July 2017 (UTC)
There is no class in kikkasho, so rosette are not necessary. Therefore, revert soon.--uaa (talk) 19:55, 23 July 2017 (UTC)
- @Uaauaa: Don't revert. Replace it on Wikipedia instead. If you think the image is garbage, start a deletion request. Guanaco (talk) 19:59, 23 July 2017 (UTC)
Other fileｓ will be changed to a new version.--uaa (talk) 19:59, 23 July 2017 (UTC)
By the way, do you think that you can allow fake information to flow for the commons policy?--uaa (talk) 20:10, 23 July 2017 (UTC)
I have started a discussion/poll at User talk:CommonsDelinker/commands/talk#Global replacement for possibly incorrect Japanese ribbon bar, to address this. Guanaco (talk) 20:42, 23 July 2017 (UTC)
An idea 💡 to possibly prevent spam, and re-uploaded unfree images.
I have an idea 💡 to prevent the re-uploading of previously deleted unfree images, and to maybe prevent spam to some level. I am mostly inspired by 2 (two) things, first of all I don't want to accidentally re-upload images I thought were free but because the country I visited had more limited F.O.P. than I am used to, and got deleted, and the second inspiration came/comes from a recent block 🤚🏻 here on Wikimedia Commons where an account attempted to upload an image called “Kate Winslet.jpg” around 30 times, and then (a suspected/an alleged) sockpuppet attempted this 3 (three) or 5 (five) times more. Now here is how we could easily prevent both from happening, simply keep ALL deleted images (without displaying them, hosting copyrighted images without making them available is not illegal, only sharing them is), and then scan all new uploaded images before publishing to see if they’re among the deleted images.
Now I know that some trolls will make minor adjustments to the images to not get detected, however this will prevent a large part of users who just upload the same Facebook post or the same copyrighted images. Is this feasible?
--58.187.171.238 10:50, 22 July 2017 (UTC)
- Deleted images are generally kept on the server so they can be restored and reviewed by admins as needed. This might be relatively simple to implement with a hash function, but I wouldn't do a hard disallow of uploads if it catches something. False positives could happen, and there are sometimes legitimate reuploads. Better to tag them as with the abuse filter: "possible reupload of deleted file File:Bad photo.jpg." Guanaco (talk) 11:06, 22 July 2017 (UTC)
Help with new file
File added to Lupton family page on Wikipedia. The file is called Lord Mayor Sir Charles Lupton etc etc. I have added a comment on the deletion page. Please let me know what can be done to get this file all ok. It was not published until 2013 in newspapers and then online. It was filmed in 1915-16. Thanks so much from a novice. 2001:8003:4E8F:6D00:6939:DA68:5FBA:B50B 11:17, 22 July 2017 (UTC)
- This file is not in public in USA (due to URAA restoration), so nothing can be done until 1 January 2022. Ruslik (talk) 14:09, 22 July 2017 (UTC)
- Which file? Can it be tagged with Category:Undelete in 2022? -- Tuválkin ✉ ✇ 22:29, 22 July 2017 (UTC)
Open search on a new window
Until today or so it was possible to enter a queary in the search box and have the results page open in a new window by Ctrl-clicking the button Search. It stopped working for me (Monobook user). Any ideas? -- Tuválkin ✉ ✇ 22:36, 22 July 2017 (UTC)
- Works fine for me with vector. With monobook, Firefox told me it was blocking a popup window – allowing popups for Commons made it work (opens in new tab, not window). --El Grafo (talk) 06:53, 23 July 2017 (UTC)
- Thx for replying. For some reason it is again working properly as before, without any change on my part. -- Tuválkin ✉ ✇ 00:52, 24 July 2017 (UTC)
July 23
The ghettoization of women continues
In Category:Jazz composers, buried under the letter "F" is Category:Female jazz composers. There is, of course, no corresponding Category:Male jazz composers. So if you look very carefully, you can find the women; otherwise you are presented with a list of over 200 names, all or nearly all male.
When I've called out similar things before, I've been told that this is somehow feminist, in that it makes it easier to find just the women in a field. I call bullshit. Yes, it may make it easier to find women if you are very specifically looking for women. For every other use, it makes the field look all male, unless they look very closely.
Further: what does gender have to do with being a composer that it should call for an entirely separate category? I understand separating out vocalists by gender, because with very rare exceptions male and female vocalists sound very different, and it's one of the first things you notice about a singer. But composers?
In the unlikely event that this separation is really what the community wants, then male jazz composers should also be "down a level". As it stands, this is ghettoization, pure and simple. - Jmabel ! talk 16:34, 23 July 2017 (UTC)
- Thank you for taking care of this issue. I agree that something has to be done here. I'm afraid that due to the nature of Wikimedia Commons as being a multilingual website with a worldwide user community it simply can't be assumed that everyone comes here with an understanding that women have to be treated equal. By sorting them out into subcategories as it has been done at the categories for composers this is absolutely not the case. I don't want to blame anyone here. Many users may simply sort new content into an existing category sheme without thinking. As a matter of fact in many countries it is not normal that there is nothing special about it when women perform certain jobs. In some countries women are not even allowed to work at all (exept for taking care of the household at home). Just yesterday I saw a documentation about Bangladesh: In most families the husband can decide about everything. If the men don't agree, women are not even allowed to leave their home. Many Commons users live in countries with a whole different unterstanding of gender roles. These understanding sometimes comes visible within their contributions here. This simply can't be ignored or discussed away. In my opinion gender equality should become an official policy on Wikimedia Commons. Due to the worldwide community it can't be taken for granted without an official agreement. --Zaccarias (talk) 17:33, 23 July 2017 (UTC)
- Zaccarias, please note that:
- Language ≠ country
- Single person ≠ their country’s average
- Enjoy your Splash Damage award. -- Tuválkin ✉ ✇ 00:51, 24 July 2017 (UTC)
- On English Wikipedia, there are sometimes what are called "non-diffusing categories" for women in fields where they have been historically less represented. The women stand alongside the men in, for example en:Category:American diplomats, and they are also in the non-diffusing sub-category en:Category:American woman diplomats. The converse is true as well, as in en:Category:Male feminists. That might be what was intended here, rather than ghettoization. For the sake of simplicity, ease of navigation, and avoiding conflict I would prefer that we not do this, and instead always treat female and male categories equally. Guanaco (talk) 17:57, 23 July 2017 (UTC)
- Jmabel, I think (or rather, I hope!), that the resulting ghettoization you complaint against (and correctly so!) is not the original intent, but rather the result of clumsy attempts at diffusion: Someone notices that Category:Jazz composers is getting too crowded and decides to split its contents into subcats. So far so good (well, mostly, but lets keep this story short), but instead of splitting Jazz composers by any meaningful criterium (or criteria!), the category is split in the simplest, laziest possible manner — by gender. I would prefer to have a seriously researched and mantained sub cat tree splitting these by musical subgenres and/or historical period. Category:Jazz composers by gender is only sensible if among a good handful of other such Categories:Jazz composers by …. -- Tuválkin ✉ ✇ 00:51, 24 July 2017 (UTC)
- I'm not talking about intent. I'm talking about effect. - Jmabel ! talk 01:53, 24 July 2017 (UTC)
- We do agree, then. -- Tuválkin ✉ ✇ 10:46, 24 July 2017 (UTC)
- There's no way to stop people making intersection categories. Category:Jazz composers could no doubt be split multiple ways. I don't think there's any real solution apart from waiting for a user interface based on structured data. I suppose it wouldn't be hard to write a bot that could maintain intersection categories using properties from Wikidata, and I suppose keep them in sync with useful flat categories, but I'm not sure if it would be worth it at this point. --ghouston (talk) 02:05, 24 July 2017 (UTC)
- Look, we split Category:Skyscrapers by height, we split Category:Years by month — it’s logical that Category:Jazz composers should be split by musical subgenre, or maybe by historical period, if subgenres of jazz, or the assignment of each composer to a jazz subgenre, turns out to be impractical.
- Appealing to wait up for everybody’s most loved / most hated piece of vapourware is not the way to go, though.
- -- Tuválkin ✉ ✇ 10:46, 24 July 2017 (UTC)
- I agree completely with User:Jmabel. If, however, someone is categorizing wrongly and continues this way without making (and filling!) a category Male whatever my protest has always been simple: (example) re-adding the category Photographers from Austria to the female photographers. If someone might object ("over-categorization!"), you can plainly answer that it is of course no over-categorization as long as the category Male photographer from Austria doesn't exist or is only filled up to 20% or so. Don't let women be marginalized. Vysotsky (talk) 13:51, 24 July 2017 (UTC)
- When you have a Category:Photographers from Austria and a Category:Female photographers from Austria but no Category:Male photographers from Austria, who is being marginalized are the Austrian men who are photographers, because they do not appear under the category:Men of Austria by occupation: Right? --E4024 (talk) 14:10, 24 July 2017 (UTC)
- Wrong. category:Men of Austria by occupation is a technical category, used almost entirely by those who are categorizing photos. An end user is likely to be looking for photographers from Austria; they are not likely to be looking for men of Austria by occupation. - Jmabel ! talk 14:33, 24 July 2017 (UTC)
- Rightly so. See also this discussion. Vysotsky (talk) 14:44, 24 July 2017 (UTC)
- Wrong. category:Men of Austria by occupation is a technical category, used almost entirely by those who are categorizing photos. An end user is likely to be looking for photographers from Austria; they are not likely to be looking for men of Austria by occupation. - Jmabel ! talk 14:33, 24 July 2017 (UTC)
- I disagree that there is any malicious discrimination happening here. The correct answer to this is USD 10 million for Commons:Structured data. The prejudice is based in software infrastructure. Wikimedia projects have an obligation to users to permit research of biographies by demographic, so if someone wants to search by race, gender, sexuality, religion, nationality, etc with the intersection of career, accomplishment, residence, or whatever else, then users should have a path for doing this. The original high-profile New York Times story in 2013 about novelists was misguided because of course there is such a thing as "promotion of a demographic in a career field", and with Wikipedia's current software, creating a category is the way to actualize that. If there is a "women in jazz" category then it is because someone is promoting women in jazz, not because of exclusion from other categories. It makes no sense in Wikimedia projects to put someone in a specific category and simultaneously all parent categories. The core of the problem is that software cataloging is expensive and what seems like a small problem actually requires 10 million dollars that only now we received. When structured data is actualized then all category intersections on Commons will go away, and so will the problem. There should be a category for "jazz players" and categories for "male", "female", and anyone who wants to combine the two should combine them. Blue Rasberry (talk) 15:56, 24 July 2017 (UTC)
- (Edit conflict) Ten million dollars to be spent in vaporware that does nothing now and will still be doing do nothing once that amount is exhausted in “outreach campaigns” and other such pretend work. Meanwhile, human-powered categorization done by volonteers working for free in their spare time will go on improving, little by little, the semantic web linking together all Commons’ content. (I really don’t know anything about jazz, or else the op discussion would be moot by now.) -- Tuválkin ✉ ✇ 19:27, 24 July 2017 (UTC)
- You are not addressing the main issue. There are many (too many) Wikipedians making categories like Category:Female composers from Italy WITHOUT making categories Category:Male composers from Italy while at the same time REMOVING the female composers from the Category:Composers from Italy. And this happens everyday in Wikimedia Commons, thereby literally removing women from thousands of main categories. Though this may be done with the best intentions, the outcome makes Commons less useful -and very old-fashioned and mediocre. We need an honest discussion about this way of working. Vysotsky (talk) 18:31, 24 July 2017 (UTC)
- I agree that is the main issue here and it needs fixing. Seems that nobody disagrees with that, either, so we’re only facing these two options:
- Either create complementary categories for Male so-and-so (either by
- splitting in twain its parent Category:So-and-sos, or
- creating an intermediary parent Category:So-and-sos_by_gender, allowing for better gender categorization at this level and non-gender related categorization at an upper level, with concurrent Category:So-and-sos_by_this-or-that), or
- ignore gender altogether for most categories of humans and undo all Category:Female_so-and-sos, moving its contents back to the parent cat.
- Either create complementary categories for Male so-and-so (either by
- I think I prefer solution 1.2. What about you lot? -- Tuválkin ✉ ✇ 19:27, 24 July 2017 (UTC)
- Good summary, clear options. I would also go for solution 1.2. Vysotsky (talk) 20:33, 24 July 2017 (UTC)
- I don't see 1.2 as being necessary (feels like just more make-work), though I feel something from 1.# is the way to go. Simply adding the male and female subcats to the parent cat with an appropriate and standardised sortkey would solve the problem of either subcat getting lost in the forest, which was one of Jmabel's original complaints. I would suggest something like "| Gender" to keep them both side-by-side in the parent category. — Huntster (t @ c) 21:27, 24 July 2017 (UTC)
- I agree that is the main issue here and it needs fixing. Seems that nobody disagrees with that, either, so we’re only facing these two options:
- I'd say: nuke all gender-specific subcategories. Instead establish a limited set of high-level categories:
- Category:Humans by gender
- → Category:Female_humans
- → Category:Male_humans
- → possibly further categories for transgender etc.
- I largely agree, but I think that's probably a bit too extreme. I think there are a few things (vocalists, actors) where gender really is that significant. But very few. - Jmabel ! talk 15:15, 25 July 2017 (UTC)
- I'd say: nuke all gender-specific subcategories. Instead establish a limited set of high-level categories:
@Bluerasberry: I didn't say this was intentionally malicious—I am talking about an effect, not an intention—and I don't have 10 million dollars lying around. I would be happiest with solution 2, willing to accept solution 1.2, not interested in discussing infeasible solutions or worrying about people's unfulfilled intentions. - Jmabel ! talk 23:52, 24 July 2017 (UTC)
Agree with points made by BlueRaspberry and El Grafo, though El Grafo's solution isn't in keeping with current category implementation policy. Gender and occupation are not attributes that make for reasonable subdivisions. For those determined to waste their precious time on earth organizing media files using a totally broken system, the only reasonable choice is 1.2 above -- there's nothing special about grouping jazz players by gender vs any other random category you might pick, so have a "by gender" intermediate group so that "by xyz" can freely be added by people interested in various xyz attributes of jazz players. Ultimately, this all needs replaced by something sensible, where intersections are done by the search user, not by Commons users trying to second-guess what may be useful. -- Colin (talk) 14:05, 25 July 2017 (UTC)
I´d go for Tuválkin´s option 2 (aka El Grafo´s "nuke them") if all subcategories for individual people are copied to Category:Men by name or Category:Women by name, thus making sure that the information about gender is retained close to the root of the category tree. If you want a list of the categories of female jazz vocalists, you can get it easily as long as Category:Women by name is well-maintained. Splitting the whole category tree along men/women doubles the number of people categories and clearly doesn´t work: Most of the "by gender"-subcats are practically useless as they are poorly maintained, illogical and unreliable. --Rudolph Buch (talk) 14:09, 25 July 2017 (UTC)
- If you want to see where (in principle very useful) categorization has led us, just check Category:Photographers. If I would like to find a photographer whose name and country of origin I vaguely know (was he from Hungary or Austria?), I could look in 4 categories: Photographers (with the left-overs), Male photographers (practically empty), Photographers by name or Photographers by country. Mind you: he could really be in one of these 4 categories. I would like to have one home category, containing all photographers (perhaps the category:Photographers?), and I really don't care how many sub-categories there would be. I can afford a smile looking at categories like Female photographers from India or Photographers using Leica cameras, but I don't mind, just as long as photographers in these categories are not removed from the home list. Vysotsky (talk) 15:36, 25 July 2017 (UTC)
July 24
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
CSS in templates will be stored in a separate page in the future. This will make it easier to make templates look good on mobile devices. This now works on mediawiki.org and Wikitech. It will come to more wikis later. [5][6][7]-
.mw-ui-constructivemodifier class is deprecated and has been removed. [8]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 25 July. It will be on non-Wikipedia wikis and some Wikipedias from 26 July. It will be on all wikis from 27 July (calendar).- It will be possible to restrict who can send you notifications on a wiki. This new feature will accessible in your preferences, in the Notifications tab, on Wednesday, July 26. Please see the documentation. [9]
Meetings
- 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 25 July at 19:00 (UTC). See how to join.
- You can join the Wikimedia Foundation July 2017 Metrics & Activities Meeting. The meeting is about how Wikipedia and the Wikimedia movement are perceived and understood by the world. The meeting will be on 27 July at 19:00 (UTC). See the agenda and how to join.
Future changes
- New Filters for Edit Review, at the moment available as a Beta feature, will be released by default for the Recent Changes in September.
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
15:57, 24 July 2017 (UTC)
July 25
Redirections in categories once more...
A new fashion of adding stright redirections to the redirected categories is still going on... It is nonsense to add redirection next to the {{Category redirect}}. We have millions of such categories. We should add it to the template or give up... Wieralee (talk) 08:56, 25 July 2017 (UTC)
Please, fix this jpg file
Hello, I've just found that one of satellite photos is currently rotated upside-down (i.e. south is up and north is down) this is the file: File:Мерц6.jpg. This is proof, that it's rotated: https://www.google.com/maps/@42.185443,79.8611786,20537m/data=!3m1!1e3 . Could you please fix it? — Preceding unsigned comment was added by 213.145.139.2 (talk) 07:16, 25 July 2017 (UTC)
- North is not up. Plenty of Aerial photos look south, too. - Jmabel ! talk 15:16, 25 July 2017 (UTC)
Arnold Genthe Collection
The Arnold Genthe Archives is mostly Public Domain at the Library of Congress (http://www.loc.gov/pictures/collection/agc/), but there are some photo marked as "Rights Advisory: Publication may be restricted. For information, see "Arnold Genthe . . .," http://www.loc.gov/rr/print/res/073_gen.html". I inquired few days ago, again, about these photos with the LOC and the answer is below: 1) the 70 year rule would only apply if the images were not a work for hire, and that's precisely the element that is in doubt and why the rights statement mentions that whatever client information we were able to find, we recorded in the catalog records. 2) If the work was done by Genthe not for a client, you're correct that the should be no restrictions on publication. If the work was done for a client, however, it was a work for hire, and the term of copyright in those circumstances is 95 years from publication or 120 years from creation, whichever is shorter (see the section labeled "Situations Where the Image Was Made "For Hire" or Is an Anonymous or a Pseudonymous Work" in the discussion of duration of copyright http://www.loc.gov/rr/print/195_copr.html#duration in our overall guidance document on assessing the risks of using an image from our holdings (the document also references relevant U.S. Copyright Office circulars to read more about it). You didn't specify the image in which you are interested, but some images are getting close to the 95 year mark if they can be assumed to have been published. 3) We have had one researcher assert that Genthe no longer did work for hire after he moved to New York in 1911, but we have been unable to verify that. The only other information I can offer towards your risk assessment is that we have never been contacted by anyone asserting copyright to images made by Genthe for hire. Conclusion: all photos before 1922 (as of 2017) are in Public Domain. Photos after 1922 for which there is a "Publication may be restricted" notice maybe not in Public Domain, but a) Genthe's experts said Genthe did not perform work for hire after 1911 and b) no one of the heirs of people on those images contacted LOC for copyright (considering that many of them, like Alice DeLamar and Marion Carstairs do no have direct heirs).--Elisa Rolle 15:53, 25 July 2017 (UTC)
Flickr images / paid editing
The following types of images raise concerns for me. Basically what we have is paid editors creating a flickr account, adding the image they want to upload to this account. Than uploading to Wikipedia using the flickr account as justification that the image is under an open license.
We have no verification that they have gotten proper release to release the image under an open license on flickr. Looks like a way to simple side step OTRS and better copyright release verification. Doc James (talk · contribs · email) 16:30, 25 July 2017 (UTC)