Commons:Village pump

From Wikimedia Commons, the free media repository
(Redirected from Commons:Village Pump)
Jump to navigation Jump to search

Shortcut: COM:VP

Community portal
introduction
Help deskVillage pump
copyrightproposalstechnical
Administrators' noticeboard
vandalismuser problemsblocks and protections
↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓
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:


 
Broadwick St, Soho, London: a water pump with its handle removed commemorates of Dr. John Snow's tracing of an 1854 cholera epidemic to the pump. [add]
Centralized discussion
See also: Village pump/Proposals • Archive

Template: View • Discuss  • Edit • Watch
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 7 days.


June 17[edit]

Is Commons' aim to store all free scientific articles?[edit]

Background: Commons:Deletion requests/File:Research of an Intelligent Sale System of Guilin Rice Noodles Based on SCM.pdf

There're several million scientific articles in free license. Is every such article in scope of Commons?--GZWDer (talk) 12:51, 17 June 2020 (UTC)

Brianjd (talk) 13:08, 17 June 2020 (UTC)
  • For the DR you referenced, this is a moot point, as the file is in use. I have mentioned this at the DR as well. Brianjd (talk) 13:39, 17 June 2020 (UTC)
    "A PDF or DjVu file of a published and peer-reviewed work would be in scope on Wikisource and is therefore also in scope on Commons." An entry on Wikidata does not constituted in-use on Wikisource. -Mys_721tx (talk) 18:29, 17 June 2020 (UTC)
    However, in-use on Wikidata constitutes as in scope for Commons, as being used on another Wikimedia project. --Jonatan Svensson Glad (talk) 18:54, 17 June 2020 (UTC)
    The text you quoted does not say “in use on Wikisource”. It says “in scope on Wikisource”. Which the file subject to this nomination is, as far as I can tell (but I am unfamiliar with Wikisource). This is separate to it being in use on Wikidata. Brianjd (talk) 02:32, 18 June 2020 (UTC)
    I agree that the file is in-use. However, Hans Publishers is possibly predatory. The quality of the review is questionable. Articles in open access predatory journals have the guise of peer-review and a compatible license yet they have little education value. The policy needs to be updated to exclude those. -Mys_721tx (talk) 03:10, 18 June 2020 (UTC)
    • Is preadatoryjournals.com itself reputable? The best external source I could find is [1] (via enwiki), which recommends researchers check one of the sites listed there (including predatoryjournals.com).
    Perhaps we should look at predatoryjournals.com itself. It does not seem to give any details on why Hans Publishers is listed as predatory. The article in question is from a journal called “Dynamical Systems and Control”, which is not listed on predatoryjournals.com.
    I suppose we’ll need to clarify this if we’re going to update the policy. Brianjd (talk) 03:49, 18 June 2020 (UTC)
    • I should point out that Hans Publishers is also on Beall’s List, again with no apparent explanation. Brianjd (talk) 03:53, 18 June 2020 (UTC)
    • preadatoryjournals.com states that they inherited the list from Beall. The journals on Beall's list are standalone such that those journals do not have a publisher. A journal published by a publisher would not be included in the standalone list. Perhaps DOAJ could be used as what journals is allowed. -Mys_721tx (talk) 22:20, 18 June 2020 (UTC)
    • I think these big text files should not be added, unless there is an Wikisource entry. Better to sourcelink the PDF by the Wikipedia articles, with the advantage of keeping up with updates. Wikisource can only have public domain entries. Because of that most Wikisource entries are historical text and literature.Smiley.toerist (talk) 16:17, 22 June 2020 (UTC)
    • @Smiley.toerist: I can’t work out what you’re trying to say. If a paper is public domain, then put it on Wikisource and it’s fine. If a paper is copyrighted but freely licensed, then it’s not worth hosting. Did I get that right? We have plenty of externally-published files, and there is no precedent for this “sourcelink to save space and keep up with updates” thing, as far as I know. If it’s in scope, we should have a copy. (Otherwise, we might be scrambling to make a copy later.) Brianjd (talk) 10:35, 23 June 2020 (UTC)
      @Brianjd Let me know your though on using DOAJ as a list of permitted open access journals. Also should thre be a new thread to discuss how to update COM:SCOPE? -Mys_721tx (talk) 08:09, 26 June 2020 (UTC)
  • There are millions of PD books are they all in scope - Yes. Is someone going to import them all - Unlikely. Same with photographs (useful for educational purposes) or with photographs of artworks. I do not see scientific papers any different. --Jarekt (talk) 21:58, 17 June 2020 (UTC)
  • Out of interest, we are just populating United States Census Bureau publications with a few thousand large-ish to extremely large documents. These are, to my mind, dull as ditch-water to look at, apart from the odd map, but might be very exciting for someone to run some analysis of the data and create charts to support a Wikipedia article. The issue for Commons is that it's still not very nice to browse a PDF on our website, and the only way to link to a specific page (like a map) is to use a thumbnail as the normal image syntax still misses a "page" parameter. Without some basic improvements to the reader interface for articles and books, an import of a million articles is highly likely to remain virtually unused and impenetrable. -- (talk) 10:04, 19 June 2020 (UTC)
Pictogram voting comment.svg Comment What is the function of books and scientific papers being on scope in both Wikisource and Commons? Isn't that essentially the same as hosting articles on both Commons and Wikipedia, or pictures of lifeforms on both Commons and Wikispecies? --Pitke (talk) 11:52, 26 June 2020 (UTC)
Can you even upload images to Wikispecies? We need scans of books on Wikisource in order to transcribe them. In some cases, they're used on multiple Wikisources for different languages; in others, they're the source work for various extracted images that might see use on Wikipedia, Wikispecies or Wiktionary as well as Wikisource. In others, they're files that are going to be used on one Wikisource; is there any reason that Wikisources should not upload their files to Commons just like all the other projects do?--Prosfilaes (talk) 23:33, 26 June 2020 (UTC)
A PDF of a digital document that provides nothing beyond a text file would be an example. -Mys_721tx (talk) 06:52, 27 June 2020 (UTC)
An example of what? I ask again, is there any reason that Wikisources should not upload their files to Commons just like all the other projects do?--Prosfilaes (talk) 21:39, 27 June 2020 (UTC)
One type of disallowed PDF files given by COM:SCOPE is those whose "... content is essentially raw text; such files are not considered media files. Note that scans of existing books, reports, newspapers etc of historic or other external significance are not excluded on this ground, even if they contain no images."-Mys_721tx (talk) 01:07, 30 June 2020 (UTC)
@Mys 721tx: If that was intended as a rejoinder to Prosfilaes' question, it actually is rather the opposite: that indicates that "scans of existing books, reports, newspapers etc of historic or other external significance" are in scope. - Jmabel ! talk 02:43, 30 June 2020 (UTC)
I fail to see the contradiction. Book scan? Yes. Government paperwork? Probably. Literally a plain text file converted to a PDF? No. -Mys_721tx (talk) 02:56, 30 June 2020 (UTC)
As an illustration of liminal cases, we have just uploaded the delightful File:Administrative Notes (IA 568391 02 07).pdf.
This is only just more than a plain text file, as it was manually typed up in 1981 and presumably photocopied for wide circulation. As a series, these brief administrative notes would give insight in to library operations in pre-digital days, when microfiches were the best alternative to paper prints.
If someone were to feed these in to OCR and create texts with the same layout, they would be more readable and more searchable, however one can still make the case that the look of the original, including the unique physical way the typewriter has not made perfect impressions, should not be lost or made hard to discover. -- (talk) 09:21, 1 July 2020 (UTC)
What I meant by plain text file is in its computer science sense, an array of human readable characters. They can be hosted directly on Wikisource barring any licensing issue. Converting them to PDF via text2pdf, Microsoft Word, or any other program adds nothing to its presentation. -Mys_721tx (talk) 18:46, 1 July 2020 (UTC)

June 19[edit]

The state of the help pages ..[edit]

.. leaves much to be improved.

I was trying to find out what information should generally be entered in the "caption" box versus the "description" field of an image (when I come across images which haven't been proberly labelled) and performed a search of the help pages using these terms:

  • description versus caption
  • description caption box
  • description caption field

There were no relevant results ...

Browsing the help pages for information on this topic I came across some ambiguities on Commons:First_steps/Quality_and_description which I mention on the talk page.

Doing this I noticed that the questions posed on this talk page have not received any answers since around 2010.

This obviously leads to the question of whether the foundation shouldn't perhaps focus on fixing some of the basics of the apparatus before initiating a comparatively insubstantial rebranding process.

The file and category cleanup that constantly needs to happen is already a strain for the community of volunteers and maybe some extra ressources would be required to sufficiently deal with the fundamental deficiencies of the help pages.

After all thousands of images are uploaded every day and most of the occasional users must be facing the same issues and must be confused when trying to find relevant information in the help pages.

Shouldn't there be a more "institutionalised" way of establishing a coherent system of help pages which comprises a routine review of the relevant talk pages and the help desk and using this information to update and generally improve the catalogue of help pages of this central repository of the universe of Wiki... ?

(.. not to mention the state of the help pages of the German and probably many other Wikipedias ..)

best regards,

KaiKemmann (talk) 10:04, 19 June 2020 (UTC)

  • One solution is to use Google search. This gives commons:File_captions. Wouter (talk) 14:58, 19 June 2020 (UTC)
    • If you’re telling people to use an external search engine, instead of your own search engine, to find documentation on your own site, then you have a bigger problem.
    That page says that captions are under CC0. Wait, what? The system didn’t bother to point that out when I went to edit some captions. (Doesn’t bother me, since I put everything under CC0 anyway, but I really think this needs to be changed.) Brianjd (talk) 15:03, 19 June 2020 (UTC)
    • I believe you will have a hard time here finding anyone enthusiastic about captions. They were more or less imposed on Commons by the Wikidata team. - Jmabel ! talk 16:13, 19 June 2020 (UTC)
    • Captions are pointless, a vandal magnet, and confuse newbies by forcing them to enter some vague text in that box before they even get to the real description box where they then realize they have to type in the same thing again. If everyone were not so tired trying to adapt to pandemic fallout and spending our nights worrying about the multiple existential threats, we might have run a RFC to get the upload wizard and image page layout changed back by now. Oh, yes, making them CC0 was never properly agreed with the Commons community when everything we have ever typed here is CC-BY-SA and cannot be "undone" to pretend it's now CC0 and can be cut and paste into a CC0 compliant free database for Google to harvest for a commercial AI service. -- (talk) 05:58, 20 June 2020 (UTC)
      • Actually, what I meant was that the software needs to be changed to make it clear to users that structured data is CC0 (I think it applies to all structured data, not just captions). About changing the policy to not use CC0 at all, it’s a nice idea but it’s too late for that now, isn’t it? Brianjd (talk) 08:37, 23 June 2020 (UTC)
    • Just chiming in to join the chorus that captions are bad. Between annotations, captions, categories, the description template, and structured data statements, we have a very confusing, very cumbersome, and very broken system to essentially have five different things doing roughly the same thing and they have different licenses and with a clunky interface that is outright hostile to users in my estimation. The roll out of structured data here is sincerely the biggest blunder I have seen in 17 years using WMF wikis. I'm not one for mindlessly whining about the WMF and I really don't see why others do so but man, this was 100% forced onto this project with no real forethought and it is a sorely broken system. —Justin (koavf)TCM 08:17, 20 June 2020 (UTC)
    • I’ve commented elsewhere how strongly opposed I am to structured data. It sounds like a nice idea, but they way it has been implemented, it is virtually impossible for ordinary people to use properly. Brianjd (talk) 08:37, 23 June 2020 (UTC)

Thank you for your comments.

I now understand the relation of "caption" and "description" to be a contentious point. And apparently what we see now maybe not to be the final stage of the development?

For the meantime maybe the fields "caption" and "description" could be renamed or annotated in order to make the difference and effects of each a little clearer. For example:

  • "caption - may contain up to 50 words - will appear as the title of the corresponding Wikidata entry - will appear prominently on the file description page"
  • "more detailed description - may contain up to 2000 words - will not appear in the Wikidata entry - will appear ..."

(I have no idea if any of this is correct .. just trying to figure out how the status quo could be improved for ignorant users such as myself ..)

thanks again,

KaiKemmann (talk) 20:14, 30 June 2020 (UTC)

3,000,000 Wikidata Infoboxes in Commons categories[edit]

Just to note that we now have over 3 million Commons categories using {{Wikidata Infobox}} - see Category:Uses of Wikidata Infobox! Thanks. Mike Peel (talk) 20:20, 19 June 2020 (UTC)

June 23[edit]

Retroactively adding a category for a GLAM[edit]

We now have literally thousands of pictures from the Seattle Municipal Archives, but we never set up a category for them as a GLAM. I'd like to remedy that; if we set up such a category, is there an easy way to add the category to all images with https://www.flickr.com/photos/seattlemunicipalarchives as part of their file-page wikitext? That will be at least the bulk of such images; it will certainly be less daunting to find the outliers by hand than to go through finding all of these. - Jmabel ! talk 23:30, 23 June 2020 (UTC)

@Jmabel: I used the search "insource:https://www.flickr.com/photos/seattlemunicipalarchives" and User:BMacZero/gallery.js to generate User:BMacZero/Search results (1539 files). Looks like you can run VFC on that gallery to add the category, or let me know if you want me to tackle it. – BMacZero (🗩) 23:50, 23 June 2020 (UTC)
Actually, you can also run VFC directly on the search results page. – BMacZero (🗩) 23:53, 23 June 2020 (UTC)
@BMacZero: Thanks! I can take it from there. - Jmabel ! talk 23:55, 23 June 2020 (UTC)
No, I guess I can't take it from here. Using regular expressions, I don't see how to reuse a matched string in the replacement, and it looks like there is no relevant example in Help:VisualFileChange.js/samples. Basically I want to match the following regex; this is PHP style, not sure how that compares to what VFC may need:
  • /[|]\s*[Ss]ources\s*=[^|}]*/
Then if we call the matching string %0 (but in fact I have no idea how to refer to it in VFC), I want to replace that by:
  • %0\n{{Seattle Municipal Archives via Flickr}}
Other than the %0 and the \n (newline), that last is a literal string.
Because regexes can be a bit of a "write-only language", let me paraphrase my intent for the match:
  • A single pipe character (and, yes, you can also write that as '\|')…
  • any amount of whitespace…
  • "Sources", initial letter may or may not be capitalized…
  • any amount of whitespace…
  • a single equality character…
  • a string consisting of anything but a pipe character or closing curly bracket, which should bring us to the end of the source field; the next pipe character would be the beginning of the next field; allowing also for the template ending here (no next field).
Can anyone help me out? And can someone document how you use a regex here if you care to reuse the value the regex matches? - Jmabel ! talk 03:56, 24 June 2020 (UTC)
@Jmabel: That's pretty close. If you want to grab part of the matched string for use in the result, you have to wrap it in parenthesis (). /([|]\s*[Ss]ource\s*=[^|}]*)/. And you reference the match with $1 in whatever flavor this is (yes, it's one-based for some reason, I don't know why). – BMacZero (🗩) 04:27, 24 June 2020 (UTC)
Ah, '$' instead of '%'. And probably 1 is first parenthesized expression, 0 is the whole string.
Is the $1 thing documented somewhere, or was this done by a PERLer who just thought that was common sense? - Jmabel ! talk 04:46, 24 June 2020 (UTC)
It's not super well documented, but it's mentioned in the dropdown that enables it (Preserve nowikis, comments. Allow usage of substring and $1 (internal usage of placeholders (%v%f%c%\d+)).). The $ syntax comes from the ECMAScript RegExp standard, which was modeled after but is not exactly the same as the PCRE syntax. AntiCompositeNumber (talk) 05:18, 24 June 2020 (UTC)
We probably should add an example of this in the examples for using VFC. Does someone else want to do that, or should I? - Jmabel ! talk 17:26, 24 June 2020 (UTC)
Having gotten no further response, I'll take that on. - Jmabel ! talk 00:08, 30 June 2020 (UTC)

June 24[edit]

Blazonry[edit]

If you are into shields/blazons/coats-of-arms, and maybe know a code/language called blazonry, you might enjoy my new tool to generate them. --Magnus Manske (talk) 15:22, 24 June 2020 (UTC)

Examples. --Magnus Manske (talk) 15:22, 24 June 2020 (UTC)
this is cool! thx!--RZuo (talk) 19:16, 29 June 2020 (UTC)

June 25[edit]

Category:Books from the Library of Congress[edit]

I notice that this category has many thousands of PDF files, apparently whole books. Do they belong in Commons, or is Wikisource a better place for them? Jim.henderson (talk) 18:34, 25 June 2020 (UTC)

See Commons:Project scope#Allowable reasons for PDF and DjVu formats. -- (talk) 18:50, 25 June 2020 (UTC)
Wikisource makes an digital copy of the text, often using a process called OCR, followed by manual cleanup of errors. In most wikisources this proccess starts with uploading the original file to commons, so the files should remain here.--Snaevar (talk) 23:25, 1 July 2020 (UTC)

June 26[edit]

Taiwan railways[edit]

High speed Chiayi station in 2014 1.jpg
This is not Hsinchu station but a HSL station to the south of Miaoli. I got confused because I later took a train at Hsinchu station, but took no pictures. Does anyone know wich station?Smiley.toerist (talk) 12:10, 26 June 2020 (UTC)
I think it is the THSR Chiayi Station.Smiley.toerist (talk) 19:41, 27 June 2020 (UTC)
Solved, rename started.Smiley.toerist (talk) 17:57, 29 June 2020 (UTC)

June 28[edit]

Making Hot Cat easier to use[edit]

I made this request at MediaWiki talk:Gadget-HotCat.js a couple of weeks ago, but it seems no-one is looking in there.

At the moment when one clicks on hot cat for a category, it opens a drop-down box with five choices, and a scroll bar to make other choices accessible. Given that many categories have 100 or more subcategories to chose from, this makes finding others by scrolling very difficult: a tiny touch of the scroll button and suddenly you're 20 subcategories lower or higher, and missed the others inbetween.

Suggestion: please make Hot Cat tall enough to show 50 choices at a go from the drop-down, not just 5.

Could this see some action, please? Thanks! - MPF (talk) 00:41, 28 June 2020 (UTC)

I would not support this as a default option. I have enough problems with that select box getting in the way as it is. --AntiCompositeNumber (talk) 01:20, 28 June 2020 (UTC)
I am against a change, too, especially for such a huge dropdown list. I answered this on the gadget talk page, but let me phrase it here, as well: Use the dedicated user setting, either JSconfig.keys['HotCatListSize'] or window.hotcat_list_size in your common.js or systemwide in your global.js, cf. Help:Gadget-HotCat. Additionally, you could even remove the arrow button, because if you enter a letter the dropdown is opened anyway; this is JSconfig.keys['HotCatUseCategoryLinks'] or window.hotcat_use_category_links set to false. (I myself use the window variants and can tell you that they work). — Speravir – 03:27, 28 June 2020 (UTC)
i think this is a good idea, but maybe limit it to 10 instead of 50.--RZuo (talk) 19:16, 29 June 2020 (UTC)
Thanks! I didn't know there was any option to set the number; perhaps this option needs to be more prominently advertised in the Hot Cat info? While I'd prefer to be able to set to 50 lines, the 30 maximum currently allowed certainly helps a lot. - MPF (talk) 21:42, 30 June 2020 (UTC)

ZDF German subs need checking, content needs promoting[edit]

Hi there, as mentioned previously I have been adding German subtitles to the 58 high quality ZDF documentary clips. About two thirds now have subtitles, the remainder I am unlikely to subtitle. A few points:

  1. My subtitles are auto transcribed and roughly checked by me. There are errors!
  2. They need a native / high functioning German speaker to check them through! Some have been check but all should be rechecked
    1. Find the subtitled files at category:Videos by Terra X with German subtitle file
  3. The time stamps are mine alone, they should be mostly fine. — Preceding unsigned comment added by JimKillock (talk • contribs) 09:37, 28 June 2020 (UTC)
  4. Checking isn't a difficult job, so please do if you have the ability
  5. German subs are the first step to further usage, beyond German speakers. Once subs are available, other langauge users can
    1. Translate the subs relatively easily, without the pain of doing the timestamps
    2. Consider redubbing the content, adapting any translation as they like

As this is really good content I think multilingual subs and / or redubbing is well worthwhile. I am not well connected within the Wikipedia community though so someone else will need to think about how to do the promotion. If anyone wants to do this or has advice about how to do this please let me know. JimKillock (talk) 09:31, 28 June 2020 (UTC)

@JimKillock: Thanks a lot for that! I've checked all remaining German subtitles. All done now. --Jcornelius (talk) 19:42, 28 June 2020 (UTC)
@Jcornelius: Thank you! That's great – next I will work on some English subtitle files, much as the German this will need checking, but it will be a while before these are ready. JimKillock (talk) 19:54, 28 June 2020 (UTC)

MediaWiki:Licenses[edit]

Please could someone with the necessary rights attend to the changes discussed in MediaWiki talk:Licenses? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:05, 28 June 2020 (UTC)

Expectation of EXIF[edit]

Is there a page documenting the *expectation* of EXIF data in images? I know people often have their uploads questioned if they are without EXIF data, but can't find clear documentation of that requirement. Asaf (WMF) (talk) 11:14, 28 June 2020 (UTC)

Hi Asaf, there's no strict requirement, only Commons:Image_guidelines#Guidelines. It's more of a preference, but does get mentioned at FPC, see special:search/exif prefix:Commons:Featured_picture_candidates.--BevinKacon (talk) 11:38, 28 June 2020 (UTC)
Thank you! While I know it's not strictly required, I find it mentioned not only at FPC, but also at deletion discussions. I understand sometimes the lack of EXIF means the image is indeed not the uploader's own, but there are also cases where one would legitimately want to wipe the EXIF data, e.g. if one took a photo of a household object in one's home, to illustrate an article, but isn't interested in forever exposing the coordinates of that home. So there is no actual policy about this? The guidelines you link to only refer to EXIF in the context of the color space technical information, not as indicator of the provenance of the image. Asaf (WMF) (talk) 12:06, 28 June 2020 (UTC)
We will change or remove any privacy related exif data at the request of the uploader to avoid file deletion. I removed serial number from File:Drone shot of bra.jpg. Not aware of any policy or guideline, only instructional pages.--BevinKacon (talk) 12:18, 28 June 2020 (UTC)
(ec) Just 0.02 but to say that EXIF is only an indicator of things. Not only can it be wiped it can be falsified... For me it is one of many aspects to be looked at. Equally a hard one to make policy on (not least of which people "use" policy in whatever way they wish Face-smile.svg --Herby talk thyme 12:21, 28 June 2020 (UTC)
I have also experienced that certain programs eliminate the EXIF data. For example when image stitching to a panorama. Wouter (talk) 12:33, 28 June 2020 (UTC)
As with others, this is a balance of probability issue, per "significant doubt" in COM:PRP.
Were you to upload a photo with EXIF (apparently) cut off, the file would be well above "significant doubt" in a way that a newbie account might have problems with.
EXIF tampering is a real problem, we have seen vandals deliberately cloning EXIF data on to files lifted from photography websites, or Facebook. As this has been to fake copyright releases, this is taken as serious block-able disruption.
We have had plenty of cases where users want their personal names or GPS data removed from the EXIF already uploaded, and it's not too hard to arrange for a bot to selectively remove specific EXIF tags as needed. This does not mean that all the rest of the EXIF needs to go, and as a norm, we can probably recommend that where privacy issues occur we want folks to not blank the whole EXIF, but retain as much as they feel is relevant to the file without revealing unnecessary detail about the photographer. In particular it should not be a requirement for an uploader to release original EXIF data if they are not comfortable with doing that.
This is a question that comes up regularly, and it would be handy if one of the project guidelines had a summary to point newbies and disputes towards.
Corollary It would be of benefit if the project had a principle that highly technical research on mass EXIF data should be avoided on the public wiki unless there are no potential privacy issues that might cause harm to the photographer. There can be accidental tracking data left in a succession of photographs that could show that someone was, say, at a political protest, or in countries that the police in their home intelligence services would find problematic if the pattern of data is laid out explicitly. I have in mind one contributor living in China using multiple harmless sock accounts, and their anonymity should not be compromised via EXIF GPS tags and lens codes, just because someone likes tracking sock accounts and fancies experimenting with EXIF mapping. -- (talk) 12:59, 28 June 2020 (UTC)
Thank you. Yes, as you say, "This is a question that comes up regularly, and it would be handy if one of the project guidelines had a summary to point newbies and disputes towards." This is precisely what I was looking for (in order to refer people to it). I don't feel I am sufficiently active in Commons as a volunteer to propose guideline changes, but it would be great if some of you reading this who are could propose, discuss, and (if there are no strong objections) enact such a change, so that there is something to point to henceforth. Cheers! Asaf (WMF) (talk) 15:27, 28 June 2020 (UTC)

Editing exif to upload stolen images can go undetected for years, see Commons:Deletion requests/Files uploaded by Marianne Casamance, which involved a user photoshopping files and applying fake camera data to 10,000+ files under multiple accounts.--BevinKacon (talk) 13:30, 28 June 2020 (UTC)

It'd be great if the Upload Wizard offered a choice to remove specific EXIF data like location, serial numbers, and makernotes. (I've tried some free tools that claimed to remove location but didn't, so am sympathetic to those who would want to wipe the whole lot to be sure.) I imagine this may have been proposed or requested before? Pelagic (talk) 15:30, 28 June 2020 (UTC)

Having only delved into EXIF editing modules briefly, the issue with creating a tool is the variety of interpretations that exist for different camera manufacturers, and more recently, mobile phone camera apps. Though there are standards for EXIF data, there are also unspecified extra tags used by photoshop and mobile apps that hold all sorts of edit-time tags, or even extra tracking info like unique serial numbers of software.
Basic tag stripping could be added as a gadget, but if that only handles stuff that would be displayed on image pages, that would be limited to standard EXIF tags, ignore non-standard ones, and probably have to ignore other header data like IPTC. It could be more pragmatic and useful to warn users to review their data themselves before upload, perhaps by providing a link to a WMF hosted header examination tool similar to Jeffrey's excellent version http://exif.regex.info/exif.cgi, and pointing to a guideline pages with example free header data editing tools. -- (talk) 10:36, 29 June 2020 (UTC)

@Asaf (WMF): I think it's important to know that there are many perfectly legitimate reasons for not having Exif data in an image; you might find this discussion interesting where I presented an example by dusting off a very old digital camera :-). As I wrote there, "I often think, when processing deletion requests, that people nowadays tend to suspect copyright violations too quickly if an image is rather small and/or doesn't have EXIF data." If we were to create a summary as suggested by , I think it should be something along the lines of "missing Exif data and/or small size can be reasonable grounds for suspicion, but shouldn't be used as the sole grounds for deletion", and that the context is important. Gestumblindi (talk) 21:51, 2 July 2020 (UTC)

Agreed! So, can we move towards some written guideline around it? I think status quo, where it is both unwritten/invisible and used (too?) frequently to propose deletion, is sub-optimal. Asaf (WMF) (talk) 23:09, 2 July 2020 (UTC)
I suppose that we could expand Commons:Exif, which is currently more about the technical side of Exif data, with a section on the "expectation of Exif" and its limitations. I think I will give it a try soon... Gestumblindi (talk) 12:15, 4 July 2020 (UTC)

June 29[edit]

Mass adding categories[edit]

Suppose I have a list of file names, such as that at the foot of File:Biologia Centrali-Americana (8271463253).jpg. What tool will let me add all of the listed files to a specified category? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:03, 29 June 2020 (UTC)

@Pigsonthewing: I don't know of one for a general list, but for that particular list you could use Cat-a-lot on Special:Search/linksto:"File:Biologia Centrali-Americana (8271463253).jpg". --bjh21 (talk) 15:18, 29 June 2020 (UTC)
A bit roundabout, but you could also copy the list into a gallery on a sandbox page and run VFC on that page. – BMacZero (🗩) 16:29, 29 June 2020 (UTC)

Both clever solutions; thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:05, 29 June 2020 (UTC)

also COM:AWB.--RZuo (talk) 19:16, 29 June 2020 (UTC)

If I could have a preview of a category when my cursor hovers over it[edit]

i am diffusing some categories of persons, but i cant really remember who's who. right now i am clicking into each to see. if commons could have something similar to "Page previews" on wikipedia, such that i can hover over a cat and see the image set to image (P18) or a random one if P18 is not set, it would save so much work!--RZuo (talk) 19:16, 29 June 2020 (UTC)

en:Wikipedia:Tools/Navigation popups - avilable on this project, as a gadget - does that. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:26, 30 June 2020 (UTC)

Is there a tool to expand a specific category tree?[edit]

ReactOS-0.4.13 tree command 667x434.png
something similar to this, so that i can see the entire cat tree.--RZuo (talk) 19:16, 29 June 2020 (UTC)
  • Since category inclusions can be circular, you can't really always do the "entire tree". - Jmabel ! talk 00:06, 30 June 2020 (UTC)

June 30[edit]

Looking for a practical titleblacklist fix for perfectly good batch upload projects[edit]

My many batch upload projects have been running on Commons for many years. There's one very specific and very bad thorn in my side that wastes huge amounts of volunteer time, and for which there is no technical fix apart from playing around for every unique upload project trying to juggle official archive supplied titles into something that might pass the ever changing and ever increasing burden of the titleblacklist.

In practice, I simply don't bother, and many thousands of public domain images are missing from Commons, regardless of individual educational value. The balance between endless debugging and spending valuable volunteer time on the next project instead, just works out that way.

Here's an example from a few minutes ago:

APIError: titleblacklist-forbidden:
The title "File:Joannis Marianae Hispani, e Societate Jesu, De rege et regis institutione libri III - ad Philippum III Hispaniae regem catholicum. Eiusdem De ponderibus & mensuris liber (IA joannismarianaeh00mari).pdf" has been banned from creation.
It matches the following blacklist entry: " .*(richero|marian).*(maria|richero).*"

Ref: https://archive.org/details/joannismarianaeh00mari

Clearly when the Internet archive unique ID matches a proper name in the official title of a 17th Century public domain book is a reason to effectively permanently ban uploads of the work, there is something seriously wrong with the way titles are blacklisted, and something seriously wrong with the fact that batch uploaders like myself cannot get an exemption flag.

Thoughts about what should change, or do I walk on again, accepting that due to local design flaws, Commons will never have these works and Commons can never magically expect to have enough programming resources to keep fixing work-arounds because nobody can be allowed to have a positive exemption for the "titleblacklist"? Thanks -- (talk) 14:11, 30 June 2020 (UTC)

Addendum same goes for the spamblacklist, which is also stopping the upload of the various randomly used short-urls that curators frequently use in their archive descriptions, see recent problems. -- (talk) 15:58, 30 June 2020 (UTC)
  • For starters, I'll make a strong guess that should be two distinct blacklist entries: " .*richero.*maria.*" and " .*marian.*richero).*". (I'd also guess that the leading blank is an error.) But, yes, there really ought to be an exemption flag. - Jmabel ! talk 15:41, 30 June 2020 (UTC)
  • I would support granting Commons:Template editor to users who regularly need to override the blacklist, even if they do not actually edit templates. -- King of ♥ 16:14, 30 June 2020 (UTC)
    That would grant tboverride but is there a group that does the spam exemptions on contents? Seems that one could request the specific flags, or bundle them in a specific new group. -- (talk) 16:23, 30 June 2020 (UTC)
    I think tboverride is sufficient to cover everything, as I don't see any other right in Special:ListGroupRights that serves to allow overriding a blacklist. On the English Wikipedia, there is precedent for granting unnecessary permissions to people unlikely to abuse them when actual technical implementation of the correct permission set is months or years away. For example, TonyBallioni was granted intadmin to view deleted JS/CSS pages (as part of his anti-sockpuppetry work) even though the right exists primarily for people who edit such pages, because a bug currently prevents regular admins from doing so. -- King of ♥ 16:42, 30 June 2020 (UTC)
This does look like a pragmatic thing to try. Thanks for the suggestion. Added at Commons:Requests for rights. -- (talk) 16:55, 30 June 2020 (UTC)
Can the short youtube link just be replaced with the full version before upload?--BevinKacon (talk) 16:39, 30 June 2020 (UTC)
There's lots that can be done, and I have done such fixes in the past by parsing out urls and sniffing the redirects. However I'm not a spammer, and if the official metadata written by curators elsewhere being used to create the texts use these shorturls, all the extra processing and volunteer programming time spend working out how to get around an ever evolving spamblacklist just seems, wasteful, when it could be spend on sorting out more content. Keep in mind this isn't just "tu.be" it's also all other other trapped forms of shorturl and whatever other unexplained regexes get added. -- (talk) 16:47, 30 June 2020 (UTC)
  • It seems that you can include blocked URLs as long as you put them in <includeonly>...</includeonly> tags: Special:Diff/429954071. So you might be able to work around the spam blacklist by putting the URL in a template. The template might have to be created after you transclude it on the file information page.
Sorry for spamming the blacklist log a bit while testing stuff. --Stefan2 (talk) 19:55, 30 June 2020 (UTC)
Am I right in thinking that, if selected users are allowed to upload blacklisted URLs, then other users would not be able to save (unrelated) edits to the affected pages? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:40, 1 July 2020 (UTC)

Category needs cleanup template[edit]

Do you think we need a "Category needs cleanup" template? SpinnerLaserz (talk) 19:32, 30 June 2020 (UTC)

  • @SpinnerLaserz: Could you please be more specific about the problem for which you are proposing a solution? - Jmabel ! talk 01:08, 1 July 2020 (UTC)
  • Some of the categories have pictures that are not the focus (e.g. A house picture that incidentally contains a statue). SpinnerLaserz (talk) 01:25, 1 July 2020 (UTC)

July 01[edit]

Annual contest Wikipedia Pages Wanting Photos[edit]

Wikipedia Pages Wanting Photos (WPWP)

This is to invite you to join the Wikipedia Pages Wanting Photos (WPWP) campaign to help improve Wikipedia articles with photos and win prizes. The campaign starts today 1st July 2020 and closes 31st August 2020.

The campaign primarily aims at using images from Wikimedia Commons on Wikipedia articles that are lacking images. Participants will choose among Wikipedia pages without photo images, then add a suitable file from among the many thousands of photos in the Wikimedia Commons, especially those uploaded from thematic contests (Wiki Loves Africa, Wiki Loves Earth, Wiki Loves Folklore, etc.) over the years.

Please visit the campaign page to learn more about the WPWP Campaign.

With kind regards,

Thank you,

Deborah Schwartz Jacobs, Communities Liaison, On behalf of the Wikipedia Pages Wanting Photos Organizing Team - 08:24, 1 July 2020 (UTC)

feel free to translate this message to your local language when this helps your community — Preceding unsigned comment added by Romaine (talk • contribs) 2020-07-01 08:24:25 (UTC)

Non-commercial use licence - Is it possible sometimes?[edit]

In 2017 I made these authorized shots at en:Accademia della Crusca, Italy. There was some kind of agreement for a cc-by-sa licence back in the days, but I no longer have emails archived about that, and neither they can find. I cannot remeber if it was more a verbal agreement and I regret the situation looks unclear now. They are now telling me they would prefer the images to have a non-commercial licence. Is it possible, in some very special cases, to change this? Or will we just have to delete all the images? I really have no idea what to do, any help or suggestion would be very welcome. Thank you. --Sailko (talk) 15:49, 1 July 2020 (UTC)

We do not accept NC licenses as the sole license under any circumstances. However, we won't need to delete the images. They are not the copyright holder, so are not in a position to offer any sort of copyright permission, assuming the original works are all PD. Unless you signed some statement that allows them to restrict your ability to exercise your rights as copyright holder, they do not have any claim to the images once they are already made. -- King of ♥ 16:11, 1 July 2020 (UTC)
Thank you. I will discuss more with the insitution, and I think I can also use this disclaimer (as it is a public insititution from 2012) in order to avoid posible legal issues in the future. --Sailko (talk) 16:34, 1 July 2020 (UTC)
Sailko, I do not want to sound heartless, but your arrangements with Accademia della Crusca for access to the objects are yours. Once photographs are taken you are the only copyright holder, and after the upload the images belong to the community. From the community perspective even unauthorized shots, taken against the house rules are OK as long as objects are in public domain. We do not encourage people to break the rules but do not have any policies which would justify deletion in such a cases. I realize that such position might complicate future access to similar material, and as community we should do as much as possible to help in any way very valuable contributors like you, but deletion of images or even license change to more restrictive license would be taken only in a special cases as an exception to a rule. You are welcome to blame out policies in your future talks with the institution. --Jarekt (talk) 21:37, 1 July 2020 (UTC)
This discussion just reminded me whether we should revisit File:Notre-Dame de Montréal Basilica Jan 2006.jpg by Diliff, which was deleted because the photographer signed a non-commercial agreement with the property owner (see w:Wikipedia:Featured picture candidates/Notre dame basillica delist). In my opinion, even if the entity that controls access to a photography location requires a photographer to sign a waiver agreeing not to use the image for commercial purposes, Commons may nonetheless be able to accept such images. After all, if the photographer never agreed to transfer or share copyright with the property owner (in contrast to w:Burning Man#Photography restrictions) and the property owner has no copyright interest in the original work (either because it is PD-old or because it falls within that country's definition of "public place" for the purposes of COM:FOP), then I don't see how the property owner can make a copyright claim against the image. Reusers are at no legal risk here because the image violates no copyrights. Whether the photographer could be liable for breach of contract if other people use it outside Wikimedia would depend on the actual contract terms, so we'll be particularly sensitive to uploader requests to delete. But if they are OK with having it here I see no reason not to allow it; any legal uncertainty around the image is merely COM:NCR. -- King of ♥ 22:17, 1 July 2020 (UTC)
There are no copyright reasons for that image deletion. If this case was discussed now and the user feels that breaking the house rules exposes him to potential legal trouble and he wants it deleted we could delete it as a courtesy to the user. Otherwise it should be kept. That image was deleted 14 years ago, Diliff if you are OK with it I would just undelete the image. --Jarekt (talk) 02:41, 2 July 2020 (UTC)

July 02[edit]

Racial stereotyping in art[edit]

Category:Black people in art and its subcategories contain a mixture of positive representations of Black people and historic images which use outdated racial stereotypes (example). I'd like to split the negative images into sub-categories. What name should be used? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:29, 2 July 2020 (UTC)

Keep it simple, perhaps "historic representations of black people in art". Though some will be intentionally racist, not all will be deliberately negative racial stereotypes when created, but it's a difficult thing to judge which would cause offence today in different contexts. How these should be displayed to our readers and reusers may be something to work on, without crossing into 'censorship'.
For those interested in the topic of presenting racist materials, there is a discussion at meta:Talk:Black_Lives_Matter#Scientific_racism that lists example articles and images that badly represent the material and in some cases promote misinformation about race. Where and how we improve this situation is something still being thought through. -- (talk) 13:27, 2 July 2020 (UTC)
I'm not a fan of using the word "historic" in category names, as the meaning of it is not clear. -- King of ♥ 17:22, 2 July 2020 (UTC)
+1 (to King of ♥). - Jmabel ! talk 21:20, 2 July 2020 (UTC)
Sure, what would work better? -- (talk) 21:40, 2 July 2020 (UTC)
Perhaps just diffuse it by decade? -- King of ♥ 21:43, 2 July 2020 (UTC)
Does Commons have a template that could be used to mark "objectionable" items for expert review and potential deletion (apart from the normal DR process)? ShakespeareFan00 (talk) 08:20, 3 July 2020 (UTC)
No.
There would be grounds for a form of 'expert review' depending on who we think is an expert, but each type of objectionable nature would need a consensus about whether we need to see certain types of warnings (e.g. Nazi symbols, a legal requirement in some countries) or a level of sourcing (e.g. misleading maps or flags to settle disputes) or level of unique educational value (e.g. sexually explicit photographs).
Stepping beyond creating a backlog of 'expert review' might be an issue against NOTCENSORED. -- (talk) 10:07, 3 July 2020 (UTC)
This was about 'objectionable' in the context of materials expressing views or representations of certain groups, where the views or representations expressed could be deemed racist or extremist (even if the material is from prior to contemporary times.). Commons may not be censored, but given that some European jurisdictions (and internet platforms) are considering tougher laws and policies about extremist media online, up-to effectively blocking entire domains, having the discussion seems timely. As you are certainly aware balancing appropriate context for academic use of contentious images, against the potential to offend or as you justifiably mention the need to comply with applicable local legislation, does not necessarily have easy solutions. Commons contributors are not necessarily legal (or for that matter academic) specialists, which was why the option to flag something for review by someone more qualified was desirable.

ShakespeareFan00 (talk) 11:30, 3 July 2020 (UTC)

Book template effectively eats itself[edit]

Could we please agree to fix the {{Book}} and remove the inset image of the book that simply duplicates the book being displayed on the same image page?

There's no really good reason for doing this, it means that every single book includes a link to itself. In addition the infobox display space can be halved as every field being displayed is then limited to only go as far as the left-hand edge of the inset book image.

For example File:George Engelmann -botanical notebook 8 - Cereus (IA mobot31753003969836).pdf on my display has multiple unnecessary extra lines do to excessive text wrapping. Due to the IA books project I may be becoming the most active user of this template, and I'm wondering if I should create my own version just to work around its bad display.

Thanks -- (talk) 13:19, 2 July 2020 (UTC)

  • If we do that, we have to make it somehow conditional, so it can have that link from a file that shows a single page. - Jmabel ! talk 15:23, 2 July 2020 (UTC)
Book template from day one had "image" parameter meant for display of the title page. Originally the template was mostly used for books stored as one image per page and "image" was storing a filename of the title page. Once we started to use PDF/DjVu files the expectation was that "Image page" is a parameter with a page number of the title page which will be shown. Once we began to use Wikidata to store most of Book metadata, so it can be shared with Wikisource and other projects the page number usually comes from there. In a rare case when the title page number is not provided (here or on Wikidata) than the template's fall back is the first page, hopefully as a reminder for the users to specify the title page number either in the template or at Wikidata. If there is consensus to do so I could create "noimage" boolean parameter to suppress image addition, it is just not an issue which was ever requested before (as far as I can recall). --Jarekt (talk) 18:43, 2 July 2020 (UTC)
Having just used this for 176,000 multipage PDFs, yes it needs to be suppressed. -- (talk) 19:12, 2 July 2020 (UTC)

NARA template category issue[edit]

Category:National Archives and Records Administration institution templates is flooded with individual files; I have not, so far, been able to track down the cause. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:26, 2 July 2020 (UTC)

@Pigsonthewing: I think I've fixed this in Special:Diff/430340095. --bjh21 (talk) 17:26, 2 July 2020 (UTC)
Note that it will probably take a few weeks for the changes to be visible in the category itself, since templated category moves are done in the background by MediaWiki. --bjh21 (talk) 11:59, 3 July 2020 (UTC)

{{Geogroup}} has aesthetically worsened. What should I do?[edit]

In the last couple of weeks {{Geogroup}} has been edited by User:Verdy p, and it is causing a serious layout problem for hundreds of category pages using it. I have requested the fix or the reverts, but he doesn't even recognize the problem. As a result of his edits, hundreds of minor edits like this might be needed, which is likely to expend quite a many hours or days. Should I accept his edits and consume some days fixing these categories, or can I revert his edits? Could somebody restores the template's function as of ? --トトト (talk) 15:46, 2 July 2020 (UTC)

Worsened ? It has been internationalized and properly aligned with the Infobox. You did not recognize that the problem was in the few categories that you maintained in Japan. This tempalte is not specific to Japan... There's no problem at all in the few samples you indicated to me.
Yes some edits may be needed, but very few compared to the tons where this works properly. And it has been internationalized as well (including for Japanese). Your asserted problem of alignemnt is based on a false assumption: that the "alignment" is identical on your screen with all browsers, all languages, all fonts installed. And I made sure that it works also on all sizes of displays (including small ones on smartphones), and with several themes in user prefererences or in the Mobile version of the wiki. verdy_p (talk) 15:53, 2 July 2020 (UTC)
Note that this tempalte is usually located below the infobox, beside the listed members of the category, it's not an "informative" template but a search tool for helping categorizing the contents (medias) which are at the bottom of the category pages, after the subcategories (and frequently needed for overpopualted categories where many items have not beedn subcategorized properly or were categorized in the wrong one). It is not a navigation box for visitors browsing the categories or searching some relevant content, but a tool for maintainers...
Its size is properly set, it does not obsucre the content of the category pages. It is minimized to jsut what can fit, but still it is translated. View the pages using a different windows size, or with the mobile version, or on a smartphone, or using a different suer language. You'll see that your assumptions based on the old versions were in fact completely untrue. verdy_p (talk) 16:01, 2 July 2020 (UTC)
  • No, it is an informative template even for visitors, as it enables one to search an image as if in Panoramio. After your edits this small box became impossible to be placed above {{Prefectures of Japan22}}, for example, as it tries to come under another template. For example, in this category page, it is not longer shown above {{Prefectures of Japan22}}, but right to it, thus enlarging {{Prefectures of Japan22}}'s height when browsed in a small display. Ugly. Back then {{Geogroup}} was more versatilely placed within a page, under various page layouts. Why are you minizimizing it as for maintainers only? And being used in a non-U.S-related category is completely irrelevant. The fact is your edits have destroyed the layout of categories which were neatly set prior to June 23. Please fix it to be able to placed above another template, if choiced. Or should I create another one from the version of April 14? It used to be a simpler, and thus more usable template. --トトト (talk) 22:10, 2 July 2020 (UTC)
Your terms are excessive. I've not "destroyed" anything, and you still don't want to see that this template has a VARIABLE content, it can use different texts, can have more or less items displayed, the lecngth of the text can vary depending on language, fonts, OS, browser, zoom level... It has always been floatting, I did not change that. Your assumption that the change of size is not what you like is wrong, the size has always been variable, including the width depending on zoom and user preferences in the wiki or in the browser. All I did was to make sure the tempalte had a minimum size without wasting space, because it is floatting, and allow it to be internationalized to other languages (including RTL languages: Arabic, Hebrew). verdy_p (talk) 14:01, 3 July 2020 (UTC)
Anyway your page is also a very bad example of what NOT to do in HTML and what not to expect.Yuo've placed te Geogroup template at top before everything, so it's notmal that it starts at the stop. And as it has also been floatting, it was also displayed at the same level as the two translated description texts in English and Japanese, and then only you had the tempalte sowhing the list of preferectures, so it has ANREADY below the Geograoup template (illogically). Don't blame me for things you did incorrectly yourself ! Your statements are simply compeltelty false. You are lying (and in addition I complain about your attitude because you've already sent birds name against me, I've been patient but now you continue here). verdy_p (talk) 14:09, 3 July 2020 (UTC)
And it looks fine even after... Nothing is "broken", as was stated. verdy_p (talk) 14
32, 3 July 2020 (UTC)

What's so bad with 14 April 2020 version?[edit]

I will show how it looked like before User:Verdy p makes changes after 23 June. Please see April 2020 in Yamagata prefecture. Versatility of this template in a usage like this should be kept. Moreover, the box looks neat as it is vertically slim even when the parameter level=1 is inserted. Opinions of other users are expected. --トトト (talk) 16:50, 3 July 2020 (UTC)

OS you don't wnat any internationalization of these custom templates you did and don't wnat any adaptation to different browsers/languages/fonts. Dates indicated jsut by digits are just wrong as well, and in everywhere else the lateral navigation to sister categories are at top before the content of the categoy itself (its description, its detailed navboxes for its own **sub**categories (not parent categories, the infobox). Even the Geogroup is a detail of the content, and should be after the navigation between **different** prefectures (outside the current category).
You are illogical and ignore the basic needs of this international wiki which is also not specific to a single language (not just Japanese or English).
The two boes have NEVER been esually sized, their hight varies, one of them (the Geogroup) being floatting and sized to fit well with infoboxes. And visibly you don't want infoboxes there are well (sooner or later they will be added by any one) verdy_p (talk) 16:58, 3 July 2020 (UTC)
And your statements about "my sincerity" is just a personal attack. I did not attack you with personal judgements like you did repeatedly. My intents are clear and to offer the best for everyone. I did not break anything. You just did not look enough about the effect: did you try the mobile version? Did you try to reduce the window ? Did you try to use another language ? Did you try to use zoomin in your browser (liek many do for acessibility reasons). Your statements that the two boxes should "neatly" align vertically had never been true. And you add extra vertical spacing with extra newlines, this is just a quirk and pollution. verdy_p (talk) 17:02, 3 July 2020 (UTC)
I rarely use Japanese as dault setting when visiting commons. Visitors also browse around commons in English. So what I am demanding has almost nothing to do with the language setting. --トトト (talk) 17:15, 3 July 2020 (UTC)
So you don't care about languages, font sizes (zoom in browsers), mobile versions, other themes in user preferences.... you seem to live in a small world. Anyway why do you want to post the lateral navigation box at the **bottom**. And what would happen if there's a wikidata infobox added ? Your assumption would be destroyed as well.
Lateral navigation should be at top (and compact) before the infoboxes and all tools and description in the main part. These Geotools have always been placed at the bottom (yes they are informative, and most often they don't work as they are external tools, their list is expansible or reducible as well: the Geotools have already had several ones disabled as they were broken, no longer working, or pending other external changes. They are NOT part of Commons itself (in fact thye should finally be integrated in the Wikidata Infobox where there are already other external tools displayed at the bottom (such as Reasonator). These tools are just complements of the infobox. Many odf them are legacy/unmaintained. verdy_p (talk) 17:35, 3 July 2020 (UTC)
Perhaps most of the your edits on {{Geogroup}} are to intendedn to adopt with {{Wikidata infobox}}, I guess? If so, why don't you creat another variant of this template, {{Geogroup3}}, for example, specially designed for {{Wikidata infobox}}? Currently {{Wikidata infobox}} is providing no useful information at categories like Coats of arms of Germany, showing the meaningless letters Q9560456 Wikimedia-categorie. I see it takes a decade or two, or even a century for {{Wikidata infobox}} to be trully useful at all of category pages in commons. So maintaining a category without {{Wikidata infobox}} is still important. That is the rationale of my demand. Besides, I have never seen this template used inside {{Wikidata infobox}} up until now. --トトト (talk) 18:03, 3 July 2020 (UTC)

Some CC sites[edit]

Does anyone know if there are any issues with using material from the following sites:

They all make claims to have CC (usually CC0) material. JimKillock (talk) 16:55, 2 July 2020 (UTC)

Each of them is user-submitted content, so I would treat it just like Flickr; if it looks like the uploader did in fact create the material, then it's OK. -- King of ♥ 17:21, 2 July 2020 (UTC)

Feedback on movement names[edit]

Hello. Apologies if you are not reading this message in your native language. Please help translate to your language if necessary. Thank you!

There are a lot of conversations happening about the future of our movement names. We hope that you are part of these discussions and that your community is represented.

Since 16 June, the Foundation Brand Team has been running a survey in 7 languages about 3 naming options. There are also community members sharing concerns about renaming in a Community Open Letter.

Our goal in this call for feedback is to hear from across the community, so we encourage you to participate in the survey, the open letter, or both. The survey will go through 7 July in all timezones. Input from the survey and discussions will be analyzed and published on Meta-Wiki.

Thanks for thinking about the future of the movement, --The Brand Project team, 20:33, 2 July 2020 (UTC)

Note: The survey is conducted via a third-party service, which may subject it to additional terms. For more information on privacy and data-handling, see the survey privacy statement.

July 03[edit]

Is it safe to upload the protest photos under Hong Kong national security law?[edit]

Starting from last night, the government mention Anyone advocating independence, liberation or revolution in public can be immediately arrested (Even showing "Liberate Hong Kong" images). Is it safe for Wikipedia user to upload these photos? Many media and news agency can have well protection for the staff, but Wikipedia don't have this policy. Standing Committee of the National People's Congress (NPCSC) member, Tam Yiu-chung, even said the media reports involving Hong Kong independence, police violence and other news may also be accused of inciting separatism and subverting state power 【港版國安法】譚耀宗指傳媒揭警暴或犯煽動顛覆政權 記協:條頸架咗把刀. Can Wikipedia commons can provide the measures, to ensure the safety of the user to upload the media and not be arrested. --45.8.223.9 03:16, 3 July 2020 (UTC)

I am not sure what you mean by safety measures. Ruslik (talk) 05:19, 3 July 2020 (UTC)
No.
At this moment the safest course of action for anyone living in Hong Kong would be not to edit articles about Hong Kong and not to upload photographs to Commons taken in Hong Kong, probably of anything. Subverting the state could have an extremely wide interpretation. -- (talk) 06:03, 3 July 2020 (UTC)
  • The anonymous nature of contributions is strictly protected by our policies, however Wikimedia Commons is part of a bigger whole and is subject to a "term of use"; no one is immune from legal consequences as regards their own actions, see Terms_of_Use and Privacy policy. Christian Ferrer (talk) 11:15, 3 July 2020 (UTC)

I think it's unlikely that the Wikimedia Foundation would divulge the IP address or other information about a pseudonymous uploader who didn't break any US law to Chinese authorities, but that's just my personal opinion. But even then, an uploader could be identifiable if they by accident have their real name in the Exif data or have associated their pseudonym with their identity publicly somewhere. Gestumblindi (talk) 18:32, 3 July 2020 (UTC)

"I think it's unlikely that the Wikimedia Foundation would divulge the IP address": I would tend to agree (or would want to agree) however Wikimedia Foundation will obey to a US legal decision, and that fact escape to us and escape to the Wikimedia Foundation as well. Nobody knows what the next day will be or what the agreements between the countries will be, for example Usa / China. + see below Christian Ferrer (talk) 18:51, 3 July 2020 (UTC)
It's a safe bet that should a state sponsored agent have already hacked the WMF servers, or have means to sniff connections during routing at the hardware level, like, er, we know some government agencies have for telecomms that cross their borders, then the WMF will wash their hands very quickly of any liability for damages, and probably do not have the right resources to "prove" they are secure.
... and this scenario isn't even close to being a conspiracy theory. -- (talk) 18:39, 3 July 2020 (UTC)
True, WMF servers can be hacked, especially by governmental or non-governmental entities which have substantial technical means. Christian Ferrer (talk) 18:59, 3 July 2020 (UTC)
No server-side hacking is necessary, it is a reasonable assumption that the NSA and the governments of China and Russia are already capable of decoding every encrypted Internet packet. -- King of ♥ 19:30, 3 July 2020 (UTC)
Haven't the revealings of Edward Snowden shown that these agencies have, in fact, a hard time with encrypted communication? Much of the surveillance, at least back then, relied on unencrypted connections. Personally, I wouldn't see them as so all-powerful as some people think. But I think that a discussion of this topic here will not be very fruitful. Gestumblindi (talk) 19:52, 3 July 2020 (UTC)
  • No one can decently advise someone here to potentially take legal risks in their country of origin, and claim that they will be protected here. Christian Ferrer (talk) 19:05, 3 July 2020 (UTC)
besides, it is inappropriate to advise here any risk whatsoever, however laudable the action we are talking about. Christian Ferrer (talk) 19:10, 3 July 2020 (UTC)
Governments can also apply pressure in other ways.. Anyone here recall what happened to a French admin over a contentious photo of a military installation? ShakespeareFan00 (talk) 20:16, 3 July 2020 (UTC)
That story is described here. Apparently it was only possible in this form because the administrator, a rather prominent figure and then President of Wikimedia France, was easily identifiable. Most volunteers who use a pseudonym and don't divulge their personal information should be safer, but of course there are no guarantees. Gestumblindi (talk) 20:32, 3 July 2020 (UTC)

Open for signatures - Community open letter on renaming[edit]

Dear all,

There is an open letter that requests a pause to renaming activities being pursued by the Wikimedia Foundation 2030 Brand Project.

Individual editors and affiliates can sign with their logged-in account to show support.

The letter focuses on concerns about the process, and not about specific naming choices. With 50 major chapters and affiliates and 600+ individuals signing the statement, and more than a dozen translations, we are seeing great interest in this issue.

Related to this: the branding team is conducting a survey that runs until July 7. There is concern that the consultation process and options on the survey do not adequately reflect community sentiment, given the effect name changes for the foundation and movement would have. This served as a motivation for the open letter. Useful links are below:

  • Brand survey for individuals - Qualtrics survey. If there are options you would like to highlight outside of the three provided, it is possible to write in your own options and views at the end of the survey.

There will be a WMF board meeting scheduled in July to discuss the branding issue, so it is important to express your views now.

Thanks - Fuzheado (talk) 13:45, 3 July 2020 (UTC)

July 04[edit]

Responding to multiple deletion requests[edit]

Hywel72 has requested the deletion of several of his images (about 80), using separate deletion requests for each file. I am not making a complaint; Hywel72 is free to request deletion of the images, but in the absence of other issues we are free to keep them. I have reviewed some of the images and commented on the DR pages: several are useful or potentially useful, but I have only identified one with a clear reason for deletion. I think most of the images could usefully be kept, but I am reluctant to spend the time needed to review them all.

Is there a way to retrospectively group the individual requests into a batch request, so that I and other people can comment on them collectively? Verbcatcher (talk) 01:22, 4 July 2020 (UTC)

  • You could create a page that transcludes them all (the same was the daily DR page does) and has a section for comments on them collectively. If you want to be more ambitious (probably with some sort of tool, but I don't know what would work) you could then "demote" all their headings by one level, and use that new page in DR instead of including them directly in DR. Seems like it might be more work than it's worth; someone else may have a suggestion. - Jmabel ! talk 16:14, 4 July 2020 (UTC)
@Verbcatcher: I've done this on a couple of occasions where it was clear that a bulk DR would have been more appropriate. I created a new DR, copied the existing DRs into it, replaced each of the original DRs with a redirect to the new one, and made appropriate changes to all the pages that transcluded the DR. It was a lot of work and I can't really say I recommend it unless you're expecting a lot of discussion and manage to catch it early. In this case many of the DRs have additional reasons, and people (me included) have provided image-specific responses, so I think it's rather too late. --bjh21 (talk) 18:45, 4 July 2020 (UTC)

MOTD emergency[edit]

We just went an hour and a half with no COM:MOTD on the main page; I quickly found something and stuck it in Template:Motd/2020-07-04. But Template:Motd/2020-07 is still barely halfway filled, so I'm calling on everyone to help fill in the blanks. Thanks, King of ♥ 01:44, 4 July 2020 (UTC)

We just had a discussion about changing to MOTW, but was assured by long term contributors that there were enough active volunteers to make it work daily rather than weekly, and work at a higher quality.
Do we need another go at that discussion?
My mistake, it's not closed yet. Go vote on it:
Commons:Village pump/Proposals#Turn MOTD into MOTW
-- (talk) 16:00, 4 July 2020 (UTC)

Announcement for License reviewers[edit]

You can now visit User:EatchaBot/Files-requiring-license-review-sorted-list for a sorted list of users by number of files requiring license review. This includes images, videos and sounds. Updated every 48 hours. // Eatcha (talk) 16:51, 4 July 2020 (UTC)

I would like to add that there is now a new optional parameter on {{LicenseReview}} called custom_text, allowing reviewers to review a website and document evidence other than a free license. For example:
  • File:Dave Leduc - MLWC 2018.jpg: I reviewed a Facebook post which named the pseudonymous author on August 30, 2018. As the Commons account predates the photo, it serves as proof that the Commons uploader is not an impostor and is therefore authorized to release the photo under a free license.
  • File:廖城兰(大马美食家食公子)造型照.jpg: The uploader has had various copyright issues in the past, so I'm not just going to believe that they took a photo with an expensive medium format camera without evidence. I reviewed a Google Drive folder showing the camera being set up for the shot, thus substantiating their claims.
King of ♥ 16:58, 4 July 2020 (UTC)

Legal warning templates[edit]

I've just come across Template:Georgian boundaries. From the way it is written, especially the bolding, it could be read as advice or as a chilling warning. Is such a template useful/a good idea, and if so how should it be distributed across images? Chipmunkdavis (talk) 18:25, 4 July 2020 (UTC)

Such warnings seem important, if you're a re-user from Georgia you might accidentally use a map that can put you in jail. A similar warning exists for Socialist symbols, please see "{{Communist symbol}}". Wikimedia Commons should be as "safe" as possible for re-users, the warning isn't saying that we will punish people, it's saying that the Georgian government may punish them. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:24, 4 July 2020 (UTC)

July 05[edit]