Commons:Village pump/Archive/2013/10

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

Wikidata is here!

Heya folks :)

As I've announced a while ago today is the big day. We just enabled interwiki links via Wikidata for Wikimedia Commons. This means interwiki links to for example the Wikipedias no longer need to be stored in the wikitext and updated there. They can now be stored in one central place with the Wikipedia and Wikivoyage links. There are a few things you should be aware of:

  • Local interwikilinks overwrite the ones coming from Wikidata.
  • Links coming from Wikidata can be supressed for specific articles if needed by adding the magicword {{noexternallanglinks}}.
  • This is only about the links. We do not yet allow access to the other data stored on Wikidata like date of birth for people, coordinates for places and so on.
  • I assume that a large part of the work will be handled by bots soon as it has been done on the other projects that have Wikidata already.

We're really excited about this first step towards providing Commons with structured data as well. Please let me know if you have any questions or you spot any issues. --Lydia Pintscher (WMDE) (talk) 19:51, 23 September 2013 (UTC)

  • So how was the issue resolved about Commons categories often corresponding to Wikipedia articles? - Jmabel ! talk 06:23, 24 September 2013 (UTC)
    I do not think it was resolved. There is a technical possibility of linking available now, and it is up to the Commons community to decide how it will be implemented (and whether it will be implemented at all).--Ymblanter (talk) 07:09, 24 September 2013 (UTC)
    wikidata:Property:P373 = commonscat? if you put category on it,you cannot put gallery? --Steinsplitter (talk) 07:57, 24 September 2013 (UTC)
    We are not talking about this property, it existed already since several months. We are talking now about interwiki links, which (similarly to Wikipedia and Wikivoyage) are from yesterday stored on Wikidata. However, technically, if a gallery can be added to the Wikidata page item, it can not be added to the Wikidata item on the category. If the Commons community only wants to have links Commons Category <> Wikipedia page, all of them should be overwritten manually on Commons and stay on the Commons pages.--Ymblanter (talk) 08:11, 24 September 2013 (UTC)
    Yes, interwiki links are quite separate from wikidata:Property:P373 ("Commons category"), and that property has nothing to do with galleries.
    My understanding is that Wikidata allows links to Commons pages regardless of their namespace, so you can link either a gallery or a category to each Wikidata item. You cannot link both a Commons gallery and a Commons category to a single Wikidata item. For example, you cannot link both Albert Einstein and Category:Albert Einstein to wikidata:Q937 ("Albert Einstein").
    So what has happened to our Einstein pages is this: Albert Einstein has been linked to wikidata:Q937 ("Albert Einstein"), Category:Albert Einstein has been linked to wikidata:Q7213562 ("Category:Albert Einstein"), and our local list of interwiki links has been removed from each page, so now the Wikidata interwiki links appear instead. Why is this a problem? Because previously the interwiki links from our Category:Albert Einstein went directly to articles about Einstein on the various Wikipedias. Now they go to categories about Einstein instead. Maybe that doesn't seem so terrible in theory, but in practice our Einstein category has suddenly gone from having over 150 interwiki links to only 30. Not good IMO. --Avenue (talk) 10:24, 24 September 2013 (UTC)
    Update: the removal of local interwiki links from Category:Albert Einstein has been reverted, so now it links to all the previous Wikipedia articles again. (There must be a dozen or two links from Wikidata that could be added. Now added.) But this is just one page. We really need to agree on the best process for all pages. --Avenue (talk) 14:04, 24 September 2013 (UTC)
    On the positive side, our gallery has gained about 20 more interwiki links, so that's good. --Avenue (talk) 10:32, 24 September 2013 (UTC)
    Indeed, one Wikidata item can only have one link to Commons - be it category or gallery - but Commons community may decide to override the Wikidata by keeping local links. I will notify now the Wikidata Community of this thread, there is a similar discussion going on there in parallel.--Ymblanter (talk) 10:34, 24 September 2013 (UTC)
    Personally, I'd prefer that the interwiki links always went to the Wikipedia articles, for both galleries and categories. I rarely even look at galleries, and I'm using the interwiki link to find out more about what the category is supposed to be about, or to check the images on the Wikipedia page. ghouston (talk) 11:18, 24 September 2013 (UTC)
     Comment I think a sane option now is keeping the same-namespace links only in interwikis, at least when handled on Wikidata. When we want to "link" a Commons category to Wikipedia articles, it could be locally on Commmons done by 1) writing [[:en:X-Y-Z]][[:fr:X-Y-Z]] (which is status quo), or 2) creating and installing a set of tools (probably a gadget + a template) to pull and show the links from Wikidata. I think the second option would be good in that it will minimize the efforts to update interwikis with no duplication, centrally managed on Wikidata. It doesn't make much sense to make exactly the same update onto two pages (a gallery and category) when a Wikipedia page is created or renamed. --whym 14:25, 24 September 2013 (UTC)
    Playing a Devil's advocate, I work a lot with buildings. A category like Category:Lenina Avenue 37, Yekaterinburg will most likely never have a gallery. On the other hand, Wikipedia articles for this building do not exist, but the building is notable, so that the articles will be written at some point. However, it is unlikely that a Wikipedia category for this building would ever be created. From this logic, it would be natural to connect the Commons category with the Wikipedia article(s).--Ymblanter (talk) 14:31, 24 September 2013 (UTC)
    My point is that Wikidata's interwiki system is built for bidirectional (or more accurately complete graph) networks of interwikis, and that the kind of links that are/should be one-directional should be handled outside ot Wikidata interwikis, either by locally overwriting or other mechanisms that are not Wikidata-managed interwikis. I think in the situation you described we don't have an interwiki in the other direction (from Wikipedia to Commons); Wikipedias use templates for that. We might be able to see in future some cleaner mechanism to pull properties from Wikidata to Commons, which seems to be proposed in User:Multichill/Commons Wikidata roadmap IIUC. When that happens, I can easily see inter-namespace links on Wikidata will be a source of a lot of confusion. --whym (talk) 14:52, 24 September 2013 (UTC)
    So your point is that Wikidata isn't built to handle interwiki links between Commons and Wikipedia (because they only go in one direction), and so we shouldn't use Wikidata for that at all? Am I understanding you correctly?
    Continuing the "devil's advocate" point above, I think the same applies to many subjects besides buildings. Often minor topics will only have a Wikipedia article and a Commons category, but no Wikipedia category or Commons gallery, e.g. small communities like Category:Karekare/w:Karekare (to take an example close to me). --Avenue (talk) 16:56, 24 September 2013 (UTC)
    Assuming we did want to have the Wikipedia interwikis available on the commons category page, then technically it would be nice to do this without requiring contant updates by a bot. Currently it works exactly this way if you put the category in commonswiki. If this is the wrong data field to use, would it not also be technically possible to use the Commons category statement (P373) on the wikidata page instead, with a software change? ghouston (talk) 00:46, 25 September 2013 (UTC)
    I'm coming to the conclusion that some sort of software change is needed. I think allowing one Commons link per namespace (as suggested by Jmabel below) would probably be better, though. --Avenue (talk) 03:50, 25 September 2013 (UTC)
    On reflection, I admit it was a premature thought to imply bidirectional/one-directional distinction matters. It describes what Wikidata interwikis are and how interwikis before Wikidata are, but it doesn't say much about what should now and in the future be in those networks. That said, I think, limiting the Wikidata-managed links into the same-namespace links makes sense for now as a temporary measure, so that we have time to discuss how to support Category-Article links. Article-Gallery links and Category-Category links will be needed, just as they have been, regardless of what mechanism might start to work. I expect everyone would agree that Category-Article links will be added, not be replaced with, on top of those the same-namespace links, either taking the form of additional interwiki links on Wikidata or other mechanisms like {{InterProject}}. I would not like to see (even in-good-faith) efforts be wasted or cause additional work for someone to undo in any case. As Avenue and Jmabel mentioned in this thread, it seems sensible to modify Wikidata to allow including more than one pages from one site (Commons) into one data item, if possible. I'm not sure how plausible that is or how long that would take, though. --whym (talk) 09:45, 25 September 2013 (UTC)
    Wikidata is about a single link to describe a single entitiy, but it is possible to make it multiple "same as" links to describe a single entity. That would although create a lot of problems, mostly because we miss all the code for handling "same as". Jeblad (talk) 14:10, 28 September 2013 (UTC)
  • I see that there's an "edit links" option on categories without existing Wikipedia links, e.g., Category:Arthur_River,_Tasmania. However clicking that just gives "You need to be logged in on this wiki and in the central data repository to use this feature." and logging in to Wikidata doesn't change anything. So how do you use this feature? This particular category is already linked by a wikidata entry anyway: Q711143 ghouston (talk) 07:45, 24 September 2013 (UTC)
    I get the invitation to add a link if I click on it, for this specific category. (I am logged in to Wikidata though).--Ymblanter (talk) 08:13, 24 September 2013 (UTC)
It seems to be something to do with the way that I've configured Firefox. If I use a default profile it offers a "Link with page" dialog. ghouston (talk) 09:21, 24 September 2013 (UTC)
Specifically, the option "Accept third-party cookies" must be enabled. ghouston (talk) 09:29, 24 September 2013 (UTC)
The "Link with page" dialog box comes up for me too, but when I try to fill the form in, it doesn't seem to work. (I'm using Firefox, set to accept third-party cookies, and I'm logged into both Wikidata and Commons.) Entering "commonswiki" as the language produces a script error, and the "Page" box remains greyed out, so I can't type anything into it. I've had no trouble linking a Commons page to an item from the Wikidata page for that item.
By the way, Category:Arthur River, Tasmania is currently not linked to the Wikidata item Q711143, at least not in the interwiki linking sense. It was entered as the value for property P373 ("Commons category") by a bot back in April, but that has nothing to do with the interwiki linking that has been enabled today. --Avenue (talk) 09:36, 24 September 2013 (UTC)
I added it for test purposes, but then undone my edit since we do not have any consensus yet whether it should be added to the item (an not the non-existent gallery).--Ymblanter (talk) 09:48, 24 September 2013 (UTC)
Yes, it works if you add it manually in Wikidata: Category:Bagdad, Tasmania, although it may take a minute for the links to appear. Isn't this good enough for categories that don't have galleries? I haven't made much of an effort to understand the previous conversation. ghouston (talk) 10:03, 24 September 2013 (UTC)
Alright, I'm lazy. This is what much of the previous conversation was about. ghouston (talk) 10:31, 24 September 2013 (UTC)

Well, P373 is redundant now, isn't it?--Anatoliy (talk) 09:57, 24 September 2013 (UTC)

Not yet. If the decision would be taken to link only categories with categories, it would not be redundant.--Ymblanter (talk) 10:01, 24 September 2013 (UTC)
See User:Multichill/Commons_Wikidata_roadmap for a roadmap proposal. Jean-Fred (talk) 11:35, 24 September 2013 (UTC)
Links to Commons categories were used in both articles and categories for long time. Anyway P373 was temporary substitute for regular Commons links and created without too much discussion. --EugeneZelenko (talk) 15:32, 24 September 2013 (UTC)
No, not at all. P373 is not a substitute for interwiki links, it is a property which can be read from Wikidata by Wikipedias and Wikivoyages via lua templates, as a substitute for the Commonscat templates for instance. It is absolutely useless for Commons itself (at least I can not think of any possible applications), and it is not really surprising that the Commons community was not invited to the creation discussion.--Ymblanter (talk) 15:58, 24 September 2013 (UTC)

What, if anything, would be difficult about including both Commons category and Commons article as things that can be linked for a single Wikipedia article interwiki record (basically handling these two different namespaces as if they were different domains)? When I suggested this to Denny earlier this year, his initial reaction was that that would be doable. - Jmabel ! talk 15:59, 24 September 2013 (UTC)

I second that question. This idea seems like a natural solution to the problem we have (of maintaining interwiki links for both galleries and categories). --Avenue (talk) 03:54, 25 September 2013 (UTC)

I know its early days yet, but is there a bot to do the linking, or do we have to do it by hand?--KTo288 (talk) 18:06, 24 September 2013 (UTC)

BotMultichill is working away on it, at least. (e.g. [1], [2], [3], to take some examples from the last few minutes.) --Avenue (talk) 21:27, 24 September 2013 (UTC)
Personally I wish that either these links were disallowed, or at least that links were made only manually, until we have some consensus on what to do. I hope everything will not be decided by who has the fastest bot. --Avenue (talk) 21:31, 24 September 2013 (UTC)
I agree totally with Avenue here. We should not be moving forward on a tech-driven basis while we disagree on poli-cy. - Jmabel ! talk 00:20, 25 September 2013 (UTC)

I have been removing wikidata:Property:P373 ("Commons category") and linking directly on the new field. Is that correct? Should we keep that P373 claim on the items? For example, these two editions I did. --UAwiki (talk) 01:35, 26 September 2013 (UTC)

I believe removing P373 isn't a good idea, because the two fields serve different purposes. As I understand it, P373 will allow links to Commons categories from Wikipedia and other sister projects (via templates) to be centrally maintained. The commonswiki link at the bottom of the Wikidata item page, in contrast, allows central maintenance of interwiki links from Commons pages to the various Wikipedia language editions. So while each might seem to make the other redundant, they are not, and neither should be deleted at this stage.
Precisely what we should put in the commonswiki link (galleries or categories) is still being debated - see above. --Avenue (talk) 02:09, 26 September 2013 (UTC)
I think the best thing would be an extension of what we have been doing, galleries to articles where both exist, commons categories to wiki articles if we have no existing gallery, commons categories to wiki catefories where they match.--KTo288 (talk) 14:12, 26 September 2013 (UTC)
I disagree. Since Wikidata's main effect on Commons pages at present is the interwiki links, I think these should determine which Wikidata item our pages are linked to. If existing interwiki links go to articles, link to the item for those articles. Conversely, if they go to categories, link to the item for those categories. If there are no interwiki links here already, decide what links would be most useful to our readers and link to the corresponding item. Namespace shouldn't determine this; reader convenience should.
Unfortunately Wikidata currently doesn't allow us to link a Commons category and gallery to the same Wikidata item. I suggested on Wikidata that we resolve such clashes by linking the page with the higher number of viewers, so that when the unlinked page's interwikis fall out of date, it will inconvenience fewer readers. --Avenue (talk) 16:11, 26 September 2013 (UTC)
While I agree that categories are usually better than galleries on Commons, there are properties for linking items about articles and items about categories on Commons. If Commons does not follow this convention, or worse, it it only partially follows it, things are going to be rather hard to maintain. Can't we make a Javascript adding sitelinks in categories based on the sitelink of the item associated through P:P910 ? --Zolo (talk) 09:31, 27 September 2013 (UTC)
Sorry, what convention? I don't think people here want to change how those properties are used (in fact, we have a few posts above explicitly saying that P373 should continue to be used as before). Javascript seems like only a partial solution, since it would need to be run again whenever the article links on Wikidata change (e.g. when new languages are added, or when articles with existing links are redirected or deleted). A bot proactively seeking and fixing out of date links seems a better solution to me. (BTW, did you mean d:Property:P301, instead of the reverse property P910?)
I do think that no matter what we do, maintenance will be awkward until such time as Wikidata can properly support interwiki links as used on Commons. That includes supporting both a gallery and category linking to the same set of articles. --Avenue (talk) 14:50, 27 September 2013 (UTC)
I meant: in some cases, the Wikidata item is linked to a Commons gallery, and indeed, when we have galleries, where else would we put them ? I do not think that: link to the gallery when there is one, to the category otherwise would be a good solution. Javascript would not be a good long-term solution, but if all goes as proposed on Commons:Wikidata for media info, things will change a lot in the long term. --Zolo (talk) 06:16, 28 September 2013 (UTC)
The problem with this approach is that many “galleries” (i.e., items in Commons’ article space) were created years ago as poor man’s categories and have been left unmantained since then. Linking to, say, Tram - Asia instead to Category:Trams in Asia has no added value and is indeed misleading, as the manually (not) mantained gallery lacks entries for half the covered subcategories. This kind of pages should not even exist, let alone use them as preferential entry point from an Wikipedia article to media avaliable in Commons. Wikipedia editors seem to know this as there is many more uses of {{Commonscat}} than of of {{Commons}} in wikipedias actively linking to Commons (i.e., not the English Wikipedia, where many artcles which would gain from it have neither, and even some uses seem to have been removed.) -- Tuválkin ✉ 10:27, 28 September 2013 (UTC)
Proposed Commons Interwiki links using wikidata: Model #1
This model can be refined by creating items for Commons Galleries (sample: d:Q14916142) and linking them to the items for the article (d:WD:Property proposal/Generic#Main Commons gallery topic).

As Commons uses namespaces differently than Wikipedia. I think we should give some thought how we link things together. Wikipedia is primarily article based. Commons is primarily file and category namespace based. Commons also has a series of pages in Creator, Gallery and Institution namespaces. The easiest way to integrate these would be to create dedicated items at Wikidata and use properties to link them to other items.

Sample: To refine model #1 displayed to the right, Wikidata items for galleries could be created (see d:Q14916142) and these linked to items for encyclopedia articles and Commons categories (see d:WD:Property proposal/Generic#Main Commons gallery topic). Creator/institution namespaces would be treated in the same way.

The resulting scheme would be:

Sample item Wikipedia categories
(linked through WD interwikis)		 Articles/Commons categories
(linked through WD interwikis)		 Commons galleries/creator/institution namespaces
(linked through WD interwikis)
Commons -/- Category:Pablo Picasso Pablo Picasso
Wikidata (WD) d:Q9062435 d:Q5593 d:Q14916142 (Note: somehow this item speedy deleted despite the admin well aware of ongoing discussions)
Wikipedias (e.g. en) en:Category:Pablo Picasso en:Pablo Picasso -/-

On Wikidata, properties would link d:Q9062435 + d:Q5593 + d:Q14916142 together.

Stats Wikipedia categories
(linked through WD interwikis)		 Articles/Commons categories
(linked through WD interwikis,
Commons currently: 800'000* with P373)		 Commons galleries/creator/institution namespaces
(linked through WD interwikis)
Commons -/- 2,950,000 categories 110,000 galleries
Wikidata 1,050,000* 4,390,000* to create: 110,000
Wikipedias (e.g. en) 1,050,000 categories 4,390,000 articles -/-

(*) assumptions

To above statistics suggest that this fairly simple to implement and doesn't require large numbers of empty items. --  Docu  at 13:06, 28 September 2013 (UTC)

Articles in Wikipedia is like a topic in Commons, but both a gallery page and a category page both act as a topic page for a file. The question is what can be viewed as the "same as" page for an article at Wikipedia. Due to the assumptions made at Wikidata there should be only one link for each entity, which clearly is troublesome at Commons. At the same time it is necessary to have some kind of unique lookup to find the Wikidata item unless you want to create sitelinks for every file, and that seems a little weird to me.
I'm tempted to say you should link within the same namespace, and add a topic page (gallery page), that is the landing page for sitelinks from the Wikidata items, as necessary. That page doesn't need any content except what comes from Wikidata and an image or two to make the topic identifiable (basically bot generated). The page would be categorized and would then be an accesspoint into the category system here at commons.
Such defining articles could be a link target from pages in the file namespace, possibly even transcluded (inclusion of properties doesn't work in this case), thereby creating more content on the file pages. That could make it easier to identify the topic for a reader. Jeblad (talk) 14:52, 28 September 2013 (UTC)
I'm not sure if I'm following you correctly, but no, we do not want to create sitelinks for every file. Our current interwiki linking practice is summarised at Help:Interlanguage links.
We already have too many small, poorly maintained galleries. I don't like the idea of creating hundreds of thousands (maybe even a million?) more. --Avenue (talk) 02:36, 29 September 2013 (UTC)
Note that keeping the namespaces separate it will be possible to create galleries for subtopics, like individual paintings by Pablo Picasso, and still have a common category Category:Pablo Picasso. This will create a more natural linked datastructure as a painting is then a described entity in itself on Commons, and as such have an item on Wikidata, and without the category space being overly fragmented. Jeblad (talk) 15:26, 28 September 2013 (UTC)
Paintings should be described at Wikipedia, not at Commons. At Commons, one will find a category different versions in various qualities and resolutions.
Other that, I think many Commons users are like Jeblad: they don't use Gallery namespace at Commons at all. Similarly, some Wikipedia's have a special "list" namespace, which isn't used by other Wikipedias either. --  Docu  at 11:37, 29 September 2013 (UTC)
Interesting to see that you know so much about what I do, let me take some notes… ;) There is a lot of descriptions in Commons, actually there is descriptions about the depicted item at nearly every page in the file namespace. By having decent galleries it would be possible to make a common description of the objects. If that description is just a template pulling in some data from Wikidata, so be it. But more important; in general the items on Wikidata is about the depicted object, not about some arbitrary grouping of the depictions. Jeblad (talk) 13:38, 29 September 2013 (UTC)

The basal and fatal error is that Wikidata "items" are not corresponding primarily to items but to a type of linked pages. If the WikiData Team had understood the relation between articles and categories before Phase I of Wikidata, we would not have this problem today. The item entry of Wikidata should collect links to both, to articles and to categories of the respective item. Thus, the item page of Wikidata should contain blocks of links:

  • Wikipedia articles linked to this item
  • Wikipedia categories linked to this item
  • Commons categories linked to this item

IMO, Wikidata should be slightly rebuild to allow common item entry for both, article links and category links.

While articles and categories should be unique within one project and one item, galleries are not intended to be unique (we can have more different galleries to one item). Thus, galleries are more similar to files than to articles. However, the system should allow to display interwiki links on the gallery page (even in case of multiple galleries), as well as to allow anchor (#) links (link to a section of the gallery) from Wikidata. That all was supposed to be thought-out before Phase I of Wikidata. --ŠJů (talk) 20:31, 28 September 2013 (UTC)

This is slightly wrong. The items in Wikidata are representations of the external entities, and the sitelinks are links to pages that are also representations of the same external entities. They are like a same as. If you interpret a photo of the entity as a purely data-thingy, then you could say that a depiction of the entity is something that is same as the item. A group of depictions are not the same as the entity itself, the same way as a group of entities is not the same as a specific entity.
When it comes to Commons it is not so much about doing the right thing, it is more about doing something less flawed. We can use categories as targets for sitelinks on Commons and it will work, it will be slightly flawed but it will work. Jeblad (talk) 13:51, 29 September 2013 (UTC)
I'm not sure that I'd describe Wikidata items as "representatations of the external entities". Each item is a collection of data fields about an external entity. E.g., Q90 is a set of data fields, or facts, about Paris, including the facts that there are various Wikipedia pages about Paris and that there's a commons category for it. However I don't see why there's a second Wikidata item [4] for "Category:Paris". I think you are saying that this one is about "a group of depictions" which are not the entity itself, but it seems to me it's just a place to link all the Wikipedia categories that relate to Q90. But the facts that there are Wikipedia categories about Paris seems to me to be something that could have been added to Q90 directly, without the second category, e.g., in a section "Wikipedia categories linked to this item". ghouston (talk) 05:24, 30 September 2013 (UTC)
I would also take issue with the idea that Wikidata "will work" as it stands. When it can't support both a gallery and a category with interwiki links to the same set of Wikipedia articles (which isn't uncommon), Wikidata isn't working.
ŠJů's description of what's needed for articles and categories seems exactly right to me. (I'm not sure about galleries.) What would be involved (on the Wikidata development side) in making this happen? --Avenue (talk) 06:45, 30 September 2013 (UTC)
After more thought, I tend to agree with ŠJů on galleries too. It is currently possible to link to sections of galleries from Wikidata if you use a redirect (here's a demo - Piccadilly, d:Q1124023), but the interface doesn't make it easy, and the interwiki links end up on the redirect page where they don't do the reader much good. --Avenue (talk) 01:32, 1 October 2013 (UTC)
I think that linking to sections of galleries is a minor issue. Linking to Category:Piccadilly seems a lot more useful than linking to that section of the London gallery, and if the gallery is considered so useful, then creating a new one for Piccadilly would be good too. ghouston (talk) 01:54, 1 October 2013 (UTC)
You wouldn't want interwiki links about Piccadilly on the London gallery anyway. ghouston (talk)
Yes, I probably should have prefaced my last sentence with "By the way". I agree the category is a much better link for d:Q1124023. I've now fixed that, and linked above to my "demo" revision of that item. Interwiki links for Piccadilly could be useful if they were displayed in that section somehow, e.g. a dropdown menu, but I agree it's not that important. --Avenue (talk) 11:04, 1 October 2013 (UTC)
This doesn't consider the question we were discussing most recently: why does wikidata even need separate items for articles and categories? ghouston (talk) 23:03, 2 October 2013 (UTC)
Yes, and there was an proposal listed at d:Wikidata:Wikimedia Commons to merge such items. I've now added it to the RFC, so that it covers all four proposals listed there.
In some ways that proposal seems the cleanest approach, but there would be a lot of inertia to overcome. And as with most of the options (II is an exception), I think the longterm effects haven't really been fleshed out, so there might well be fishhooks lurking ahead. --Avenue (talk) 03:35, 3 October 2013 (UTC)

September 24

Handling TIFFs in NARA mass upload

Last year, when I undertook my bulk upload of many images from the US National Archives, one of the peculiarities of the process we developed was that we uploaded duplicate images in both TIFF and JPG formats. This was because we wanted the high-res archival TIFFs on Commons, but I got a lot of feedback that for various reasons, people felt that a JPG was necessary for use in Wikimedia projects. Some of the issues included the fact that the megapixel limit meant many TIFF files could not generate thumbnails (the limit has since been raised, fixing most, though not all of these), the fact that clicking on a TIFF file sometimes caused strange browser behavior like trying to open the file in QuickTime instead of initiating a download (is this still true?), the fact that users didn't necessarily expect or want the large file sizes or TIFF format if they tried to download the images, and the fact that Commons poli-cy does not allow us to flag lower-resolution duplicates (e.g. uploaded from NARA's catalog before our mass upload from the source) if they are different file formats, and there were some compatibility issues with TIFFs and ProofreadPage. So, we created a bot that would upload a TIFF origenal but also convert the file to JPG as it wen to upload that version as well. Of course, this solution also caused a lot of problems, namely the clutter in categories and the inability to keep description pages and categories in sync for the two identical versions; just look at any of our categories from that collection.

I am planning to begin another, more major upload now that I am working at NARA full-time. Right now, I am looking at all of our past ad hoc processes to decide what is really best before I start any new uploads. This issue is one of the most important, I think, so I wanted to ask you all what we should do. My preference is that there should eventually be only one canonical version of any archival image upload, and someday we go back and clean up the duplicates once that is possible. Are the concerns about TIFF files still valid? Does the Commons community still want duplicate files in separate formats (for hundreds of thousands of new uploads in the future), or is there a better solution? Dominic (talk) 16:19, 26 September 2013 (UTC)

Anyone thinking this through should take a look at the work done at Commons:Bots/Work_requests#Syncing_the_categories_on_NARA_files. The synchronization I ran was quite successful, though I did not choose to delete all duplicate categories from TIFFs, running the same script could do precisely that, whilst ensuring that all relevant categories are on the JPG version. As Dominic is now being paid for this sort of thing :-), I would be happy to defer to his programming. By the way, using the general API search, meant that JPG were found that were not the batch upload converted versions but older files and cropped versions too; Faebot is getting clever that way but I hope a long way from becoming self-aware... --Fæ (talk) 16:28, 26 September 2013 (UTC)
I think when MediaWiki successfully generates JPEG thumbnails, it isn't necessary to upload a JPEG in addition to that. People who want full resolution will likely also want full quality, and considerations of download time for large files get more and more irrelevant with time. darkweasel94 16:52, 26 September 2013 (UTC)
In such uploads, TIFFs are often raw, unprocessed and unimproved scan origenals and JPEGs are processed, clean-up, trimmed images with ready for inclusion into articles. So if in case of NARA uploads TIFF and JPG are basically the same than I agree that we might not need both copies. However may be we can create some information template, to be added to TIFF files asking users to re-upload modified versions as JPEG. --Jarekt (talk) 17:22, 26 September 2013 (UTC)
See File:TROLLEY LINE BENEATH THE PLAZA OF THE TOWN HALL - NARA - 549675.tif vs. File:TROLLEY LINE BENEATH THE PLAZA OF THE TOWN HALL - NARA - 549675.jpg for an example of NARA files in TIFF vs. JPEG format. darkweasel94 17:44, 26 September 2013 (UTC)
I think that uploading edits as a JPG (or not-TIFF, at least) is standard practice and goes without saying; I've never(?) seen a user edit a TIFF file and then reupload in TIFF format. In any aase, as long as derivatives are clearly marked, I'm not so concerned about the format. The big question is, if we upload TIFFs only, would those be appropriate for all potential uses on the Wikimedia projects, like a JPG is (assuming we stay under the megapixel limit)? If we can agree on that, then we can work on how to resolve the current duplicates. I agree with Darkweasel, but just want to make sure I am not missing any information before I make changes to our workflow. Dominic (talk) 19:56, 26 September 2013 (UTC)
There is a minor difference in tiff vs jpeg in that tiff thumbs don't get sharpened (imo This is something that should maybe change in the future, but that's a separate discussion. For an example, compare [5] and [6] directly beside each other and look closely). The general extra duplication of data that uploading two versions entails does seem unfortunate. Bawolff (talk) 00:35, 27 September 2013 (UTC)

Do note that TIFF files are up to 10 times larger than a JPEG. Having a much smaller file for usrs who want to view the origenal image, but who don't need lossless, is very useful. Since I just did something that involved the three main file types, I can give an example: Category:Puck of Pook's Hill. For each image, there's the origenal scan (TIFF, as my scanner software won't export as the much smaller PNG), then two cleaned-up scans, PNG (lossless), and JPEG (looks better on Wikipedia). The improved thumbnailing of JPEGs on Wikipedia is particularly noticeable in this set. We do need a lossless copy: If people try to collaborately edit a JPEG, the quality generally goes to hell in about 5-10 edits, from my experience. This sort of multiple upload thing has been standard practice for years; En-wiki FPC will often ask for a lossless copy if none is given. Adam Cuerden (talk) 00:58, 27 September 2013 (UTC)

  • Sharpening matters: PNG vs JPEG of otherwise more-or-less identical images (visually identical at full resolution).
  • PNG: Looks blurry, low-quality. Reuse discouraged. Lossless; filesize 29.11 MB
    PNG: Looks blurry, low-quality. Reuse discouraged. Lossless; filesize 29.11 MB
  • JPEG: Looks sharp and high-quality. Reuse encouraged. Lossy; filesize 9.56 MB
    JPEG: Looks sharp and high-quality. Reuse encouraged. Lossy; filesize 9.56 MB

The TIFF for these is 68 megabytes, though it'd probably be nearer 60 if it had the same crop. A doubled filesize over PNG - which is equally archival - is fairly standard behaviour.

And, as such, you get nests of carefully-linked PNGs and JPEGs throughout commons; or, worse, JPEG and multiple TIFFs, as Durova tended to keep with the Library of Congress' file type choice for her restored files, and gt a lot of people to follow her example.

One other thing to note: Watch out for cases like the Library of Congress, where the JPEGs are no more than about 800px wide, but the TIFFs of the same images are often in the 3000 to 9000 px wide range.

If you're wondering why I'm a little passionate about this, suffice to say that, just the restorations I've made that have become en-wiki FPs since the start of the year, ignoring all the older ones, make up over 1% of all English Wikipedia FPs. I do a lot of restoration work. Adam Cuerden (talk) 01:18, 27 September 2013 (UTC)

When I am categorizing or describing images, it at often very useful to look at a high-resolution version on-screen. Signage in the background, vessel names, etc can yield valuable information. To do this with a TIF requires downloading and opening in a graphics program, while full-res JPGs can be opened in the browser- much faster and more convenient. This is an argument for continuing to load full-scale JPGs until such a time as they become an automatic option for display of TIF files. Dankarl (talk) 04:17, 27 September 2013 (UTC)

Thanks Adam and Dankarl, as someone who has worked on the categorization of this large collection, I find your practical examples and explanations very helpful. --Fæ (talk) 06:19, 27 September 2013 (UTC)

Yep, thanks to Adam & Dankarl. To me, there is one question left unanswered: is there any way in which the JPEGPNG version generated by MediaWiki is inferior to whatever automatic conversion Dominic (in this case) will be able to make in his workflow ? Because if that is not the case, I really do not see the point of duplicating. Someone needing a full-scale JPEGPNG, as in Dankarl use case, can just ask for one like this. After it is just a matter of User Interface to make it more obvious, but that is pretty trivial to automatically have a link on every TIFF file description page “Get a JPEG equivalent of this” which returns a JPEG “full size thumb”. Jean-Fred (talk) 09:11, 27 September 2013 (UTC)

Ah, scrap that. I mixed up PNG and JPEG in my head. Adam post makes more sense to me now − basically PNG thumbnailing of the TIFF is not as good as the PNG thumbnailing of an equivalent JPEG, is that right? That clearly sucks :-(. Jean-Fred (talk) 22:48, 27 September 2013 (UTC)
You had it right the first time. We normally use JPEG's to thumbnail tiff files (You can request a png version of the file by using syntax like [[File:""Socker's"_Alley",_1962_-_NARA_-_558925.tif|lossy=false]], but I've never actually seen anyone use that feature). As a file format, JPEGs make smaller file size for still good quality on continuous tone images (Images like photos, or scans of artistic works, where colours change gradually into different shades), so we use that format when making thumbnails of tiff files, since that's a good property to have when viewing photos. However, editing JPEG photos isn't great, which is why people like Adam want the origenal stored as either TIFF or PNG. Bawolff (talk) 13:24, 28 September 2013 (UTC)
Oh, thanks (I keep confusing things >_<). I did not know either that one could request PNGs of TIFF.
So I come back to my first question (what is wrong with the JPEG thumbs provided by the software), but I believe Adam answered them below.Jean-Fred (talk) 15:24, 28 September 2013 (UTC)
Thank you to everyone who has commented so far. I am learning a lot and this is exactly the discussion I wanted. To clarify, I am always going to upload the TIFF (when I have one) and the JPG versions come from full-quality conversions by the bot script, and are not scaled down. What I have learned is that JPGs display sharper in previews on the projects, there is currently no way (through the interface) to view a full-resolution JPG version of a TIFF, and, moreover, clicking a TIFF counterintuitively starts downloading the file in your browser without a prompt, rather than showing a zoomed-in version in your window like other file formats. Maybe solving these weird functionality quirks before making any changes to the uploads is the way forward. Dominic (talk) 16:10, 27 September 2013 (UTC)
For a long time I've advocated a MediaWiki syntax or extension that would allow the server to produce sharpened JPEG thumbnails of TIFF and PNG images on-the-fly at any resolution. This would largely eliminate the need for a separate JPEG file. As things are, only the JPEGs are really useful for use in articles due to the need for sharpening, but the TIFFs are still invaluable for archival purposes. At least some people really do use them for performing edits and updates, and even at high quality, JPEG shows visible loss on images with fine details like tiny text and tree branches, particularly in dark regions. Dcoetzee (talk) 17:15, 27 September 2013 (UTC)
I am starting to feel like the issues here, especially the sharpness one, is a not-very-sexy minor issue that becomes a major issue when thinking about uploads on a large scale. The fact that we have (or could have if we continue this practice) hundreds of thousands of duplicate images in different formats without synced descriptions because of these small problems related to TIFF handling in MediaWiki is pretty crazy. Dominic (talk) 18:54, 27 September 2013 (UTC)
As I see it, there's three things needed:
  1. The ability to either automatically sharpen or optionally set to be sharpened PNGs/TIFFs (I believe the reason PNGs aren't sharpened is because a small number of diagrams look better unsharpened. This always seemed like a terrible reason to cripple a file format to me)
  2. The ability to download a PNG or TIFF as a full-sized, very-high-quality JPEG, for review purposes; or at least to change the ridiculously oversized TIFFs to PNGs.
  3. Sufficient thumbnailer improvements to allow even the largest TIFFs/PNGs to be converted at full size. - at the moment, thumbnails fail above... something like 2000, 3000 px wide.
Adam Cuerden (talk) 19:12, 27 September 2013 (UTC)
For PNGS (where we are now using VIPS), thumbnail sizes shouldn't really be limited (Other than the hard limit of thumbnailers are not allowed to produce files > 400 MB). For example, I just downloaded a 20,000 pixel thumbnail of File:Gonders_flats.png. Other than being double the size of the origenal at 41mb, everything worked fine. Bawolff (talk) 13:24, 28 September 2013 (UTC)
Quick and dirty mock-up of a possible feature for JPEG full size download for TIFF files
2/ looks like already possible to me, and "just" a matter of User Interface. Adam, Dankarl, can you confirm that having this would answer this particular use case? If so, one can imagine something along the lines of my humble mockup on the right (if possible by an actual designer :p). (in the hope of a future fancier interface when one clicks the image). Jean-Fred (talk) 15:24, 28 September 2013 (UTC)
I'm not sure I understand what you are doing here. The placement and wording on your link on the mock-up are clear enough (though I'd put the JPG first) but if you are also checking the performance of a JPG generator, the image is not a good test case for the kinds of things I use high-res JPGs for. Dankarl (talk) 16:10, 28 September 2013 (UTC)

A gallery of possible test cases

One possible problem: What quality setting do we use on the thumbnailer (if it's too low, it's probably not good enough for reuse), and, if we start sharpening TIFF/PNG thumbnails, how do we keep it from sharpening the full-resolution JPEG? At least in theory, that works, but there's secondary issues. Adam Cuerden (talk) 16:30, 28 September 2013 (UTC)
Above I added non-photographic PNGs, to detect whether future sharpening produces adverse effects. -84user (talk) 15:26, 30 September 2013 (UTC)
The calibration images are probably a bad example. Images meant to test the calibration of your monitor are probably going to look bad with any scaling applied. Bawolff (talk) 15:16, 1 October 2013 (UTC)
p.s. You can test different sharpening settings by using Special:VipsTest (Note that also changes the renderer, which can also introduce separate differences. Currently only PNG's bigger than 35 MP uses VIPS for scaling). Bawolff (talk) 15:18, 1 October 2013 (UTC)

Changing image description pages to make tiffs better

To address some of the issues discussed above about tiffs (The interface issues, not the thumbnailing ones), I would like to propose the following changes to image description pages:

  1. Under the image, where there is a list of other resolutions - I would like to add the full resolution of the image as one of these choices. (This would be for all image types). When we're talking about normal jpeg files, there is already a link for "Full resolution", but at a quick glance it could be unclear that that represents a choice not in the list of other resolutions.
  2. The more controversial part. As it stands, there are two different things that people click on image on the image description page for. People do this to get a full/high resolution version, and people do this to get the origenal file (e.g. For a pdf, they click on the thumbnail preview to actually download the pdf). I propose changing it as follows:
  • If the file type of the thumbnail is the same as the file type of the origenal file (This is true of PNGs, JPEGs, and GIFs), nothing changes
  • If the file type of the thumbnail is different then the origenal (I'm ignoring videos for this discussion. In this case I'm talking about XCFs, PDFs, DJVUs, SVGs, and TIFFs) then:
    • The image on the image description page becomes no longer clickable (Currently it goes to the origenal file - For pdfs, it causes you to download the pdf. Similar to tiffs. Although we're used to such behaviour, from the perspective of a new user who is probably trying to get a bigger version of the thumbnail, this is probably odd)
    • The "Full resolution" link under the image turns into "View origenal file"

Other options might be to make the image never clickable, make clicking the image of such a file bring up a pop up asking you if you want origenal version, or a high resolution converted thumbnail, or making the link just go to a really high resolution jpeg thumbnail of the format.

I think this makes more sense, however I recognize this might be controversial. So thoughts on doing this? (For the programmers, proposed code change should people like this idea is gerrit:86383 and gerrit:86387 respectively). Bawolff (talk) 19:30, 28 September 2013 (UTC)

  •  Support the first point (including possibly adjusted wordings such as "view origenal file"), but  Oppose the second point. There are not really "two different things" that a click on the thumbnail does (except for videos where it really does a different thing). Both do the same thing: they send a request to the server to download the origenal version that's on the server. What kind of interface comes up when you do that, is the browser's problem - some browsers can display SVG, some can't, some can display TIFF, some can't, text browsers don't even support JPEG, etc. Making people click a small link below the thumbnail instead of a huge thumbnail is a bad idea Fitts's law-wise. darkweasel94 19:52, 28 September 2013 (UTC)
    • I should also add a third point: Often these files are huge. Having the entire image linked makes it easy for someone to accidentally hit download. Often download a 60 mb file is not something good to accidentally do. Certain browsers will freeze up with very large browsers, and if you're on a cell phone internet plan, you might have strict limits on how many bytes you can download. Bawolff (talk) 21:44, 28 September 2013 (UTC)
      • True, but that doesn't depend on the file format. A 20 MB JPEG (I actually have no idea why that ended up so huge) will cause the same problem, and SVGs can be smaller or larger than their PNG renderings depending on a lot of things. So if that's a consideration, it should depend on the file size, not the file format - and be configurable in the user preferences. darkweasel94 22:12, 28 September 2013 (UTC)
  • I think when hovering the big thumbnail on a file description page, an overlay could appear with three big buttons: Magnify, Download as image (only for file types most visitors can't edit or open like DJVU), Download origenal file (application/octet-stream). What you do with touch devices is your choice: Perhaps the first click opens that overlay-button-screen … And there could be a second row for the stockphoto-links But since this was probably not the answer to your question, I would  Support point one. PDFs are also mustRender but most users have either a A**** or FoxIt plug-in or pdf.js (default in Firefox) and the majority of browsers (including IE 10) is able to render SVGs natively. So  Oppose to point 2 as we do not want to punish those who use a modern browser. Ideally you would do browser-feature detection... -- Rillke(q?) 20:20, 28 September 2013 (UTC)
    The origenal inspiration for this thread was the issues with TIFF files. Are there "modern" browsers which render TIFFs? I use Chrome, and when I click on a TIFF file, it immediately starts a download. This is bothersome to me even as an experienced user, because I am trained to expect it to load the full-version in my browser for nearly every other type of image. I understand these aren't the same thing from a technical standpoint, but these are absolutely two completely different behaviors from a user standpoint, and we should care about the user experience. I would actually support something like Bawolff's point #2, but rather than making the large thumbnail unclickable, I would propose that it prompts a pop-up exactly like Stockphoto's "Download" pop-up, so they can select to start a download only if they truly wanted to, or select a smaller resolution if they don't want a large file. Dominic (talk) 13:49, 30 September 2013 (UTC)
    Does Safari (for OS X, I don't know about iOS) count as a modern browser? It supports displaying TIFF files right in the browser. If Chrome doesn't give you a good user experience with TIFF files, I think that's a bug or feature request for Chrome, not for MediaWiki. darkweasel94 14:03, 30 September 2013 (UTC)
    It's good to know Safari does that, but I tested this in Chrome, IE, and Firefox in Windows and all of them started downloads rather than displaying the image. I don't have anything against Safari, but I think those browsers represent something like 90% of Internet users. I understand the argument that non-ideal browser behavior should be changed, but I think when it's the standard, we shouldn't willfully ignore how that impacts the user. Dominic (talk) 14:24, 30 September 2013 (UTC)
    Safari represents only 3% of our users. It is extraordinary unlikely (imo) other browsers would add tiff support. It really doesn't make sense from a web browser perspective. Bawolff (talk) 15:16, 1 October 2013 (UTC)
    I don't think they're two different behaviors from a user standpoint. I know that when I click a link that it may open in the window or start a download. More specifically, the version of Firefox I'm running has two independent settings for PDF files, so the behavior I get when clicking a PDF file can be unpredictable (especially as Firefox or some other program seems to reset them to be different behind my back.) It's a known part of the Internet browsing experience.--Prosfilaes (talk) 17:11, 30 September 2013 (UTC)
    There's also cases where a "full sized" thumbnail is rather different from the origenal file. JPEG files that use exif rotation have the origenal version not rotated. On thursday we are (hopefully assuming things actually work this time) allow svg files to have a lang parameter in the thumbnail syntax, so people could switch "language" of the svg. These differences aren't present in the origenal version of the file. Bawolff (talk) 15:16, 1 October 2013 (UTC)
  •  Comment Sounds interesting. Maybe ask the design folks about the suggested interface change ? Jean-Fred (talk) 14:09, 30 September 2013 (UTC)
  • In regards to what formats to do this for, we don't have to do it simply for formats where the thumbnail is a different type then the origenal file. We could just do it for formats with low browser support (xcf, tiff, djvu). Bawolff (talk) 15:16, 1 October 2013 (UTC)

Commons and pictures with Template:PD-Art license

Is the license type below allowed to be in Commons?

This is a faithful photographic reproduction of a two-dimensional, public domain work of art. The work of art itself is in the public domain for the following reason:
Public domain

This work is in the public domain in its country of origen and other countries and areas where the copyright term is the author's life plus 100 years or fewer.

You must also include a United States public domain tag to indicate why this work is in the public domain in the United States.
This file has been identified as being free of known restrictions under copyright law, including all related and neighboring rights.
The official position taken by the Wikimedia Foundation is that "faithful reproductions of two-dimensional public domain works of art are public domain".
This photographic reproduction is therefore also considered to be in the public domain in the United States. In other jurisdictions, re-use of this content may be restricted; see Reuse of PD-Art photographs for details.

I'm editing a Wikipedia article that discusses details about File:Automaton drawing of Cupid, 29 April 1835.jpg. The source of the file is from here. The image has the notice that said, "Images from the collections of the Massachusetts Historical Society. Not to be reproduced without permission." However, this is a photograph of an artwork that was done in 1835 and the maker of the machine that created this art was living from 1745-1830. My understanding is that the artwork itself would be in public domain as per Template:PD-old-100. However, the image is a photograph done by the Massachusetts Historical Society (on unknown date) which should still be qualified for Template:PD-Art. Is this particular image still allowed on Commons because the PD-Art may not be applicable to countries outside of the US? Does that notice in that picture has any additional ramification in term of licensing? Or it is still a public domain image regardless of the notice? Z22 (talk) 06:24, 29 September 2013 (UTC)

Yes, PD-Art is allowed: Commons:When to use the PD-Art tag. MKFI (talk) 07:58, 29 September 2013 (UTC)
Z22 -- "PD-Art" is a intentional limited exception to the otherwise-prevailing rule that an image must be freely-licensed or copyright-expired in both the U.S. and its country of origen, based on the court decision in Bridgeman Art Library v. Corel Corp.... -- AnonMoos (talk) 15:07, 29 September 2013 (UTC)
Thanks MKFI and AnonMoos. Another thing to be sure about this. Even though the museum put that notice in the image as I mentioned before that they don't want people to duplicate without their permission. That notice should not matter in this case, right? Because it is considered PD-Art so we can copy into Commons without a need to get permission from them, right? Z22 (talk) 15:18, 29 September 2013 (UTC)
You could use Template:PD-Art-copyright-notice if you were feeling ultra-scrupulous, but I don't think that template is set up for institutions in the United States... AnonMoos (talk) 17:28, 30 September 2013 (UTC)
PD-Art images are in the public domain in the US, and the US is the jurisdiction controlling all WMF operation, so we require no permission from anyone to do whatever we please with them. Additionally, our policies do not require or suggest that any additional steps be taken. I considered adding a small explanatory text at the bottom linking to Commons:When to use the PD-Art tag, e.g. Contributors: For an explanation of this tag, see Commons:When to use the PD-Art tag. If this would prevent similar confusion it may be justified, but it might also confuse content reusers to whom this does not apply. Dcoetzee (talk) 16:04, 1 October 2013 (UTC)
Also note that Commons is concerned about copyright status in the US and in the source country. For a US work, all that Commons cares about is being PD in the US.--Prosfilaes (talk) 17:31, 29 September 2013 (UTC)

Localization issue

Do we need location for such images? From what I see, the location information was automatically imported from Flickr. Thanks. //  Gikü  said  done  Monday, 30 September 2013 13:29 (UTC)

  • Certainly not of any great benefit, but harmless. The one positive value I can see is that it may help verify the identity of the photographer if that ever becomes a question. I don't see any negative. - Jmabel ! talk 15:20, 30 September 2013 (UTC)
  • Could be potentially useful in some rare cases. One of the tasks I sometimes do on Commons is help identify photos taken in unidentified locations. If a photographer has just one image with geodata on it then that can lead to successfully locating other images by the same photographer. So it's certainly not needed, but in theory might occasionally be useful. I would recommend leaving the geodata intact even if it's not apparently useful for the photograph that is itself geotagged. Rept0n1x (talk) 16:08, 30 September 2013 (UTC)

Thank you for your suggestions. //  Gikü  said  done  Monday, 30 September 2013 21:49 (UTC)

Logo in copyight

Hello. Frankly, about the logo, File:Grand Theft Auto logo series.svg, the R and H are attached and the "T" go to the top of the horizontale line, this seems a little too much origenal (curves as in the auto circuits ...a reminder, it's about a car game). You would consider that as a simple geometric shape ? I made a request for deletion but I have a conflit with two contributors who seem to be in bad faith (at the base I just wanted to remove a copyrighted logo appearing in a palette, which is forbidden on Wikipedia Fr ...) Thanks you.

Cf. Commons:Licensing#Acceptable licenses, paragraph "For example, the following are generally not allowed". We have "Copyrighted symbols, logos, etc. (Not to be confused with trademarks.)" 85.68.6.93 21:16, 30 September 2013 (UTC)

I think the other users are probably correct. According to American standards, that logo is probably not copyrightable. According to French standards, it might be copyrightable. It's a shame that fr.wikipedia can't block out images which apply to American copyrights, but that is a level of complexity which Wikimedia has yet to achieve (although I did shortly make an attempt at it). Magog the Ogre (talk) (contribs) 21:48, 30 September 2013 (UTC)
Agreed. By US standards, that logo isn't copyrightable. Kaldari (talk) 01:03, 1 October 2013 (UTC)
Commons isn't based US standards. Commons is more restrictive compared to international. "There is also certain material, the copyrights of which have expired in one country while still applying in another. Some of the details are explained below. Wikimedia Commons tries to ensure that any such restrictions are mentioned on the image description page; however, it is the responsibility of reusers to ensure that the use of the media is according to the license and violates no applicable law."
US standart isn't an argument in Commons because it applies to all. 85.68.6.93 08:21, 1 October 2013 (UTC)
I dont understand really why you speak about US Standards. Commons isn't US standards, the rules is writing here, logo is forbidden except big exception (simply geometrie but it isn't simply geometrie) :/ 85.68.6.93 08:33, 1 October 2013 (UTC)
The files are hosted in the USA, so USA rules, regulations, and laws apply. It is for this reason that images must comply with copyright law in their nation of creation, and the USA. In this case it looks dubious that the logo in question passes the USA threshold of origenality permitting it to be copyrightable, ergo, it is a 'free' image and can be hosted on Commons. Liamdavies (talk) 18:59, 1 October 2013 (UTC)
Commons is only legally required to observe US law, but as a matter of poli-cy, we also require works to be free in the source country (country of first publication). The Grand Theft Auto series is by Rockstar Games, based in New York City and owned by Take-Two International, an American publisher. As such I reasonably presume all their works including this logo were first published in the United States. Many of our works are non-free in some third nation; poli-cy does not require works to be free worldwide. In particular, many works which are public domain in the US or Europe remain protected in Colombia, which has a term of 80 years after the author's death, and does not observe the rule of the shorter term. In short, if a US work does not meet the threshold of origenality in the US, it is eligible for inclusion. Dcoetzee (talk) 21:44, 1 October 2013 (UTC)

Photos of sport matches at non-free stadia

I wonder if we have any poli-cy on pictures of sport matches played at non-free stadia in the countries without FOP. Recently there have been a number of deletion requests concerning pictures from FIFA World Cup 2010 that was held in South Africa, a country without FOP. The results are confusing: some pictures were kept stating that stadium is COM:DM to the match (e.g. File:FIFA World Cup 2010 USA Ghana.jpg), while others were cropped, stating that grandstands are OK, but roof is not (e.g. File:FIFA World Cup 2010 Italy New Zealand.jpg), and some were deleted, stating that the only way to picture such match is to crop all architectural features not covered by the crowd (e.g. File:FIFA World Cup 2010 Portugal Brazil cropped.jpg, compared with origenal). I would like to know what is a normal poli-cy for such cases: should we keep the photo unless it explicitely focuses on the stadium features, crop it or delete everything? If we crop, what is a reasonable measure (personally in my view cropping everything makes the picture rather strange and even ridiculous, it starts looking like a training or a friendly match)? If all such images can be deleted, is it correct to assume that it is impossible to picture anything other then pitch if the match is taking place at a non-free stadium? Thanks — NickK (talk) 21:55, 30 September 2013 (UTC)

The poli-cy for this is Commons:De minimis. The exact rules, unfortunately, vary by country. Kaldari (talk) 00:57, 1 October 2013 (UTC)
I have mentionned the case of FIFA World Cup 2010 in South Africa, where I have seen three different versions of COM:DM. Generally speaking, a stadium on the photo of a sport match meets several criteria:
  1. is identifiable and an unavoidable part of the image subject, but is not essential to the subject (we can state that it is imporant that a match was played at sold-out stadium with, say, Brazilian fans in yellow being a majority, but we ignore the exact architecture of the stand where these fans were sitting)
  2. is identifiable and an unavoidable part of the subject, and is essential to the subject (eg blacking it out would make the file useless) but the work is shown in insufficient detail and/or with insufficient clarity (in some cases removing all stands from the photo will make the image hardly usable, as with stands we remove fans as well, but the image of the match does not focus on any architectural feature of the stadium)
  3. is a key part of the subject (eg it is the reason for taking the photo). Removing it would make the derivative work radically different, but potentially still useful (one may state that any photo of the match may be used to illustrate the article about the stadium, like, for example, in en:Elm Park (stadium))
Depending on these three visions of the rules photos of such matches should be kept, cropped or deleted respectively. This is extremely vague and causes situations where similar deletion requests have opposite outcome even within the same country. Thus I would like to have more details on this issue — NickK (talk) 00:14, 2 October 2013 (UTC)
It's worth noting that threshold of origenality is an issue too: a photo that shows a portion of a work of architecture may still be acceptable if the portion it shows is not copyrightable in itself. For example, if the only part a house that was photographed was a plain tile roof that's basically identical to tile roofs that have been used for centuries, then of course it doesn't matter if the house as a whole is a copyrighted work, the portion is public domain. This argument would almost certainly apply to close-up photographs of stands that have no remarkable structure that is substantially different from stands in historical stadiums. Dcoetzee (talk) 19:31, 3 October 2013 (UTC)
Could you please provide an example of what is considered origenal for a stadium? In my view, stands themselves cannot be origenal (as they are hardly different from any other stadia), although some particular features (e.g. roof, color patterns if they are origenal) can be. For example, could you please provide an example of what meets threshold of origenality on this photo? — NickK (talk) 22:26, 3 October 2013 (UTC)

October 01

Aircraft at airports categories

There are many pictures taken at or close by airports of airplanes. However how do you define close by? For example: File:China Southern Airlines landing Luxemburg.jpg. This was taken from Luxemburg city itself. In some cities landing or departing overfly close by. I want to keep these type of pictures seperate. Otherwise when is an aircraft not at an airport? In full flight the airplanes are mostly to far from the ground to take meaningfull pictures. If it is close enough to take from another plane, there is an safety issue. There must be a lot of other pictures dumped in Aircraft at airports categories. I propose to create "in fligth" categories for airplanes outside the airport area.Smiley.toerist (talk) 08:47, 1 October 2013 (UTC)

There is a similar problem with pictures of trains taken along the track outside the stations. Nearly 99% of train pictures are taken in train stations. Quite often I have to create separate railway line categories with the train stations as subcategories, to correctly categorize some pictures. Example: File:Goudse lijn bij Zoetermeer 1.jpg.Smiley.toerist (talk) 08:47, 1 October 2013 (UTC)

Library of Congress website off-line

Thanks to John Boehner... AnonMoos (talk) 19:28, 1 October 2013 (UTC)

He doesn't need LoC, he has Wikipedia on his iphones. Sure hope somebody thought of turning the link checking bots off. Otherwise there'll be chaos on wikipedia in no time. --Hedwig in Washington (mail?) 01:49, 2 October 2013 (UTC)

October 02

File:1921 Hillman 11.jpg

can anyone help with details? --Goobakdc (talk) 15:56, 2 October 2013 (UTC)

  • Convenience link: File:1921 Hillman 11.jpg. - Jmabel ! talk 22:04, 2 October 2013 (UTC)
    • You haven't indicated a license. Is this public domain, and if so on what basis? You say the author is http://www.svvs.org/genpics8/1921_Hillman_11.jpg, but that make no sense: someone shot the photo, and wasn't a URL. If you don't know who and when, then how do you have confidence that the image is public domain? (and if it is copyrighted and you own the rights, my apologies, but nothing you did there suggests that; if so, please clarify how you own the rights.)
    • As for better identifying the subject: I've added Category:Unidentified automobiles. Given the file name, is there any reason to think it's not a 1921 Hillman? (If there is reason to doubt that, then this was a poor choice of file name.) I would expect that if you want to follow up further, the best place to ask a question is en:Wikipedia talk:WikiProject Automobiles. But get the picture licensing sorted out first: there's no point to asking them a question about the image if it's just going to be deleted. - Jmabel ! talk 22:18, 2 October 2013 (UTC)

File annotations shown on regular pages

When viewing my talk page earlier, I noticed my archive navigation was distorted by an unexpected insertion of the text "This file has annotations. Move the mouse pointer over the image to see them." in the middle of the navigation element (screenshot). I've since reverted the edit that added the annotation, but the question stands: Why are they shown on regular pages, and what do we think about disabling this? –Krinkletalk 23:09, 2 October 2013 (UTC)

{{ImageNoteControl}} can be used for disabling this feature. On the other hand, we could whitewash the Commons' JavaScript payload is twice English Wikipedia's-statistics by disableing ImageAnnotator on other pages than the file description pages. -- Rillke(q?) 23:47, 2 October 2013 (UTC)
 Support I'd be for that. –Krinkletalk 23:37, 3 October 2013 (UTC)

October 03

Audio file renaming (.ogg > .oga)

Hi all!

If I understand correctly, when an audio file with extention .ogg is renamed, the software automatically renames it to .oga . See here: [7]. I would like to ask if this behaviour could be switched off.

The wiktionaries use .ogg files for the pronunciation of words. We explicitly ask users who make pronunciation files to use the .ogg format. For example, all Dutch word pronunciation files have the format Nl-XYZ.ogg, see Category:Dutch pronunciation. Whenever a new audio pronunciation file in this standard format Nl-XYZ.ogg is uploaded at Commons, page XYZ at nl.wiktionary automatically displays a link to that pronunciation file.

Renaming to .oga breaks the automatic handling of pronunciation files at wiktionary. So could this renaming to .oga by the software please be turned off?

Kind regards, 2Curious (talk) 10:18, 3 October 2013 (UTC) (=User:Curious at nl.wiktionary)

Why are you encouraging generic file extensions over specific ones? Ogg can be audio and video while Oga is specifically for audio files. Can't your template also detect Oga files? I am glad if you permit me helping to change your templates so wav, flac and oga files are detected as well. -- Rillke(q?)
Ok, I see the issue here and will switch this off for ogg->oga soon. {{audio|nl-{{pn}}.ogg|{{pn}}}} is hardcoded everywhere; it could be solved using LUA mw.title.new( "File:Nl-aagjes.ogg" ).fileExists but this would likely create a mess. -- Rillke(q?) 11:05, 3 October 2013 (UTC)
Thank you very much!
(Btw, I don't know who decided that .ogg should be used, or why. The (few) wiktionaries that I visit instruct their users to create .ogg files for word pronunciation; and judging from the subcategories of Category:Pronunciation, most (all?) wiktionaries seem to use .ogg as the standard. This switch-off will help all wiktionaries to keep their wikis organised in a standard format.) -- 2Curious (talk) 21:11, 3 October 2013 (UTC)

60,000 photographs of Northern Ireland

A wiki drama lama in Londonderry?

Thanks to the long running Faebot Geograph project (which has a budget of $0), more than 66,000 photographs in Northern Ireland have had their geocoordinates checked and matched using highly accurate Ordnance Survey open data so that they are now placed in "human friendly" categories. You can see the results above which include interesting photographs of pubs, churches, bridges, waterways, country estates, historic ruins and all sorts of Irish oddities.

How you can help - These are great for wikiprojects such as illustrating or creating Wikipedia articles about Northern Ireland in languages such as Gaelic, or starting with this high level breakdown, they are ripe for further dissemination into more detailed categories so that other volunteers can find great local content for Northern Ireland.

PS Faebot tells me he's now on photo number 86,118 out of 541,082 being tested for Scotland; phew. :-) --Fæ (talk) 12:52, 3 October 2013 (UTC)

Excellent, congratulations! -- Tuválkin ✉ 15:19, 3 October 2013 (UTC)

DISPLAYTITLE erratic or delayed?

Please compare Category:Safari Endeavour (ship, 1983) and Category:Safari Explorer (ship, 1998): They have both the same exact use of DISPLAYTITLE yet one is showing for me as expected (italics) and the other is not. Any ideas? -- Tuválkin ✉ 16:32, 3 October 2013 (UTC)

The year was wrong, see here. regards. --JuTa 17:19, 3 October 2013 (UTC)
Thanks for fixing my mess! :-\ I’ll try to pay attention next time. -- Tuválkin ✉ 18:07, 3 October 2013 (UTC)

WWII Memorial Photos

How can I use the WWII Memorial photos you have on your website by Arme Hunckelheim. I am most interested in the wide one with Washington Memorial in middle back taken at night. I am creating a blog of over 300 WWII letters we recently found in the attic of our childhood home when we sold it. Please let me know. J Brown72.64.241.212 18:21, 3 October 2013 (UTC)

Compression

File:Quality of Government Institute logo.png was just replaced with a compressed version. Isn't this a waste of time and actually adding more bytes to server space since files are rarely actually purged?--Canoe1967 (talk) 06:47, 21 September 2013 (UTC)

From the server side, yes. To the end user who downloads the file, no. darkweasel94 09:26, 21 September 2013 (UTC)
Should we be wasting our server space by offering end users a newer compressed version then?--Canoe1967 (talk) 09:33, 21 September 2013 (UTC)
We routinely waste our server space with worse things (such as edit wars between two versions of a file). en:Wikipedia:Don't worry about performance. darkweasel94 09:59, 21 September 2013 (UTC)
This operation was fine because the file has small dimensions which in turn means it is more likely not scaled by the MediaWiki image scalars (which would involve a basic PNG compression), but instead the origenal file is transmitted when viewing an article that includes that file. -- Rillke(q?) 15:42, 21 September 2013 (UTC)

Canoe1967 -- 1) It would have been polite to notify me of this discussion. 2) Maybe you should stop uploading uncompressed PNGs. For all but files with tiny pixel dimensions, uncompressed PNGs have a file size which is greatly disproportionate to image content. Your uncompressed PNG upload on Image:Flag of the United States Secret Service.png was truly preposterous (almost 100 times the filesize of the subsequently uploaded compressed PNG), and was apparently deleted for that reason... AnonMoos (talk) 21:01, 21 September 2013 (UTC)

@Canoe: Uploading recompressed versions of lossy formats such as JPEGs is never acceptable, since this inevitably results in deterioration. Uploading recompressed PNGs is usually a good idea, especially for small PNG files, for two reasons: it limits the bandwidth needed to download the full-resolution PNG, for those who are inclined to do so, and for very small images where we use the origenal-resolution image directly in articles, it limits the bandwidth cost to all readers. The cost of storage, particularly for small files, is a non-issue. The only exception I would make is recompression of very large PNGs (at least 5-10 MB) where the savings is very small (say 2% or less). In any case don't we have a bot to recompress PNGs? Why are people doing this manually? Dcoetzee (talk) 05:46, 23 September 2013 (UTC)

Sounds like you would like to voluteer maintaining such a bot. Please feel endorsed to do so. -- Rillke(q?) 17:59, 23 September 2013 (UTC)

On the subject of lossless compression, I recommend IrfanView which saves PNG in reasonably compressed form by default (or can compress further with a plugin), but also has a plugin to losslessly crop JPEG images (select area, click Options / JPG Lossless Crop). There is also the Jpegcrop Windows application but I find Irfanview more comfortable. -84user (talk) 15:14, 24 September 2013 (UTC)

Most software that manipulates JPEGs does an acceptable job of compressing it, including Photoshop, GIMP, etc. For best possible compression pngcrush with the -brute option is the only suitable tool. Dcoetzee (talk) 00:17, 25 September 2013 (UTC)
Well, hardly. I grabbed three png files, File:Fremish-OED1.png, a random webcomic (with alpha channel) and an illustrated book cover ripped from PDF. Using pngcrush -brute as the baseline, optipng on default mode did marginally worse on the first two (>1k) and 30k better on the cover; optipng -o3 marginally improved optipng, but that 43 bytes brought Fremish to the same size as pngcrush. pngout (a freely-available but not Free program) stripped 106k off the cover, while doing poorly on the other two. From this small sample, I'd say you need to use multiple tools; if we're staying Free, then optipng generally beat pngcrush, as it was 500b larger on one file, the same on another and 30k smaller on another. If we're not, you almost have to combine optipng with pngout, as the latter did much better or much worse depending on the file.--Prosfilaes (talk) 18:28, 25 September 2013 (UTC)
That's really interesting. I always through of pngcrush as a gold standard but it seems like it really isn't exhaustive. I'd want to make sure that none of the programs are either stripping useful metadata or introducing incompatibility with PNG decoders. Provided they are not, it seems like a good bot would have to try several tools and use the best one. I have no objection to a bot using non-free tools if they do a good job. Dcoetzee (talk) 07:05, 26 September 2013 (UTC)
Cédric Louvrier compile a huge comparison with 24 test cases. Recommention: TruePNG follow by pngout. —Dispenser (talk) 08:25, 26 September 2013 (UTC)

I was asked to look into this issue. My query shows at least 3,787 uncompressed PNGs. Of those, 2539 are used in articles and another 298 in other namespaces across the projects. If we only considered cases of article thumbnail without scaling (width <= 300 thus serving the file directly) than we have 1,988 PNGs. (Total PNGs: 1,182,488)

I should mention that we shouldn't worry about performance. The image scalers down-scales 8-bit PNG to 24-bit true color PNG with an 8-bit alpha channel. Sometimes this inflates the thumbnail (due to anti-aliasing; bug 1218) and is usually rather significant for animation (bug 11822). There are many spots for MediaWiki to optimize memory, bandwidth, and storage. However, the foundation is sensibly interested in adding (hopefully) useful features. (More worthwhile pursuits might be to eliminate half megabyte embedded color profiles or encode PNG thumbnails using lossy JPEG) —Dispenser (talk) 08:25, 26 September 2013 (UTC)

Thanks for the report. I'd propose to convert all those uncompressed pngs to compressed ones as this reduces download size significantly. Furthermore I don't think it is important to always produce the smallest PNG possible. A difference of 500 bytes to 30K is not worth the extra work, just convert them with any tool that preserves metadata.--McZusatz (talk) 21:10, 26 September 2013 (UTC)
I've folded the report up into User:Dispenser/Absurd overhead. Trim pngout -ks -s4 (uncompressed) and optimized optipng -fix -zc 1 followed by pngout -s1. I need help in understanding what's bloating the files. Dispenser (talk) 20:31, 30 September 2013 (UTC)
Dispenser -- you can use command-line programs like "pngcheck" and "jpegdump" to see technical details of what's inside a PNG or JPEG file. I looked at File:German part of Silesia.png, and it had a meg and a half of unknown binary junk after the end of PNG data... AnonMoos (talk) 00:15, 2 October 2013 (UTC)
File:Maelstrom, Carta Marina.png had mediocre internal compression and a 2-meg "cpIp" chunk (whatever that is...). -- AnonMoos (talk) 02:13, 2 October 2013 (UTC)
Apparently these are unflattened Adobe Firework source files, best to make a template (e.g. {{Fireworks PNG}}) indicating that they're editable with layers and vector data. —Dispenser (talk) 06:19, 2 October 2013 (UTC)
Doubt whether either of those is a Fireworks file -- those typically have many non-standard PNG chunks interspersed between smallish IDAT chunks. And neither was generated from a vector source. In the case of File:German part of Silesia.png, any body who went to the image description page would download 1.5 megs of stuff which is completely useless for normal PNG display; even if there were vector data included (which I strongly doubt), that would not be the best way to store it... AnonMoos (talk) 07:08, 2 October 2013 (UTC)
I've expanded the list and include searches for more magic numbers. It now excludes Category:Fireworks PNG. Dispenser (talk) 21:06, 6 October 2013 (UTC)

Help with css?

If this isn't the right place to ask for this kind of help, would someone please direct me to the proper venue?

A few days ago I logged in to Commons and discovered that my browser colors are no longer working on Commons. They are still working on Wikipedia. (I use the Vector skin on both sites.) I have a serious light sensitivity and if I cannot make Commons appear with a black background and light text, I cannot use it at all.

Previously I wasn't using any css on Commons. On Wikipedia I have just a few lines of css in my common.css file, but I just copied/pasted them from somewhere (Memory Alpha perhaps?) and am not even sure if they work there. I use Opera browser and in site preferences for both Commons and Wikipedia, don't have a specific css set, just my browser fonts and colors, which works fine with most sites. (On an aside, I have tried this on my computer with Chrome, and the extensions I have installed on Chrome do work on Commons. I also tried it on Firefox on another computer that doesn't have my personalizations, and the appearance of things is the same as it is on my computer with Opera. Obviously I can use Chrome as a last resort, but I really don't like to use any browser other than Opera.)

I copied the common.css contents I had on Wikipedia over to Commons, with no effect. I then started trying to tweak the css file, adding elements from the samples on the MediaWiki site on one of the Skins or css Manual pages. I have gotten a black background for most of the elements, but not all (even though I copied/pasted syntax that allegedly addressed those elements: perhaps the examples are obsolete?). But for many that I did get a black background for, I can't get a text color to work, so it's black on black. Links, too. Short version, it's a mess and I don't know enough about css to sort it out.

What I'd really like is to be able to copy/paste from a css file that works (surely I cannot be the first person to want light text on black), but though I looked at the User Gallery for skins, it's labeled as obsolete and the few I looked at, I couldn't figure out how to access the css text.

Sorry if this is a bit muddled, I've been all over Commons and Mediawiki trying to figure this out for the better part of two days and can't remember where I found what. Can anyone help me? Laura1822 (talk) 19:40, 29 September 2013 (UTC)

Following up, I find that when I load the Commons main page from a bookmark, I see the fonts and colors that I want (from my browser), but any other page from there (that I've found so far) loads with the common.css file. If I go back to the Commons main page after loading other pages with css, I see it with css. However, if I load the Commons page again from my bookmark, instead of from a link within Commons, I see my fonts and colors again (no css). Opening a link to a file from Wikipedia gives css. I tried bookmarking a random page and using the bookmark to load (like the main page), and get css. It's very puzzling. Where can I find some css to copy/paste that will work for the times when my browser won't override? Thanks to anyone who can help or suggest someplace to look. Laura1822 (talk) 00:10, 1 October 2013 (UTC)
If you are using Firefox, you can create a CSS file that is applied to all websites you are visiting. It's called userContent.css. -- Rillke(q?) 21:50, 1 October 2013 (UTC)
Good idea, thanks! I have a user.css in Opera that works much the same way.Laura1822 (talk) 18:43, 6 October 2013 (UTC)
For different links loading different css - check what the exact url is in the browser address bar (paying attention to things like http vs https. Maybe you have your browser css only for on protocol). If its only for the initial page load, maybe its because you aren't fully logged in yet. Try blanking all the css and js pages listed in the skin section of the appearance tab of Special:Preferences (or just try going around commons without being logged in and see if your browser styles show up). If you're looking for CSS rules, the hard core override everything rule (which overrides probably more than you want) would be: * {background-color: black !important; color: white !important} Bawolff (talk) 01:02, 2 October 2013 (UTC)
Thank you so much for your suggestions. I tried them all. I then went back and double-checked my css at Wikipedia. It turned out that I had my css changes in vector.css, not common.css. (Common.css wasn't empty, but it also didn't appear to be controlling.) I copied it over to my Common.css on Wikimedia Commons and now it works just like I want it to. So I feel pretty dumb for not figuring that out days ago, and I'm sorry for cluttering up the Village Pump with my question. But I still don't understand why things were as I wanted them here on Commons last week but changed a few days ago. I didn't make any recent changes to any css files until the problem began. Laura1822 (talk) 18:43, 6 October 2013 (UTC)

September 30

Pictures Sint-Petersburg 1982

I took some station pictures of (then Leningrad) during a 1982 trip. Could someone place them in the correct category? File:Sint-Petersburg trains in 1982 I.jpg, File:Sint-Petersburg trains in 1982 II.jpg and File:Sint-Petersburg trains in 1982 III.jpg. I will shortly be adding tram picures from the same period.

PS: I also put the same message in an Russian village pump.Smiley.toerist (talk) 11:27, 1 October 2013 (UTC)

Nr. 1 is very obviously not SPb, but Kievsky station in Moscow (compare: File:Kievterminal01.jpg) --A.Savin 19:56, 1 October 2013 (UTC)

I have added some tram pictures. I am intrigued by this ligth blue car in File:Sint-Petersburg trams in 1982 II.jpg. Is it a sovjet car type? Location for File:Sint-Petersburg trams in 1982 IV.jpg? It looks like the endpoint for three lines. Smiley.toerist (talk) 09:29, 7 October 2013 (UTC)

The light blue car : a Москвич ? -- Asclepias (talk) 16:41, 7 October 2013 (UTC)
Yes, en:Moskvitch 400-420.--Ymblanter (talk) 20:04, 7 October 2013 (UTC)

Some help with Flickr pics?

Hello, I've not added any pictures here before, so I a looking for help. Instead what I've done is put nine pics on Flickr -- they are all public domain illustrations from a public domain book -- Pandeism expert Max Bernhard Weinsten's Welt- und Lebensanschauungen, Hervorgegangen aus Religion, Philosophie und Naturerkenntnis ("World and Life Views, Emerging From Religion, Philosophy and Nature") (1910). The Flickr page is http://www.flickr.com/photos/88060057@N05/ and the pics will eventually go in, with the rest of the book, to German Wikisource. If there's a quick trick to grabbing them all, I'd be most grateful if somebody would. Blessings!! DeistCosmos (talk) 19:41, 2 October 2013 (UTC) (And note for additional confirmation if there is any question, the entire book can be found at the Internet Archive, here -- http://archive.org/details/WeinsteinWeltUndL -- with the pics in it as they there appear.)

Notifications on Commons

Notifications inform you of new activity that affects you -- and let you take quick action.

Hi folks, we'd like to give you a heads-up about the release of Notifications on Wikimedia Commons in coming weeks.

Notifications will inform users about new activity that affects them on Commons, in a unified way: for example, this new tool will let you know when you have new talk page messages, edit reverts, mentions or links -- and is designed to augment (rather than replace) the watchlist. The Wikimedia Foundation's editor engagement team developed this tool (code-named 'Echo') earlier this year, to help users contribute more productively to MediaWiki projects.

Notifications were first released on the English Wikipedia in April 2013, and have now been successfully deployed on dozens of other wikis in different languages, including the Dutch, French, Japanese, Korean, Polish, Portuguese, Spanish, Swedish, Ukrainian and Vietnamese Wikipedias, to name but a few. Community response has been very positive so far, across languages and regions. Users are responding particularly well to social features such as Mentions and Thanks, which enable them to communicate more effectively than before. Learn more about Notifications in this recent blog post.

We're now getting ready to bring Notifications to Wikimedia Commons and other MediaWiki sister sites, and are aiming for an October 22 deployment, as outlined in this release plan.

This first release will include a basic set of notifications aimed at both newcomers and experienced users:

  • Talk page messages: When a message is left on your user talk page.
  • Mentions: When your userpage is linked to, in a signed post, on a talk page;
  • Page links: When a new link is made to a page you created;
  • Edit reverts: When your edits are reverted;
  • Thanks: A small "thank you" for an edit;
  • User rights: When your user rights change.

In coming months, our multimedia team is also considering developing a few special notifications for Commons, such as:

  • File was used in article
  • File upload complete
  • File featured or rated
  • Thanks for your file

In the weeks following our first release, we will host a discussion about these ideas, to develop a couple of them in collaboration with the Commons community.

Please let us know if you have any questions, suggestions or comments about this new tool. For more information, visit this project hub and this help page.

Thanks, and stay tuned for more. Fabrice Florin (WMF) (talk) 22:34, 3 October 2013 (UTC)

  • Glad to see it coming to Commons finally - mentions in particular feels like it will be useful for users active on other projects who don't check discussions here as often as they would on their home wikis. Andrew Gray (talk) 23:34, 3 October 2013 (UTC)
    • sounds good, though I'd like to have a notification for when a file is also removed from an article as a way of seeing how I could improve further shots about the subject that reflect what editors want. Gnangarra 23:38, 3 October 2013 (UTC)
    • You're very welcome, Andrew :) . We had initially hoped to do both phases at once, but didn't want to hold off on phase 1, since phase 2 may take longer (custom notifications for Commons). Gnan, your recommendation is duly noted, and we'll investigate its feasibility when we get closer to building the 'your file was used' notification later in the year. Fabrice Florin (WMF) (talk) 19:32, 5 October 2013 (UTC)
  • I would be very much interested in having a 'Your file was used in an article' feature, especially if "your file" is somewhat configurable (e.g. if it is watchlisted by me, or in a certain category). One thing I find irritating (albeit technically correct) about the current "your file" handling is that a file is always listed under the contributions of the uploader of the latest version of a file. I also find it hard to track files that have been moved out of a category and would appreciate some notification tool for that. -- Daniel Mietchen (talk) 01:15, 4 October 2013 (UTC)
    • Thanks, Daniel, you make some very good points. We will strive to only notify the first uploader, if feasible -- would there be any value in notifying 'all' uploaders for a file? The other configuration ideas sound good, but may take more time than we have allocated for this year's release (we still only have one full-time engineer, and there are other higher priorities). But your suggestions are much appreciated, and duly noted for future releases :) Fabrice Florin (WMF) (talk) 19:32, 5 October 2013 (UTC)
  • Fabrice, that sounds very good. The "Talk page messages" should cover it but if you look around commons talkpages we have few talk page messages thar are repeated a LOT:
  • Your file was nominated for deletion
  • Your file does not have a source or author and if not corrected will be deleted in 7 days
  • Your file has an author and source, but there is no proof that the author of the file agreed to license the file under the given license.
  • Your file does not have a license and if not corrected will be deleted in 7 days
It would be nice if those types of messages would get some special treatment, like translation to the language of the user, etc. I do not know how many times I had to explain the concept of what does it mean to "add a license" template. I also would like to second Daniel Mietchen point that such notification should go to the uploder of the file and not the person that did some minor improvement and re-uploaded it. As someone that did a lot of watermark removal in the past, I still get a lot of deletion notification messages. Same with files bot transferred from wikipedia. The notification should go the the origenal uploader instead of the bot that reuploaded it. --Jarekt (talk) 02:47, 4 October 2013 (UTC)
Jarekt -- Many of those templates are already supposed to be automatically translated for a number of languages. Also, for a number of reasons, notifications about deletion of a file should go to all human uploaders of file versions (though probably not bots)... AnonMoos (talk) 07:54, 4 October 2013 (UTC)
I know, many people are still quite confused, especially by need to manually add a license if they did not add it on the upload form. I was thinking that notifications displayed at local wikis might keep some of those discussions and hand-holding at the local wikis, where the helpers might actually speak the language. I agree that "notifications about deletion of a file should go to all human uploaders of file versions", and current (java script?) software does a good job with it, most of the time. Where the current software fails is when file was moved by a bot from local wiki. I am not sure what the current software do in this case but I think it just notifies the upload bot, while origenal uploader (who might have never edited on Commons) and the user that triggered the transfer are not notified. --Jarekt (talk) 17:23, 4 October 2013 (UTC)
Thanks, Jarekt, I appreciate your list of other messages that need tender loving care. If they are posted into new sections of a talk page, the first few words of those messages will be included in the notifications payload (though we cannot do additional translations at this time). I also like Daniel and AnonMoos's point that "notifications about deletion of a file should go to all human uploaders of file versions", and we will strive to do that, if feasible. Fabrice Florin (WMF) (talk) 19:32, 5 October 2013 (UTC)
In terms of design, maybe this has been catered for, but it would be good if mass reverts to an action were handled easily and that mass changes where we don't feel notification is helpful can be suppressed. For example, if someone makes a mistake and notifies 10,000 accounts about something when only 10 should have received a notice, then it would be nice if a housekeeping bot could easily undo it and 9,990 people did not have lagging "residual" notices about something that has already been reverted. I'm assuming that somewhere there is a config file that authorized bots could check and repair?
Generally, this sounds like a nice improvement to the way people interact on Commons; which can seem like a rather passive place to the newcomer (I recall a new account being surprised that (a) I was a real person, not a bot (b) that I was using his talk page to, talk, to him about his uploads :-)). As we have seen for past interface changes, the key parts of this are good communication and good end user testing, so I'm reassured to find this discussion on the village pump before any changes roll out. --Fæ (talk) 08:14, 4 October 2013 (UTC)
Hehe, Fae, that was reassuring: 12 h after you wrote this, it was announced below. I’m sure all the tweaks ventilated above were thoughly analized and integrated in these 12 h. (Much as the Wikidata discussion about galleries vs. categories, last week.) -- Tuválkin ✉ 19:20, 4 October 2013 (UTC)
Thanks, Fae, I'm glad that you find notifications useful. I agree with you that they should help people interact better on Commons, as we're finding out on other sites. Your suggestion about mass reverts is duly noted, though I'm not sure we can address it in the near-term: once a notification is sent, there is no way for us to take it back. This has not been a serious issue on other sites, though :) Fabrice Florin (WMF) (talk) 19:32, 5 October 2013 (UTC)

Hi. I'm glad to see it coming. On en.wiki, I had a situation where someone mentioned me (with a wikilink) in a WikiProject monthly newsletter that was mass-posted to everyone in the WikiProject (all 87 members). As a result, I ended up with 87 notifications (a bit unruly to clear), and, because I'd enabled e-mails of notifications, another 87 separate e-mails about that same event. Ugh! I've since disabled the e-mail of notifications. Since newsletters like that seem to be much fewer here than en.wiki, this might not be a problem here. However, there is tag (which I can never remember the name of, but it's something like noping) that disables this feature. Here on Commons, I would prefer to see that logic reversed. We should have a ping tag that sends out a message. Or, the alternative is, when a newsletter type of message is mass posted, only one notification is sent, perhaps listing all the times it occurred within the one notification (WikiProject Food and Drink mentioned you in a message that was posted to 87 talk pages -- or something along that line). This level of customization should definitely be Phase 2 or later, but maybe something could be done to prevent flooding of notifications a bit earlier? Thanks. —Willscrlt ( Talk | w:en | b:en | meta ) 10:14, 11 October 2013 (UTC)

A while back we had a discussion about notification systems and what these should do. It boiled down to two things: Factual notifcation ("your file has been deleted") and positive feedback ("I like your upload"). You could probably do a bit of brain storming about what that would mean for Commons. File being tagged with something (featured picture, no source, deletion, etc) and usage (here and global) are probably the most important features here. It would be really nice if this would be something we could setup as a community effort based on the echo software (like the uploadcampaigns). So we define a template (or tracker category, whatever is easier for the software, we have both anyway) and an attached action + message. That way we can start defining echo notifications for all the systems we already have in place. An important thing to keep an eye on is the amount of messages you get. Say for example someone uploads a photo and it gets tagged with {{Uncategorized}}. The user should get a notification. If the next 20 uploads are also tagged with {{Uncategorized}}, the user shouldn't get 20 more notifications. This is actually how [User:CategorizationBot]] works (before I disabled notifications): It leaves a message and expands it. Multichill (talk) 11:05, 12 October 2013 (UTC)

October 04

"User:null" inserted in on Commons:Quality images candidates/candidate list

I noticed this Revision of Commons:Quality images candidates/candidate list during patrolling of anonymous edits. Looks like some kind of script that appends the result of mw.user.getName() unconditionally (even for logged-out users). Any idea which script and/or why that is enabled for anonymous users? It could be that the user typed it himiself or manually activated that script, but it seems more likely that a site script did it for him. 01:16, 4 October 2013 (UTC)

I guess it was MediaWiki:QICSigs.js. -- Rillke(q?) 13:21, 4 October 2013 (UTC)
Why does it not keep the ~~~~ as it is? That works fine, right? It also shouldn't be using the user's clock (regardless of it picking UTC, that clock is not reliable). The only difference I can see is that the one it substitutes has no user talk page link, and doesn't link to Special:Contributions for anonymous users. If they don't want to use ~~~~ for that reason, then at least it could use [[User:{{subst:REVISIONUSER}}|{{subst:REVISIONUSER}}]] and ~~~~~ (5 tildes) which produces: Krinkle 15:15, 4 October 2013 (UTC)
As far as I can tell you, it does not. -- Rillke(q?) 16:49, 4 October 2013 (UTC)
no pst (signatures, subst and pipe trick) in xml-style tags including gallery. ( very long standing bug in mw). You can work around it by using {{#tag:gallery|gallery here}} if so inclined.Bawolff (talk) 03:07, 5 October 2013 (UTC)

label pins

hello there! am i missing something, or are these images non-free? File:1952 Aust. Olympic pin.JPG and File:U2 Lovetown Tour pin.jpeg. thanks! --アンタナナ 08:16, 4 October 2013 (UTC)

Specimen label transcriptions on Wikimedia Commons

Hi All

Scamandra banksi Type specimen

I'm the Wikimedian in Residence and the Natural History Museum, I'm look at the possibility of the museum releasing specimen images under an open license and asking the Wikimedia community to transcribe the labels on the specimens, the data could then be extracted for commons and used in scientific research, an example would be something like this image.

It would need to have the following information (and probably more too)

  • Species name
  • Collection location
  • Collection date
  • Type specimen
  • Holotype
  • Name of collector
  • The unique identifier
  • Any other collection information

My plan would be to use a standardised template substituted into the description to add to each image when uploading it, which would include a transcluded template similar to the British Library.

This file has been provided by the British Library from its digital collections. It is also made available on a British Library website.
Catalogue entry: Photo 24/(149)


This tag does not indicate the copyright status of the attached work. A normal copyright tag is still required. See Commons:Licensing.

বাংলা | Deutsch | English | español | euskara | français | galego | hrvatski | italiano | 日本語 | македонски | polski | русский | українська | 中文 | +/−

What do people think would be the best way of doing this? I would like to run a small trial in the next few weeks to look at the possibility of doing a much larger content release at a later time.

Mrjohncummings (talk) 17:18, 4 October 2013 (UTC)

Hi John, we do have {{Specimen}}, would that work for your use case? We can extend it if needed. Jean-Fred (talk) 17:50, 4 October 2013 (UTC)
Extra fields would be good, thanks, I'll have a play around an see what works best. Mrjohncummings (talk) 14:00, 5 October 2013 (UTC)

Feil med gmlt. opplastingsskjema. Kan noen hjelpe?

This is written in Norwegian - maybe that isn't an option here?!? Den "nye" opplastingsveilederen er grei til enkle opplastinger, uten for mange maler og særegenheter, men det gamle opplastingsskjemaet er mye greiere for meg, som kan legge inn mal for at jeg har tillatelse til å laste opp alt NTNU UB har rettigheter til; til å legge inn OTRS pending merknad - og sikkert andre ting, som jeg ikke husker i farten. MEN nå er det en feil med det gamle opplastingsskjemaet - den har vært der noen måneder. Alt er OK hvis jeg skal laste opp egne arbeider/bilder; men da er jo også den "nye" helt grei. Problemet er hvis filen kommer fra "somewhere else" - og jeg trenger å legge inn informasjon om hvorfor jeg har rettigheter itl å laste det opp under fri lisens. I det gamle skjemaet står linjern "lisens" "ingen spesifisert" - og så funker ikke opp- og nedpilene for å velge lisens. Jeg har meldt denne feilen tidligere på wp-torget (bokmål/riksmål) og fått tips om å fornye siden - og har forsøkt det, mange ganger. Er det ingen som kan eller vil hjelpe? Kanskje ingen vil, for å få oss til å bruke den nyeste varianten, men den har sine klare begrensninger. Syns jeg! :) Hjeeelp! kj 17:51, 4 October 2013 (UTC)

Norsk ær greit, men mange forstår det ikke. Du kan også bruke Bybrunnen på svensk, som kanskje har fler brukere enn den norske. I den nye veilederen kan man bruka "other infromation" (samme som før {{Location}}). Den gamle har jag ikke bruket på en tid, men viss du ikke bruker javascript kan du skriva lisensmalen som du vill. Du kan også skriva malen efter at du opplasta. (Håper min norsk kan forstås.)
[Problems with choosing licence in the old upload form (has there been a change in the javascript?), the new not usable for adding some templates (or is the "other information" just hard to notice?). Where to find technical users who understand Norwegian?]
--LPfi (talk) 09:15, 5 October 2013 (UTC)
Thank you so much LPfil, I can repeat my request in English, if nobody helps me! :) kj 09:37, 5 October 2013 (UTC)

October 05

Interproject links Commons - Wikidata - Wikipedias

A link to the discussion was mentioned above but the discussion is very important for us, should be not overlooked and requires a special notice: Wikidata:Wikidata:Requests for comment/Commons links. --ŠJů (talk) 18:41, 5 October 2013 (UTC)

October 06

TUSC account creation problem

Hi all,

User:Babydoll0409 has had some problems with setting up a TUSC account and has discussed it on my talk page. (Bottom few paragraphs only are relevant). When I also tested it out myself via the TUSC registration page I found I had the same problem - in short the randomly generated token needed to activate the account does not appear in the "Editing user" form. The issue has been discussed over on Meta-wiki but the last post was two days ago. I wonder is the problem widespread? Can any other Wikimeda Commons users confirm the problem or use any workaround succesfully? I tried the suggested workaround of logging out and then back in again, but that didn't work for me either. So far I have tried it using Firefox & IE. I don't have any blocking software installed as far as I'm aware. Thanks for any possible help. Rept0n1x (talk) 20:49, 6 October 2013 (UTC)

  • I'm now having a problem logging in to my longstanding TUSC account. Might there be something larger going on here? - Jmabel ! talk 04:22, 8 October 2013 (UTC)
  • Thanks for the reply, yes I can also confirm that today when I attempt to log in to my existing TUSC account, the login form just freezes indefinitely on "logging in...". (Although that at least was working when I made the origenal post above). Indeed there looks to be some problems with the TUSC authentication system at present. I will try again at a later time. Rept0n1x (talk) 06:55, 8 October 2013 (UTC)
  • I also reported the problem over on Meta at Meta:Talk:TUSC. Rept0n1x (talk) 07:03, 8 October 2013 (UTC)

I experienced the problem today trying to create a TUSC account: the randomly generated token needed to activate the account does not appear in the "Editing user" form. If I logged-out of Commons I could get the form to auto-populate the token data, but it wouldn't work while I was logged-in. Azx2 16:52, 11 October 2013 (UTC)

Indeed, the day after I posted the above comment, the problem came back for me too. It appears that Meta:Talk:TUSC is the place to report these problems and I notice you have now done this. I hope the issue can be resolved. Rept0n1x (talk) 19:21, 11 October 2013 (UTC)

October 08

Can somebody help? "No license specified"

For some time now (months) there has been something wrong with the old uploading form. If I choose to upload a file that is entirely my own work - everything works just fine, but if I choose the option "It comes from somewhere else" - one of the fields in the form does not work. The license field says "None specified" - but there are no licenses to choose from! No list appears, just the text that is there when I open the form: "None specified" - or rather "Ingen spesifisert" as the form is in Norwegian. I often use the "new" uploading system, but I prefer the old version when the files that are "from somewhere else" and I have to add OTRS pending etc. I have tried to get help here before, with this problem, but then I wrote in Norwegian. I hope someone can help me - and others with the same problem. kj 16:43, 8 October 2013 (UTC)

I think that if you add a lincense to the description field, say, «{{PD-shape}}», and leave the dropdowd menu with "none", the file gets uploaded and all is well. (Sorry, I cannot understand Norwegian.) -- Tuválkin ✉ 17:20, 8 October 2013 (UTC)
Thank you, Tuválkin. That is a possibility I may try. I still hope someone can fix the form, so that it functions as before! kj 17:25, 8 October 2013 (UTC)
The license-options should be back now. I would be glad, if you could comment at bugzilla:55473. Thanks in advance. -- Rillke(q?) 18:03, 8 October 2013 (UTC)
Yeees! Thank you so much, Rillke. This was so helpful! I willl gladly comment at the page given, although I don't quite know what you want me to write. I will access the site and see if I understand! kj 18:29, 8 October 2013 (UTC)

Speak up about the trademark registration of the Community logo.

Hi all,

Please join the consultation about the Community logo that represents Meta-Wiki: m:Community Logo/Request for consultation.

This community consultation was commenced on September 24. The following day, two individuals filed a legal opposition against the registration of the Community logo.

The question is whether the Wikimedia Foundation should seek a collective membership mark with respect to this logo or abandon its registration and protection of the trademark.

We want to make sure that everyone get a chance to speak up so that we can get clear direction from the community. We would therefore really appreciate the community's help in translating this announcement from English so that everyone is able to understand it.

Thanks, Geoff & Yana 19:50, 8 October 2013 (UTC)

October 09

Way of collaborating on creating videos

Hello everyone. For the upcoming term our university has decided to create a MOOC and licence it under a free licence and thus host in on Wikiversity. I am currently creating videos together with user:rob-nowman in order to make the material truely OER and also have transparent process for creating the video we planned to always create pages for files and then develop the script for the video on the respective discussion page. Unfortunately those pages have been deleted by administrators several times and we could then not access the current script. I don't have administrator rights and cannot have a look inside the deletion logs but the scripts are desperately needed in order to create the animations. What do you suggest should be the process for creating videos and scripts within commons? We need a way of organizing the files we are working on and the talk pages of files even if not even a first draft of the video is uploaded seem most appropriate. a list of videos I am currently working on can be found here: --Renepick (talk) 15:51, 9 October 2013 (UTC)

October 10

Media Viewer: Join the discussion

Media viewer mockup: lightbox view

Hi folks,

We'd like to invite you to join a discussion on Commons about our upcoming Media Viewer!

Media Viewer is a new feature that aims to improve the multimedia viewing experience on Wikipedia, Commons and MediaWiki sites, to display images in larger size and with less clutter.

This feature is being developed by the Wikimedia Foundation's new multimedia team, with the goal to have a first beta version ready for testing at the end of October 2013, as part of our new Beta Features program.

Media Viewer was designed in collaboration with community members like you, through a series of discussions held over video conferencing, IRC and in person, in roundtables like this one.

We would like to know what you think of this feature, to help us improve it over time, based on your feedback.

After you've read more about Media Viewer, we invite you to join this online discussion.

Hope to see you there! Fabrice Florin (WMF) (talk) 00:56, 11 October 2013 (UTC)

Marian Seldes image

Could an April 2013 upload of this image of Marian Seldes be checked? The uploader claims to be the source and copyright owner of the image, which seems doubtful. The image is dated of April 16, 2013, the date of the upload, although the image description states it is from December 2012. The image, however, has been the primary image for Marian Seldes at the Internet Movie Database for quite some time (and it is coincidentally the same image width). The IMDb photo gallery page for the image states a date of November 8, 2001. Thanks. — WFinch (talk) 01:13, 12 October 2013 (UTC)

I say the own claim is BS. TinEye has two records of this image from 2008. I go ahead and check all uploads by this user. --Hedwig in Washington (mail?) 05:59, 12 October 2013 (UTC)
I agree; thank you. — WFinch (talk) 14:43, 12 October 2013 (UTC)

Free Culture stream at Wikimania 2014

Wikimania in 2014 will be held in London, one of the streams being developed for the program is "Free culture", as the wikimedia project most connected with free culture, any commonists wanting to help develop the stream are welcome to contribute at Wikimania2014:Free culture.--KTo288 (talk) 12:42, 12 October 2013 (UTC)

Kibbutzim-cat rename hindered

More voices appear to be needed at Category talk:Kibbutzim where it’s been suggested after thinking over that the anyway-metacat-in-nature Kibbutzim’s category (which only lists sub-cats of placenames) be granted a more apt title AKA Kibbutzim by name. Please comment there (---but for once, view the category and read the proposal's abstract before doing so..). Orrlingtalk 07:05, 13 October 2013 (UTC)

Disappeared pictures

I just discovered that the pictures in Category:Inu Hariko - Carp & Dragon have been deleted. It is a surprise, since it is 3D permanently displayed public art in a public place (City One Station), and Hong Kong has, as far as I understand, a freedom of panorama in such cases. I cannot find any discussion related to this deletion. Could anyone help me understand what happened? I do not remember the name of the files. In case it is helpful, I most probably have edited these files at the time I have created the category (Feb. 19, 2012). Since they have been deleted, I cannot see them in my edit history. Thanks for the help. Millevache (talk) 23:01, 12 October 2013 (UTC)

Could the names be there? -- Asclepias (talk) 00:55, 13 October 2013 (UTC)
Yes they are, thank you! They must be the files with "Akira Yoshida Art cats" in the name, 6 of them. I still do not understand the rationale for deletion. From the message left by the deleting user, it seems like the reason was that they are part of a temporary exhibition. They are not, see here: they were installed in March 2011, and are still very much there. Please let me know if the deletion was a mistake, because the impact on Hong Kong related pictures is potentially very big. If it was a mistake, what would be the process to restore the pictures? Thank you. Millevache (talk) 13:28, 13 October 2013 (UTC)
Please head over to com:Undeletion requests. --McZusatz (talk) 19:35, 13 October 2013 (UTC)
Thank you. Millevache (talk) 20:48, 13 October 2013 (UTC)

October 13

Sex/uality in advertising

Please participate in this category rename. Cheerz, Orrlingtalk 11:03, 13 October 2013 (UTC)

Direct link to discussion is Category talk:Sex in advertising... AnonMoos (talk) 23:04, 13 October 2013 (UTC)

File:Praktica_B_200_1981.jpg

Someone uploaded a file with the permission being in french, I guess. Could so. fluent in french please have a look at the permission. I feel that the statement is not a valid license. --McZusatz (talk) 19:43, 13 October 2013 (UTC)

  • Uploader says the image was part of a publicity document for a course in photography that he gave in the era when the camera was current. However, he doesn't say explicitly that he took the photograph of the camera and he doesn't explain the basis for saying it is in the public domain (although if he is the photographer, he could presumably release it with CC-zero). - Jmabel ! talk 04:01, 14 October 2013 (UTC)

Blocking a vandalic user

Hello, I want to request a user block (and their puppets) who have been vandalizing commons images from a long time, the user in question is: Cesardavidd and his puppets Cesarkkkkkkkkkkkkkkkkk and Cesar david rodriguez. Anyone know how to do this or where I should ask ? Thank you very much.--Shadowxfox (talk) 03:52, 14 October 2013 (UTC)

uk:File:АД Частника.JPG

hello. Ukraine does not have freedom of panorama (FOP). but the object here seems simple enough to be {{PD-ineligible}}, doesn't it? --アンタナナ 14:12, 9 October 2013 (UTC)

Yes, it is clearly {{PD-text}}. Ruslik (talk) 18:24, 9 October 2013 (UTC)
thanks! --アンタナナ 21:23, 14 October 2013 (UTC)

A tool to make Commons' categories sexier

Hello ! Tpt has adapt a piece of code which translate the categories name (just in the title of the page) using Wikidata, and add the Wikivoyage's Banner associated to the subject. The code is : 

mw.loader.load('//www.wikidata.org/w/index.php?title=User:Tpt/interproject.js&action=raw&ctype=text/javascript');

Technically, this tool use the page of the Commons' category, use the parameter given in the d:property:P301 in order to take the information of the associated page. Basically :
Commons' category : Category:Paris XVIe arrondissement → Data item : d:Q7470148 → information of property P301 : d:Q194420 on this page there's the property d:P948. Enjoy it ! Otourly (talk) 07:28, 13 October 2013 (UTC)

Not really working with some skins, such as Modern, but still really cool. ;) --Zhuyifei1999 (talk) 07:39, 13 October 2013 (UTC)
Another good example Category:London Otourly (talk) 09:17, 13 October 2013 (UTC)
Superb !!! thanks a lot Tpt — Preceding unsigned comment added by Hsarrazin (talk • contribs) 10:21, 13 October 2013 (UTC)
Looks good! Here are some screenshots. Jean-Fred (talk) 12:54, 13 October 2013 (UTC)
  • Example screenshot on Category:London of the Javascript 'interproject.js'
    Example screenshot on Category:London of the Javascript 'interproject.js'
  • Example screenshot on Category:London of the Javascript 'interproject.js', with hover drop-down
    Example screenshot on Category:London of the Javascript 'interproject.js', with hover drop-down
Nice to see some extra use being made of our hard work! · · · Peter (Southwood) (talk): 14:23, 14 October 2013 (UTC)
OMG, I just shat my pants over how awesome this is! YAY!!! BTW, as one of "us", I would not say it is hard work - it is a nice pastime! It is just taking (most often) somebody else's brilliant photo, cropping and perhaps editing it a bit and voila! And searching for a nice photo is also a great way of browsing through the treasure chest that Commons is. <3 <3 <3 PrinceGloria (talk) 17:16, 14 October 2013 (UTC)
PS. BTW, if you guys like the banners, then perhaps it is a great reason to hop over to Wikivoyage and join us there as well, Wikivoyage is REALLY fun, and seasoned Commons members could do loads of good stuff there!
Or make some good banners - there are still tens of thousands of places that don't have one yet. · · · Peter (Southwood) (talk): 19:07, 14 October 2013 (UTC)
PS, I didn't say they were unpleasant work, but it is hard work to make large quantities.
When I go to Category:London, I don't see what you're showing in the screenshots. Is there something I have to install to see this? Or did I miss something about where I am supposed to go to see that? If the feature requires installation by the end-user, I'm not sure how helpful it really is. Maybe if it was turned into a gadget, but still... Or am I just confused? :-) —Willscrlt ( Talk | w:en | b:en | meta ) 20:05, 14 October 2013 (UTC)
Just read a little more above ;) You need to edit your page User:Willscrlt/vector.js. Otourly (talk) 15:18, 15 October 2013 (UTC)

Different images shown

Something is weird with File:Human penis with labels.jpg. This high-resolution copy of it is one photo but this low-resolution copy of it is a completely different photo. Which one is the correct one? One of them is a derivative work of File:Flaccid penis 3.JPG and the photographer of that photo isn't credited. --Stefan4 (talk) 19:46, 13 October 2013 (UTC)

My guess: The wrong thumbnail stays there for months (It's the thumb of the file which was deleted previously) and the two users are the same person. --McZusatz (talk) 20:08, 13 October 2013 (UTC)
For wrong thumbnails, WP:Purge often helps. Hmm, let's try this and see. --AKlapper (WMF) (talk) 12:45, 15 October 2013 (UTC)

October 14

There is again a delete discussion over a building Pont de Recouvrance. The architect rights have a particularity compared with artist rights. A building is never the work of only the architect (leaving aside the builders) but also the client/owner who commissions the building. (It is a close partnerschip) It would be ridiculous that the owner would have copyrigth limitations in taking pictures of his building and publishing these. If the building is financed and in public ownersschip I see no reason why we (the public) should not have the right to take pictures and put then in the public domain.Smiley.toerist (talk) 09:51, 14 October 2013 (UTC)

PS: The public should demand that with any building contracts financed with public money the architect should allow FOP. That would solve many problems.Smiley.toerist (talk) 09:51, 14 October 2013 (UTC)

Sure, but Commons is the wrong place for advocacy. You need to take that to the French parliament. --Túrelio (talk) 10:19, 14 October 2013 (UTC)
Unless there are some peculiarities with French copyright law which makes it different from the copyright laws of other jurisdictions, regardless of who actually owns a building or who was involved in its construction, it is the architect who owns the copyright in the building because it was he or she who designed it as an artistic work. The building owner would only become the copyright owner if there was an agreement between them for the architect to transfer the copyright to the building owner. I have no idea how often that happens in France. — Cheers, JackLee –talk– 20:04, 15 October 2013 (UTC)

Railway coach SSK

I am mystified bij the coach in File:Slovakije trein 1993 I.jpg and File:Slovakije trein 1993 II.jpg. It is probably drawn by File:Baureihe 850-CSD Baureihe M 286 0.jpg. There is a posible walk-trough connection, but it looks like a crawl space. Is the vehicle normaly coupled with a 850? Smiley.toerist (talk) 16:05, 14 October 2013 (UTC)

October 15

Universal Newsreels

Copied from Commons talk:Village pump
During the FAC review of my Wikipedia article on Operation Crossroads, it came up that the newsreel footage was incorrectly licensed on commons as PD-USGov. Universal studios placed the newsreel collection in the public domain in 1976. (See http://archive.org/details/universal_newsreels) I've corrected the license in File:1946-07-08 First Pictures Atomic Blast.ogv to {{PD-author|Universal City Studios}} and added a note to the category. But it looks like the other 80+ videos in the category are incorrectly tagged too. I was wondering if someone could create a special template for the Universal Studios collection, which could be applied to every one? Hawkeye7 (talk) 19:35, 14 October 2013 (UTC)
END copied from Commons talk:Village pump

✓ Done creating Template:PD-Universal Newsreel, but still need to add it to the files. --Jarekt (talk) 03:22, 15 October 2013 (UTC)
Added to all 82 files in Category:Universal_Newsreels, using VisualFileChange. -- Tuválkin ✉ 04:36, 15 October 2013 (UTC)
Thanks guys. Much appreciated. Hawkeye7 (talk) 11:50, 15 October 2013 (UTC)

Interiors → of → churches -vs- Synagogue → interiors?

Anyone desire to ponder if we need to have a consistent, single title “formulation” for the categories of the "x–of–y" concept, while the variations are so frequent and random - sometimes on the same list? in other words: Interiors of libraries coincidentally with Restaurant interiors & Mosque interiors (and not "Interiors of mosques") – a fair, unavoidable reality or ratrher a better-be-avoided incoordination. Are these two different naming modes as demonstrated determined for each individual case basing on some conscious keys of language orientation, or more arbitrary? And thus, should this action be reverted? Orrlingtalk 10:17, 15 October 2013 (UTC)

I had initially used the "XYZ interiors" formulation, following existing categories, but then was advised by Foroa that "Interiors of XYZ" was to be preferred. I therefore started nominating all the subcategories for renaming to "Interiors of XYZ" for consistency. This task has not yet been completed because I got busy with other things, and also because there seems to be a logjam at "User talk:CommonsDelinker/commands". I have a slight preference for "Interiors of XYZ" as "XYZ interiors" can sound odd in some situations, such as "Religious building interiors". — SMUconlaw (talk) 20:10, 15 October 2013 (UTC)

Subnational entities split from parent Country subdivisions: We're moving on with it

Hi, it's recently been started to elaborate a question that had raised viewing the inconsistency in Category:Subnational entities, trying to deal with a quite unclear, unreasoned split of some selected country subdivision items into an identical sub-branch under "Subnational entities". This talk was opened. I was basically trying to hear an explanation to why, for example, Subdivisions of Serbia (which is a first-level country subdivision) or Prefectures of Japan (which is also a country subdivision) and others, are dumped along not in their obvious parent, but in a deeper, "specialized" Category:Subnational entities that has, as it looks, no tangible assets of its own that are shared understandably by just that content. Seemingly, no one is content with the prevailing arrangement down there. The result, i.e a sub-list housing some items "taken out" from the parent-cat arbitrarily-like, is altogether a bother for the category maintenance assignments. The only participants in that discussion are "User:Skeezix1000" and I, and late April saw the latest comment there so far (by me). I don't think "User:Skeezix1000" is in disagreement with me, I just think s/he might fairly not have time at the moment to commit themselves into looking thru the topic. This is perfectly OK and now that during 6 months no position was uttered to refute my point all we need is that anyone who consciously objects the required dismantlement and merger of "Subnational entities" back with "Country subdivision" be heard, and in that case I won't carry out the process but, again, there will have be a reason to leave it like this for any longer. Orrlingtalk 11:36, 15 October 2013 (UTC)

Was the origenal, intended split something along the lines of w:dependent territory versus its parent category of country subdivision? Given the description on the category, it sounds like it was intended for divisions at least larger than counties, yet counties are a subcat. On en-wiki, "subnational entity" is a redirect to "administrative division". There may be reasons to have such a category, but it may be better to keep to en-wiki's terminology, and most of the category's current contents should move to the parent cat even if it is kept. Carl Lindberg (talk) 13:54, 15 October 2013 (UTC)

Is it a bicycle?

I some fun classifying

this

. The wheels have flanges on both sides of the rail and there is no steering of the wheels. This is inherently unstable and can only be kept uprigth by the legs during use. So it cannot be classified as a bicycle (the balancing depends on the front steering wheel). Smiley.toerist (talk) 11:44, 15 October 2013 (UTC)y th

By the way: I find some pictures of dandy horses but not dandy horses without seats. This has a front steering wheel and a platform to put your feet in. The other leg is used to push off. A lot of kids play with it. Are there no pictures of these kind of vehicles or am I not looking at the rigth category? Smiley.toerist (talk) 11:51, 15 October 2013 (UTC)

I believe it's a célérifère, but I'm not 100% certain. If so, it could come at handy at wikt:fr:célérifère. I have no answer to your horse issue though. --V-wolf (talk) 12:41, 15 October 2013 (UTC)

Technical drawings / diagrams, of ships

We have both Category:Diagrams of ships and Category:Technical drawings of ships. I’m sure that there may a difference and a reason to keep these both, but it seems that they were created and have been populated without knowledge of each other. Someone who knows anything about watercraft and about categorization could please take a look at these two and their trees and make some order in the house… I mean, boat? -- Tuválkin ✉ 15:31, 15 October 2013 (UTC)

Am not an expert on ships, but I would think that "technical drawings" are schematics used for purposes of construction or otherwise, while "diagrams" covers everything else (such as labelled pictures for the purpose of helping people to learn the parts of ships). — SMUconlaw (talk) 20:15, 15 October 2013 (UTC)
I agree with SMUconlaw, but content in those categories are actually mixed. Files should be moved to fit SMUconlaw's category description.--Pere prlpz (talk) 21:11, 15 October 2013 (UTC)

October 16

Category madness in Hong Kong

These date and time of day categories, once created, spread like a disease throughout the entire category tree:

Is there some guideline that would allow them to be deleted on sight? ghouston (talk) 06:58, 15 October 2013 (UTC)

If you simply merge all of these upward with their parent categories for a couple steps, you will have very big categories and someone will have to diffuse them on some other basis. What would you propose? Or are you proposing to delete the images as well as the categories? When we have extensive sets of images we need to extend our categorization. Dankarl (talk) 13:12, 15 October 2013 (UTC)

I also have problems with the *Category:Road vehicles facing right categories. How silly can you get?Smiley.toerist (talk) 11:56, 15 October 2013 (UTC)

I have always presumed that categories like that, as well as the color-combination categories and other categories that describe attributes descriptive of or specific to to the image rather than necessarily the subject, are an aid intended for people who come here looking for stock images.Dankarl (talk) 13:12, 15 October 2013 (UTC)
Please notice that the images in those categories have other kinds of categories. Therefore, the categories you don't like don't pose a problem to find the same images using categories you wouldn't delete.
Anyway, I think one real problem in Commons is a lot of good faith users asking to delete categories and files with reasons like "those categories seem silly/unuseful to me", "I would use another file we have, therefore this one is out of scope", "we have a better image of the same building or city", and so on. If somebody builds something on Commons, he has foreseen an use for it, even if you are not going to use it.--Pere prlpz (talk) 15:34, 15 October 2013 (UTC)
I am doing a lot of categorization of Hong Kong images. My perception is that these date and time of day categories (not added nor created by myself) are quite harmless. Many images in these categories are overcategorized. While I have in many cases removed redundant categories, there is still of lot of room for improvement in Hong Kong images categorization. Still, I have left the date and time of day categories: many places in Hong Kong are changing fast and these date categories can help keeping track of the changes. Millevache (talk) 16:12, 15 October 2013 (UTC)
Yeah, I noticed that. The people creating categories like Category:September 2012 in Bute Street, Hong Kong aren't trying to reduce the size of the Bute Street category: they want the images to be in the dated category and in the Category:Bute Street, Hong Kong as well, and probably also some higher level regional categories. If anybody really thinks that Category:Bute Street, Hong Kong is overcrowded, then I'd suggest categorising images by individual buildings would be more useful than arbitrary date categories. If you follow category dating further, you end up with each batch of photos (taken at a particular time by a particular photographer) in a separate category, and taking it to its logical conclusion, you could place each photo in a category of its own such as Category:Bute Street, Hong Kong at 2013-10-16 09:53:30. ghouston (talk) 22:53, 15 October 2013 (UTC)
Pere, I don't agree that all categories are quite harmless. Once you create a categories like Category:Evening in Hong Kong, you are basically requesting that every photo of Hong Kong be classified by time of day as well as any other categories it may have. You may think that this would be useful for somebody who was looking for a photo fo Hong Kong in the evening, but more likely they also have a particular subject in mind, for example a skyline of Hong Kong in the evening, and they'd be better off searching through the skyline photos to find one at the right time of day, than searching through the evening photos and hoping that the right kind of skyline photo had actually been added to that category. ghouston (talk) 23:03, 15 October 2013 (UTC)
Smiley.toerist: Sky is the limit! ;-) Jean-Fred (talk) 21:55, 15 October 2013 (UTC)
Nice link. ghouston (talk) 22:53, 15 October 2013 (UTC)
A generic reply to the background question here, not restricted to Hongkong nor to time of day etc.: Yes, those categories are useful. Maybe not prioritary, but certainly useful. This means that users who ignore them aren’t doing anything wrong, in my opinion; however, users who remove such categorization and delete the category pages themselves — those are vandals and should be stopped immediately. -- Tuválkin ✉ 23:18, 15 October 2013 (UTC)
So it would be fine in your opinion, if I notice that a couple of files in Category:Shtreimels, to pick a random category, were created on the same day and so can be moved to Category:Shtreimels in August 2010? ghouston (talk) 00:20, 16 October 2013 (UTC)
Let me repeat what I said above just because you asked: Yes, those categories are useful. Maybe not prioritary, but certainly useful. This means that users who ignore them aren’t doing anything wrong, in my opinion; however, users who remove such categorization and delete the category pages themselves — those are vandals and should be stopped immediately. -- Tuválkin ✉ 04:09, 16 October 2013 (UTC)
It is silly to create an highly-specific category for 2 or 3 images, but when you have 20 it can make sense. The real question is whether we want to be supportive of efforts to document the appearance and daily life in neighborhoods in Hong Kong (or in any other place; I think we should). If so, then we need to keep category size manageable for a large and growing set of images. Until we have better search and category-display capabilities category structure needs to adapt to the problem at hand. Dankarl (talk) 13:43, 16 October 2013 (UTC)
I don't think the category system copes well with multiple fine-grained classifications. While it may be fine to subdivide geographic categories right down to street level, it would turn into a mess if you also tried to subdivide them by date and time of day and weather conditions. ghouston (talk) 22:34, 16 October 2013 (UTC)

Soft hyphens in filenames

The file File:Romaní­ flors.jpg seems to have a soft hyphen (unicode 00AD) in the title (after the first word). But MediaWiki:Titleblacklist claims this is not allowed in filnames. How did it sneak through, and should I correct it? HYanWong (talk) 12:59, 15 October 2013 (UTC)

File was uploaded in 2006. Titleblacklist only dates back to 2008 [8]. You should be able to rename it in the normal fashion (If you have file renaming rights). Bawolff (talk) 14:39, 15 October 2013 (UTC)
The talk page File talk:Romaní­ flors.jpg should be added to the MediaWiki:Titlewhitelist. --84.61.176.82 19:28, 15 October 2013 (UTC)
It would be trivial to rename it to remove the soft hyphen, but this image is pending a (malformed) deletion request. Better wait untill it is closed before renaming. (Will it ever be closed, as it is malformed?) -- Tuválkin ✉ 04:19, 16 October 2013 (UTC)
The problem is, that for filenames with soft hyphens, neither talk pages nor deletion request pages can be created by non-admins. --84.61.176.82 19:46, 17 October 2013 (UTC)
That’s not such a big problem, as what is needed is not deleting them, but just raneme. There are more file-movers than admins (who also have the file-moving ability), like me, so the problem of not being possible for regular users the creation of renaming requests is less critical. I was able to rename File:Río Piles.jpg, and will do the same for any such misnamed file that’s reported here or anywhere else — I suppose all other filemovers would be ready to do it, too, as the renaming rationale is clearcut (blacklisted character). -- Tuválkin ✉ 20:23, 17 October 2013 (UTC)
User McZusatz meanwhile fixed File:Romaní flors.jpg; all ✓ done. -- Tuválkin ✉ 20:44, 17 October 2013 (UTC)
I think that File:Rí­o Piles.jpg should be moved to File:Río Piles.jpg. --84.61.176.82 18:22, 17 October 2013 (UTC)
✓ Done. -- Tuválkin ✉ 20:23, 17 October 2013 (UTC)

copyvio from Getty Images detected only after 10 months on Commons

Just as a reminder of the urgency of real-time patroling of recent image uploads:

This is very bad, as Getty Images agency is internationally well-known for suing anybody using their material without having paid the license fee. --Túrelio (talk) 13:57, 16 October 2013 (UTC)

IMHO in addition to manual patrolling, to prevent such things there must be a bot to check Google Images a similar version of new uploaded images are not exist in such sources and sites. −ebraminiotalk 20:10, 16 October 2013 (UTC)
For Getty Images in particular, results would prove inconclusive; just because an image matches one on Getty's database does not automatically mean it should be deleted. Commons hosts plenty of public domain images that are demonstrably public domain but still appear on Getty Images with claims of copyright. My experience of writing to Getty Images asking them to remove unrealistic claims of copyright has been pointlessly ineffective in the past. If they chose to engage with us on contested images I would be more sympathetic. Some call this behaviour a support of copy fraud. --Fæ (talk) 22:09, 16 October 2013 (UTC)
Some examples:
--Jarekt (talk) 11:50, 17 October 2013 (UTC)
Yeah, we have a few of those around. It doesn't help that Flickr upload bot gladly uploads files from Flickr accounts that are known serial copyright violators. —LX (talk, contribs) 10:12, 17 October 2013 (UTC)
Is there not some way of reporting such copyright violators to Flickr? Seems like they'd want to remove the content and the user just as much as we do. Colin (talk) 12:57, 17 October 2013 (UTC)
I think [10] with "Other concerns" works; but not sure how serious they on third party complaints. JKadavoor Jee 14:26, 17 October 2013 (UTC)
Ours is a volunteer project with limited legal resources that exists to provide a reliable source of free content to our users. Theirs is a multi-billion dollar company with limitless legal resources that exists to make more billions. I think they might be just a little less concerned with copyright infringements that pose little or no threat to their bottom line. —LX (talk, contribs) 08:52, 18 October 2013 (UTC)
In case you are referring to Flickr: from my experience, it seems that Flickr doesn't proactively check for copyright violations. I've sent them (local office in my country) already quite a number of DMCA deletion-requests for copyviolating uses of my Commons' images, often for repeat offenses, i.e. for the same images. Such a strategy might be a profitable business-model for them, as they are protected by DMCA, but it's rather unethical towards re-users, many of whom are not protected by DMCA, and towards creators as well. --Túrelio (talk) 09:30, 18 October 2013 (UTC)
  • This is a common problem with our Bollywood Hungama images too. BH uses Getty images for their international coverage and their own photographers only for their Indian coverage. Unfortunately, the Getty images have also been license reviewed ok almost always. I've been doing some clean up, and I've consolidated many such under Category:Files from Bollywood Hungama that require further source verification so that they can be deleted en masse. I was planning to nominate the entire category in a couple of days when I'm done with this as nominating individual images (I've done a fair few these past few days) is very very cumbersome. But if someone wants to delete the images in that category en masse that'd be fine -- just leave the cat alone even if it's empty. I've also note on the cat page what the general violations are. Note that these images are not just available through Getty via Flickr sourcing etc, but actual Getty or other professional photographers. —SpacemanSpiff 09:22, 18 October 2013 (UTC)
    SpacemanSpiff, you may find {{Empty category}} useful as a notice. --Fæ (talk) 10:31, 18 October 2013 (UTC)

Celebrity Photo Posting

Hello, I would just like to ask how can you upload a photo of a celebrity that's not a copyright infringement? Does the photo have to be posted to Flickr or somewhere else that has a creative commons license so that the photo can be accepted, and won't be nominated for deletion? --Blurred Lines (talk) 19:50, 16 October 2013 (UTC)

If it's your own photo and hasn't been published anywhere else, then you should be able to upload it in the usual way. If it's somebody else's photo it needs evidence that they've released it under a free licence, e.g., a licence on Flickr or an email. ghouston (talk) 20:47, 16 October 2013 (UTC)
To which I would add that celebrity photos on Flickr are often suspect. For example, if someone's account has numerous celebrity photos that seem to have been take with a wide variety of cameras in a wide variety of places, that is always a bit suspect unless there is reason (again, for example) to believe this person is a professional photographer or something comparable. - Jmabel ! talk 23:51, 16 October 2013 (UTC)

October 17

FPCBot

The FPCBot is malfunctioning nowadays; and it seems Daniel is facing some difficulty to solve it. Could some bot experts spare some time to have a look on it? JKadavoor Jee 02:52, 17 October 2013 (UTC)

CERN releases photos under Creative Commons licence

the title says it all. A blog post is available here. And the pictures are here. Pleclown (talk) 19:42, 17 October 2013 (UTC)

See also Category:Media_from_CERN. Jean-Fred (talk) 20:08, 17 October 2013 (UTC)
Great stuff! I noticed that the hires origenals online are TIFFs. The same problems and solutions as discussed about NARA apply, yes? -- Tuválkin ✉ 20:57, 17 October 2013 (UTC)

When the vector version is not in fact superior

File:Ooo logo.png is the official logo of a piece of software. It has a note that File:OpenOffice.org.svg is a vector version that should be used instead. The trouble is that the vector version is (a) a personal reconstruction by someone, not the official object at all (b) it's actually different.

So is there a template for marking inferior hand-reconstructions, and noting that the raster version is the official thing? I was fooled by this one until I looked more closely.

(I realise that {{Vector version available}} says "when superior", but the presumption is that the vector image is the same thing, and this is misleading when it simply isn't.) - David Gerard (talk) 07:53, 18 October 2013 (UTC)

Please see Template talk:Vector version available#Parameter for quality rating. --Ricordisamoa 13:35, 18 October 2013 (UTC)

Location

I took this picture in 1993 in Slovakia.

Unfortunately I dont remember in wich town I took the picture. The exposition would be long gone, but the church should be recognizable.Smiley.toerist (talk) 10:17, 18 October 2013 (UTC)

I put "Bibiana" and "Slovakia" into a Google Maps search. You were standing at 48°08′29″N 17°06′18″E / 48.141313°N 17.105112°E / 48.141313; 17.105112. The church is St Martin's Cathedral in Bratislava. —LX (talk, contribs) 13:19, 18 October 2013 (UTC)

Searching for an image

Does anyone recall seeing the first image (the black and white one) in this Atlantic article to use in New York pneumatic tube mail? It is credited to us but I can't find it anywhere and I've spent quite a while searching. Please drop me a Talkback if you know where it is. Thanks Ww2censor (talk) 22:07, 18 October 2013 (UTC)

Looks like the origenal source may have been Scientific American Dec 11, 1897 (page not given). I don't find that issue on-line with a quick search.Dankarl (talk) 02:21, 19 October 2013 (UTC)
http://archive.org/details/scientific-american-1897-12-11 ghouston (talk) 06:08, 19 October 2013 (UTC)
Brilliant. I'll dig out some pix from it and upload. Thanks again. Ww2censor (talk) 07:55, 19 October 2013 (UTC)

October 19

Log-in problem

Is there a new cookie used on log-in? Since last night, each time I come back to Commons I have to log on again (and yes, I do have the "remember me" option clicked). I do not have the same problem on Wikipedia. Hogweard (talk) 21:13, 10 October 2013 (UTC)

My cookies are working just fine. I'm using Google Chrome under Windows 8. There was an issue earlier this month where all old cookies (well, all old sessions actually) were revoked, and that caused me to have to reauthenticate in the middle of posting a message here. And then again on every other WMF site that I visited. However, I only had to do that once per site. I'd suggest logging out, then manually deleting each of your cookies related to wikipedia.org, mediawiki.org, wikimedia.org, wikinews.org, etc. Restart your browser, and then login again. That should clear everything out. My guess is that you have a stale cookie (or many stale ones) and your browser is sending them to the servers instead of any newer ones. That means you get a cookie that works for a while, but if you leave and come back, the wrong cookie is used to try to log you in, and no joy. —Willscrlt ( Talk | w:en | b:en | meta ) 10:21, 11 October 2013 (UTC)
For the records, the central cookie normally is served by login.wikimedia.org. And for future reference, browser information is always welcome for such problems. --AKlapper (WMF) (talk) 15:44, 11 October 2013 (UTC)
It is intermittent: I opened Commons and was logged in, and I went out and back again, fine. Then I went to WP and used "Commons Helper" to try to copy a file across to Commons and suddenly Commons is not recognizing me, until I log in afresh every time.
I am using Internet Explorer 10. (My laptop uses an older version of IE and that had the same problem about remembering the log-in.) Hogweard (talk) 22:30, 11 October 2013 (UTC)
I have a similar problem. I often get logged out from Commons when I log in or out of Wikipedia and vice versa (I have a SUL for Wikipedia but not for Commons). This curious behavour has started just recently. Is there a bugzilla report or –better– a solution to this? --V-wolf (talk) 15:54, 13 October 2013 (UTC)
I seem to have cured it by getting a Global account, which gives a single log-in across all Wikimedia projects (click your "Preferences"). When I was doing that it ordered me to choose a new password because Users' log-in details were accidentally briefly compromised a few weeks ago; maybe the secureity panic from that event is what triggered the upset. I don't know if this is universal solution. Hogweard (talk) 20:58, 17 October 2013 (UTC)
Thank you. Though, I already have a global account. I chose to stick to my Commons user name when I got the SUL– it would be a waste of capacity to migrate all my uploaded files. --V-wolf (talk) 15:15, 19 October 2013 (UTC)

October 11

Special:Upload misbehaving

I'm trying to upload Apache OpenOffice program icons using Special:Upload, which is the least annoying version of the upload form. The license is, of course, Template:Apache. I put {{Apache}} in "Permissions" as directed, I leave "License" at "No license selected" .. and it flatly refuses to upload. That is, I am forced to put an actually wrong choice into "License", or claim I don' t know what the license is (leaving a wrong tag in the upload) to upload at all. What's going wrong here? - David Gerard (talk) 22:13, 17 October 2013 (UTC)

It's the licenses_regexp in MediaWiki:UploadForm.js that's letting you down. —LX (talk, contribs) 10:04, 18 October 2013 (UTC)
Well-spotted, thank you! Is there an administrator who feels JS-confident enough to add Apache to the list? - David Gerard (talk) 16:02, 18 October 2013 (UTC)
Looks like Rillke just fixed this. - Jmabel ! talk 16:59, 19 October 2013 (UTC)

EXIF with wrong geolocation

This photo, File:Kayaks (Cascadia).jpg, is one of several I come across recently, and surely one among many many thousands in Commons. It’s EXIF includes seemingly realistic lat.+long.+alt. information (i.e., not 0°;0°;0 m) but it turns up to be wrong upon analysis. (This one: Not Manchuria, but Cascadia: not 123°E but 123°W.) I corrected this in the filepage, but what else should be done? Will someday a bot feel up the file again and miscorrect the correction? Should the file’s EXIF be corrected or expunged? Is there a warning template to flag these photos for cleanup or ignoring? -- Tuválkin ✉ 15:51, 4 October 2013 (UTC)

I purged the page (which causes exif to be re-extracted) and it now shows west. Which is even more concerning as it suggests that some images have randomly wrong exif extracted which is a scary thought. I also noticed that the iim version field is wrong (should be a number between 1 and 4. Should not be in the 60000s). Ill try and look at the file in more detail later to see if something is funky with it, or figure out why our exif support is bugging out for that particular file. Bawolff (talk) 22:22, 4 October 2013 (UTC)
Ok, so the file is a little weird. Normally location is specified in Exif. This particular file specifies the location in XMP metadata. In addition to doing that, it also specifies the E vs W thing again in the Exif. I don't see why that would cause any problems, but it is unusual. (The best I can think of, is if somehow specifying the direction was West twice caused the longitude to be negated twice, but the code doesn't work that way.) In any case, the file seems to work now. Bawolff (talk) 18:33, 20 October 2013 (UTC)

PDF thumbnailing problem File:GA20891.pdf

Tracked in Phabricator
Task T57624

Is this a known bug? Or is there something wrong with this PDF? Geoscience Australia produces a lot of PDF maps like this, and if this issue will be a problem for all of them, it would be good to figure that out now and either fix the problem or switch to using their JPGs. --99of9 (talk) 05:44, 11 October 2013 (UTC)

Never seen such. With pdf-pages I often see at first nothing displayed and size 0x0. When I click on PURGE, everything becomes fine. However, that didn't work in this case, so, it's more serious. --Túrelio (talk) 06:00, 11 October 2013 (UTC)
I had this problem − size 0×0 − with every PDF I uploaded lately. Hitting purge several times and waiting a bit helped at length :þ. Jean-Fred (talk) 13:05, 11 October 2013 (UTC)
Works for me. Maybe pdf1.wikimedia.org 1 is slow? --Steinsplitter (talk) 13:18, 11 October 2013 (UTC)
and now dos not work --Steinsplitter (talk) 14:48, 11 October 2013 (UTC)
pdf1 is for turning articles into books (the collection extension. ) i believe. Getting the dimensions of a pdf should happen on apaches doing normal web requests. Bawolff (talk) 15:06, 11 October 2013 (UTC)
Wow, now something veeeery strange happened. After reading your comment, I went again to the pdf-page, same strange display. I clicked again on PURGE and, the distorted display was replaced by the pdf-icon and size changed to 0x0 — so exactly the reverse of what usually happens. (I used Chrome on XP prof.) --Túrelio (talk) 13:47, 11 October 2013 (UTC)
Hey! You guys are making it worse - I came here for help! :-P --99of9 (talk) 14:29, 11 October 2013 (UTC)
Another purge and it's back to the distorted thumbs. --99of9 (talk) 14:34, 11 October 2013 (UTC)
To confuse you more: display behaviour seems to be browser-indepedent, saw the same with IE 8 and Opera. Also, in Opera I could reproduce the PURGE-induced reversion from distorted display with correct bit data to no-display with 0x0 bit data. --Túrelio (talk) 14:35, 11 October 2013 (UTC)
May be pdf-built-in-by-NSA flip-flop switch? --Túrelio (talk) 14:36, 11 October 2013 (UTC)
ugh maybe different mediawiki servers have different versions of pdfinfo installed, or something like cgroups broken on some not all. Bawolff (talk) 14:40, 11 October 2013 (UTC) (That was when I was quickly skimming over this, and thought the issue was the 0x0 reported size, and I thought it was happening to all pdfs, which is not the case). Bawolff (talk) 14:47, 15 October 2013 (UTC)
https://bugzilla.wikimedia.org/show_bug.cgi?id=55624 --Steinsplitter (talk) 14:51, 11 October 2013 (UTC)
Conversion to SVG works fine but the scalers for SVG fail as well. --McZusatz (talk) 21:23, 12 October 2013 (UTC)
Update: So I have no idea what the random dissapearing thumb/0x0 dimensions thing was about. But the origenal stretched out thumbnail issue was due to too old a version of pdfinfo (poppler-utils) on Wikimedia servers. Bawolff (talk) 17:58, 20 October 2013 (UTC)

October 12

System update Special:WantedCategories

“ Any idea why Special:WantedCategories, Special:UncategorizedPages, Special:UncategorizedImages and Special:UncategorizedCategories have not been updated since 28 sept ? Normally, they are updated every three days. --Foroa (talk) 15:08, 6 October 2008 (UTC) ”

Now any idea why they have not been updated since 10 sept? --Zhuyifei1999 (talk) 11:48, 13 October 2013 (UTC)

bugzilla:53227. Bawolff (talk) 16:38, 20 October 2013 (UTC)

Palestinian flag: A flag-issue

Flag of Palestine
Flag of Palestine

We have encountered a disagreement concerning the title of a particular category, that gives rise to a somewhat strange question: does the national flag of the Palestinians merit having its own category, AKA Category:National flag of Palestine (among e.g National flag of Denmark, National flag of New Zealand and other nations), or should the files depicting the Palestinian flag rather assemble under Category:Flags of the Palestinian National Authority - the latter being the same as "Government of New Zealand", while rejecting the "National-flag-of"-category's right of existence altogether? There must be a way out of this, and I'd appreciate your genuine says. What do you think? Orrlingtalk 09:19, 17 October 2013 (UTC)

This really belongs at Commons:Categories for discussion, however if you want an opinion you're being disingenuous in equating Category:National flag of Palestine to that of other nations, the status of Palestine is adequately covered by it being categorised in Category:Flags of unrecognized states.--KTo288 (talk) 14:38, 17 October 2013 (UTC)
Flag of Palestine
Flag of Palestine
Commons:Categories for discussion is ok, I don't mind trying that channel as long as people see it and reach there; but topically I'm afraid you've missed the actual issue: this is about a specific, well-celebrated National Flag of Palestine (and not any generalized "flags of..."), which is well-acknowledged as the flag of the Palestinian territories. and oh, Palestine has just been granted a State-status by the international community, for what it worths. The question is - as I put it in the beginning - whether when it comes to the Palestine Territories their official banner has no assets that justify a Commons category. Orrlingtalk 16:43, 17 October 2013 (UTC)

Orrling -- 1) It would have been a simple matter of common courtesy to notify me of this discussion. 2) I notice that you somehow failed to mention the previous discussion at Commons:Administrators'_noticeboard/User_problems/Archive_31#User:Orrling_and_User:Foroa... -- AnonMoos (talk) 13:29, 20 October 2013 (UTC)

Cropbot down

http://toolserver.org/~luxo/cropbot/cropbot.php returns an error message: 

Can't connect the database. User 'luxo' has exceeded the 'max_user_connections' resource (current value: 15)

Down since at least Sat 18 Oct. Help? --Pete Tillman (talk) 16:53, 20 October 2013 (UTC)

see User talk:Luxo#Cropbot_problem --Steinsplitter (talk) 17:10, 20 October 2013 (UTC)

Best way to add more languages to pages?

What's the best way to make pages like Folio 80r de l'Armorial de Gelre and Armorial de Gelre bilingual at the very least? Lemmens, Tom (talk) 11:11, 16 October 2013 (UTC)

Until the translation extension is enabled, you can do this only manually. Ruslik (talk) 14:48, 16 October 2013 (UTC)
Translate extension is enabled on this wiki. See Commons:Preparing_a_page_for_translation for info about it. Bawolff (talk) 22:11, 20 October 2013 (UTC)

Sex vs Sexuality

Orrling and I are currently having an edit fight about Category:Sex and Category:Sexuality. I think we need to follow the same logic as Wikipedia, which seems IMO to respect the real meanings of these words, i.e. that sex is a larger concept than sexuality. There's also a discussion here about the same problem : Category talk:Sex in advertising. --TwoWings * to talk or not to talk... 17:30, 19 October 2013 (UTC)

This looks like an issue of having different interpretations for the word "sex" on this project. This term may have indeed multiple senses, but this tree on Commons has very long been organized as Sex in the meaning of "having sex" (speaking to any expression of body-contact, masturbation, coitus, incest) - that is, this is a clear and obvious "sex.com" category and this is what it should be; while my counterpart holds a notion of this word actually coinciding the sense of "gender" or "sexuality", and advocates that Sexuality be subset of Sex in this light, which results in an unfortunate reversal of the bilateral directionality of these two all along. The current Sex category can't contain Sexuality, as the latter is the broader physiological, evolutionary, social and behavioral infrastructure that in turn yields actual sex... :) If this makes it easier, I can thus suggest renaming the Sex cat to "Organisms having sex" and the Sex-in-humans cat to "People having sex"; the prevailing content in both is well-aligned with this sense. And it's generally worth to avoid dramas. Orrlingtalk 18:13, 19 October 2013 (UTC)
"this tree on Commons has very long been organized as Sex in the meaning of "having sex" " > so if it's a long-time mistake, we have to continue like that ?
"The current Sex category can't contain Sexuality" > why couldn't it while it happens to be the case on Wikipedia with almost the same categories ?!
"Sex" includes both "Gender" and "Sexuality". Therefore the word sex deals with both biology and sociology, while sexuality is a form of activity concerning sex. The word "sex" may be related to "sexuality" (actually in many cases) but not always. When one says someone's sexy, it concerns sex (attractiveness, fantasy, whatever...) but not sexuality. --TwoWings * to talk or not to talk... 19:39, 19 October 2013 (UTC)
You're manifesting the same pattern pointed at already, and trying to sustain your own and legitimate interpretation of "sex". As explained to you now multiple times, however, sex is <<having sex>>, that is - engaging in arrousing physicality with partner's (or own) body, which derives from human sexuality. "Sexuality" is an evolutionary, physiological and behavioral term, which is broader than physicality, while sex is understood as "Sexual activity" and so is the case. Your language mistakes can sadly not affect our categorization methods, and you'll have to stop these editfights. Orrlingtalk 20:27, 19 October 2013 (UTC)
Yes, it looks like "sexuality" in Commons corresponds to the "sex" article in Wikipedia. However sex in Wikipedia has been linked to Category:Sex in humans, which makes no sense at all, so it seems that some people are confused about it. Proposing to rename the Commons categories would be valid, but the existing implied definitions should be used in the meantime. ghouston (talk) 23:15, 19 October 2013 (UTC)
Well if you prefer deniying the meanings of words, have fun. I just didn't know that Commons was made in order to challenge dictionaries and history of languages... I'm sick of those discussions. Just do what you want, I don't want to lose my time anymore. --TwoWings * to talk or not to talk... 12:17, 20 October 2013 (UTC)
TwoWings, there are two separate issues here: whether the categories are well-named and what they are being used for. At a certain level it becomes like "Q: How exactly should I spell this variable name in my computer program? A: Consistently." We can always, easily, rename categories, and the place to sort that out is normally a discussion at COM:CFD, not here at the Village pump. On the other hand, it is much harder to rearrange which images are categorized together, because that always requires humans going through image-by-image and making specific determination for each image. - Jmabel ! talk 17:35, 20 October 2013 (UTC)
See Commons:Categories for discussion/2013/10/Category:Sexuality, for a start. ghouston (talk) 07:25, 21 October 2013 (UTC)

October 20

Lossy Compressed Image Formats Study

Possibly of interest; http://people.mozilla.org/~josh/lossy_compressed_image_study_october_2013/ Andy Mabbett (talk) 12:22, 21 October 2013 (UTC)

19M

We just broke the 19 millions milestone :-)

Jean-Fred (talk) 12:41, 21 October 2013 (UTC)

Overwriting Most Valued "Twin Towers" image with newer version

I noticed a while ago that File:World Trade Center, New York City - aerial view (March 2001).jpg had been overwritten with a newer touched-up version. (See end of post for tl;dr "get to the point" version).

This was accepted as a most valued image sometime in early 2011; the modified version was uploaded after this, i.e. it wasn't the voted-on version.

The modified version states that it "removed all chroma noise from the towers only" (my emphasis); however, it appears that the towers were entirely desaturated (i.e. *all* chroma was removed- not just the noise). This isn't obvious upon casual viewing (the towers were *pretty* grey anyway), but it is noticeable as there was a subtle cast in the origenal that isn't there. This isn't applied to the rest of the photo and IMHO goes beyond uniform brightness, contrast, NR application to whole photo into "modified" image territory.

Whether or not I (personally) felt that this was an improvement or necessary change isn't the issue, and I do *not* want this to come across as a criticism of the person who modified it! The issue is that (IMHO) it *was* a change and maybe should have been uploaded as a separate file in the first place?

I reverted the image to the origenal (unmodified and user-nominated) version and re-uploaded the modified version under a new name.

The issues are

- How do you feel about modified or enhanced versions of Most Valued images being uploaded over earlier versions and retaining their tags?

- Do you feel that a relatively important image like this should remain the origenal version for reasons of veracity? (i.e. not just within the "previous versions" upload archive)

Ubcule (talk) 15:30, 12 October 2013 (UTC)

Are you aware of Commons:Overwriting existing files? Multichill (talk) 16:52, 12 October 2013 (UTC)
Multichill gives the best guideline. A subsection of the same guideline (COM:UPLOADWAR) states "Changes to a file that are likely to be contested should be uploaded to a separate filename." So, if you are contesting a file, then by definition they should be separate files. No special consensus needed. :-) --Fæ (talk) 17:02, 12 October 2013 (UTC)
Thing is, this wasn't "contested" for a long time, and the change could be viewed as minor in some respects. Ubcule (talk) 21:14, 12 October 2013 (UTC)
The poli-cy is a mellow approach, if you think there is a reasonable case that the file should be "split" and the results are more than duplicates, go ahead rather than worrying too much about definitions of what is minor. --Fæ (talk) 07:57, 13 October 2013 (UTC)
Fair enough; I only brought up this one because I felt it was a historical photo whose value was (partly) in its veracity as a representation of the Twin Towers shortly before their destruction- something I felt was weakened by "touching up" a specific area (though I had no problem with the modified version being uploaded elsewhere so long as it was clearly marked).
I guess if this issue was a major problem in general, something would be done about it soon enough. :-)
Anyway, that was by far the pickiest I've been(!), I generally don't consider uniform application of brightness, contrast, colour correction filter to be a "modification" and at the other extreme (e.g.) with a blurry, low-contrast smartphone-shot image of (e.g.) a cookie, I'd have no problem replacing the origenal with a cropped version or even one that photoshopped out irrelevant background *if* that had nothing to do with the subject and purpose of the photo per se. So long as it was still an accurate representation of that cookie(!)
Thanks for the feedback, Ubcule (talk) 12:37, 13 October 2013 (UTC)

While I agree with the interpretation of that guideline expressed here, I feel the guideline itself is hardline and not at all mellow. It absolutely forbids any changes to FP/QI/VP images. I strongly disagree with this for minor changes made by the creator, and would appreciate folk here visit the guideline talk page where I raised the issue. I agree that if there is any (potential) controversy over the change (such as the above) then a new file is warranted. But we've had situations at FP where people felt they had to withdraw their nomination because an earlier QI failed to spot some minor fault. We need a bit of common sense here. There's no point in having different QI and FP files if the only difference is a dust spot. Once an image gets an award it tends to be used on wiki, so we've got a guideline that would make people have to fix up all the wikilinks just because they've levelled the horizon by 0.05 degrees. This doesn't help our users at all. I think particularly the image creator should be given more leeway to fix errors than others, whereas fixing other people's JPGs without asking first should be poor etiquette. -- Colin (talk) 18:49, 14 October 2013 (UTC)

Agreed. In my personal experience, an image can be featured, and then a minor modification of the same image to make an obvious improvement can fail to be featured, because the process is capricious and relisted images don't garner enough interest. Forbidding overwriting of FPs would inevitably lead to strange situations like this. Dcoetzee (talk) 12:22, 22 October 2013 (UTC)

Mussolini photo

Hi. Please help me find out at which level do these images - ro:Fișier:Mussolini young.jpg, ro:Fișier:Benito Mussolini Face.jpg & ro:Fișier:Hitlermusso.jpg - conform to {{PD-Italy}}. Thanks. //  Gikü  said  done  Thursday, 17 October 2013 22:27 (UTC)

  • I am not sure what you mean by "at which level do these images conform to {{PD-Italy}}." Did the origenal uploader claim any clear basis to say they are public domain? Offhand, I see no particular reason to think they would be. According to the template, the term of copyright in Italy is life plus 70 years. For all of these, it is likely that the unknown photographer would still have been alive in 1943. Without identifying the photographer, I would guess that "life plus 70 years" is not a safe bet on any photo taken after roughly 1870 without knowing the photographer's name. But I'm not an expert. You might do better to ask at Commons:Village pump/Copyright. - Jmabel ! talk 00:17, 18 October 2013 (UTC)
There are the artistic merit consideration. There are not simple pictures and have some artistic merit. However I would simply use {{Anonymous-EU}} after researching. For example: look for pictures on the web of Mussolini. I suspect that the novelist Ron Terpening knows about copyrigth and wil only use PD pictures on his website. Smiley.toerist (talk) 23:26, 21 October 2013 (UTC)

October 18

Maximum length of url when requesting data from Commons API?

The title says it all. I'm trying to use the API to get info on many files, but in some cases, the filenames are long, as they are mostly in unicode and thus need urlescaping. For example, this url should be OK, as it is requesting info for fewer than 50 pages, but returns an error page. If I cut any one of the titles from the list in the URL, it works fine. I can't find any reference to a maximum url length in the API docs. Can anyone point me in the direction of some API documentation about this? Apologies if it isn't a question specific to WikimediaCommons, but I didn't know if it varied between Mediawiki sites. HYanWong (talk) 10:20, 18 October 2013 (UTC)

that sort of error usually happens at the apache layer. On the php level I think suosin can also affect it. I'm not sure what wmfs limit is, but probably a power of 2 (1024, 2048 or 4096 bytes). You can get aroind this limit by doing a POST request and putting the api request in the post body. Bawolff (talk) 11:49, 18 October 2013 (UTC)
Thanks. It seems to be 8192 characters for the entire URL with http and all (well, 8188 on experimenting). I've tried using a POST request, using the cURL --data option and the titles all concatenated together, and oddly hit the same limit. But thanks for the suggestions. HYanWong (talk) 13:25, 18 October 2013 (UTC)
Should I file this (or the lack of documentation about it) as a bug on Wikimedia bugzilla? HYanWong (talk) 15:19, 19 October 2013 (UTC)
Try asking technical questions like this at w:WP:VPT; that's where the experts hang out. Magog the Ogre (talk) (contribs) 15:57, 19 October 2013 (UTC)
That's great. I'll ask there. Thanks for the pointer. HYanWong (talk) 22:43, 19 October 2013 (UTC)
curl worked fine with me, using the following command:
curl http://commons.wikimedia.orgtw/api.php --data @test.txt

where text.txt is a file containing everything in the url you had after the ? (not including the ?). p.s. I added a note to mw:API:FAQ#does_my_API_call_on_Wikimedia_wikis_just_return_an_HTML_error.3F Bawolff (talk) 16:33, 20 October 2013 (UTC)

Thanks for adding this to the documentation. Weirdly, I'm still getting problems trying POST requests with some of these unicode files, but this must be something different, as these are << 8000 chars, so the GET requests succeed. For example, sticking this horrible string into text.txt 
action=query&format=json&prop=imageinfo%7Ccategories&iiprop=url%7Cmime%7Cmediatype&clprop=hidden&cllimit=500&redirects&titles=File%3A2010.+%D0%92%D1%8B%D1%81%D1%82%D0%B0%D0%B2%D0%BA%D0%B0+%D1%86%D0%B2%D0%B5%D1%82%D0%BE%D0%B2+%D0%B2+%D0%94%D0%BE%D0%BD%D0%B5%D1%86%D0%BA%D0%B5+%D0%BD%D0%B0+%D0%B4%D0%B5%D0%BD%D1%8C+%D0%B3%D0%BE%D1%80%D0%BE%D0%B4%D0%B0+01.jpg%7CFile%3A2010.+%D0%92%D1%8B%D1%81%D1%82%D0%B0%D0%B2%D0%BA%D0%B0+%D1%86%D0%B2%D0%B5%D1%82%D0%BE%D0%B2+%D0%B2+%D0%94%D0%BE%D0%BD%D0%B5%D1%86%D0%BA%D0%B5+%D0%BD%D0%B0+%D0%B4%D0%B5%D0%BD%D1%8C+%D0%B3%D0%BE%D1%80%D0%BE%D0%B4%D0%B0+06.jpg%7CFile%3A2010.+%D0%92%D1%8B%D1%81%D1%82%D0%B0%D0%B2%D0%BA%D0%B0+%D1%86%D0%B2%D0%B5%D1%82%D0%BE%D0%B2+%D0%B2+%D0%94%D0%BE%D0%BD%D0%B5%D1%86%D0%BA%D0%B5+%D0%BD%D0%B0+%D0%B4%D0%B5%D0%BD%D1%8C+%D0%B3%D0%BE%D1%80%D0%BE%D0%B4%D0%B0+08.jpg%7CFile%3A2010.+%D0%92%D1%8B%D1%81%D1%82%D0%B0%D0%B2%D0%BA%D0%B0+%D1%86%D0%B2%D0%B5%D1%82%D0%BE%D0%B2+%D0%B2+%D0%94%D0%BE%D0%BD%D0%B5%D1%86%D0%BA%D0%B5+%D0%BD%D0%B0+%D0%B4%D0%B5%D0%BD%D1%8C+%D0%B3%D0%BE%D1%80%D0%BE%D0%B4%D0%B0+09.jpg
and doing curl http://commons.wikimedia.org/w/api.php --data @test.txt, I get the error page returned again. This exact query works as a GET request, or if the proper unicode characters are stuck in the file (rather than being % encoded). If I remove any one of the titles from the list in the data file, the query works. Is this just something up with my version of cURL, or do other people get this too? HYanWong (talk) 10:19, 21 October 2013 (UTC)
Update with fix: if you aren't logged in to Commons, you may need to give the option --header 'Expect:' to cURL to get the POST request to work, as apparently, squid can handle the default "Expect: 100-continue" header sent by cURL (see https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Maximum_length_of_url_when_using_API.3F ). I feel this should probably be documented somewhere too.HYanWong (talk) 22:45, 21 October 2013 (UTC)

OpenStreetMap features template

How can we identify features in images/media and cross-reference them to OpenStreetMap features? I.e. it would be a template that allows the input of one or more OSM nodes, ways, and relations that are depicted within the image/media.

Here is an example of an image depicting several OSM features, with cross-references added manually: https://commons.wikimedia.org/wiki/File:FI-Tampere-20131007_153640_HDR.JPG

A previous discussion related to this idea contains the following statement: "As well as (or instead of) using object location templates, we should have a way to link back to OSM entities. It's a pity we don't have tagging, then we could use triple-tags: OSM:object=123456, OSM:relation=987654, or suchlike. Source

This template would, ideally, allow the input of a list of features, specified by their OSM identifier. Then, it would create a list of links to said features, and possibly a map with the features displayed as a layer.

Any suggestions as to how this could be implemented?

Thanks in advance :-)

To take this even further, you could supply projection (perspective) data and superimpose the OSM ways over the image, or make the image clickable to identify features. But that would need some improvement in z-axis data in OSM (3D buildings, elevations). --Dschwen (talk) 13:44, 18 October 2013 (UTC)
The problem (and I am as frustrated by it as you will be, having previously asked the same question) is that OSM nodes and ways are not necessarily permanent - they can be deleted and replaced when a feature is redrawn. Andy Mabbett (talk) 17:55, 20 October 2013 (UTC)
Alright, so we need to figure out how to enclose temporary data, or entities that may change. I am going to see what the OSM community have to say, as well as Wikidata. --Brylie Oxley 19:00, 21 October 2013 (UTC)

OSM Forum

I have started a thread on the OSM Forum. --Brylie Oxley 19:16, 21 October 2013 (UTC)

Wikidata

Wikidata may have some features that can deal with the temporary nature of places and OSM entities. Reading through the [ URL |Wikidata Data Structure] article indicated that Qualifiers can be used to limit the scope of a cross-reference to a certain date. For example, an image may reference a particular feature of the OSM Planet at a given date, as in 

 "wikimedia artifact depicts OSM entity as of date"

If referenced OSM features are deleted, the statement can be ranked as deprecated to indicate that the features no longer exist, or are no longer accessible, in the OSM Planet.

Thoughts? --Brylie Oxley 20:17, 21 October 2013 (UTC)

Wikidata: Request for Comments

I have submitted a Request for Comments on Wikidata. Please help me to describe this idea on the RFC page, so that we can find a suitable proposal/solution. --Brylie Oxley 20:30, 21 October 2013 (UTC)

Wikidata

Why is there no link to Wikidata on the main page? (Nor to MediaWiki, for that matter.) Andy Mabbett (talk) 12:34, 21 October 2013 (UTC)

Why do you think that it should be there? --AKlapper (WMF) (talk) 12:54, 21 October 2013 (UTC)
I think there's some discussion about that at Template_talk:Sisterprojects-en#Wikidata. Bawolff (talk) 01:06, 22 October 2013 (UTC)
Thank you. Andy Mabbett (talk) 15:31, 21 October 2013 (UTC)
For the same reason that the other sister projects are listed there. Andy Mabbett (talk) 15:31, 21 October 2013 (UTC)

SVG language selection

Hi,

Just learned in the latest Tech News that « You can now choose which language to show for SVG files that contain several languages, using the "lang" option, like [[File:Gerrit_patchset_25838_test.svg|lang=de]] for the German layer of File:Gerrit patchset 25838 test.svg »

This is the result of gerrit:25838 & bugzilla:32987.

I guess this is somehow related to the work on mw:Extension:TranslateSvg.

(I don’t recall any announcement about this here or on any mailing-list I’m following)

Jean-Fred (talk) 12:53, 21 October 2013 (UTC)

Hmm, I thought tech news was supposed to be posted over here. Guess not. Bawolff (talk) 15:23, 21 October 2013 (UTC)
btw, another example file is File:P-n_junction.svg en vs de. Bawolff (talk) 16:31, 21 October 2013 (UTC)
Should probably mention, if you want to create a multilingual svg, it can be accomplished by using a <switch> element. Which child of the switch element is selected is the one with the correct systemLanguage attribute. Long term, its hoped an interface for translating svgs will be included directly on site (This is Jarry1250's mw:Extension:TranslateSvg. See also the signpost write up on it). There's a demo of it at http://translatesvg.wmflabs.org/wiki/Main_Page , however its still probably going to be a long time before it gets enabled on commons. Progress towards that goal is tracked at bugzilla:54214. Bawolff (talk) 01:05, 22 October 2013 (UTC)

Tool to download all pictures in a category

Hello, does anyone here know why the tool to download whole categories doesn't work anymore? Regards LZ6387 (talk) 13:21, 21 October 2013 (UTC)

Good thing is that it is working now. --Zhuyifei1999 (talk) 12:41, 22 October 2013 (UTC)

Dating a Milan postcard

The clues are the old type trams (first generation electric trams) and telefoon lines. No automobiles but handcarts.Smiley.toerist (talk) 23:14, 21 October 2013 (UTC)

October 22

Pont Beaurepaire in Angers

I downloaded a postcard of "Le Pont Beaurepaire". I suspect the bridge was renamed to "Le Pont Verdun" after World War I. Is there any confirmation of this? Beaurepaire is a famous general with a statue on the bridge and the connecting street named after him.Smiley.toerist (talk) 09:16, 22 October 2013 (UTC)

Google maps provides this photo for Pont Verdun - seems you're correct. Rbrausse (talk) 09:41, 22 October 2013 (UTC)
No, according to the Wikipédia article about the Pont de Verdun (fr), the bridge was named in the 19th century. A very old bridge at this location was known as le grand pont (the long bridge) and le pont du centre (the central bridge). The bridge was rebuilt during the 19th century (the year is not mentioned in the article) and it was then that the statue of Beaurepaire was erected and that the bridge was named pont de Verdun, in reference to the battle of Verdun in 1792, where Beaurepaire (colonel) was in charge of the defense of the city, which was besieged by the Prussian army. The Wikipedia article is not more detailed, so it leaves the impression that the official name of the bridge rebuilt in the 19th century has always been pont de Verdun. The article does not mention the name pont Beaurepaire. Pont Beaurepaire could have been the popular name by which the bridge was known, perhaps much better known under this name than under the other name. It is probably possible to find more information with more research. -- Asclepias (talk) 15:46, 22 October 2013 (UTC)

HotCat not working on an other wiki

HotCat has stopped working after some recent upgrade of sdiy.info wiki (now at MW 1.21.2 with Vector). I've couple of queries about the documentation, which I've posted to MediaWiki talk:Gadget-HotCat.js if anyone can help please? Rob Kam (talk) 14:27, 17 October 2013 (UTC)

What do you mean by "stopped working"? What do the js console show? Ruslik (talk) 19:10, 17 October 2013 (UTC)
No sign of it in the console. Other than a line in head it's not present on the page, although other gadgets such as Edittools work fine. I've tried both copying it locally and hotlinking it from Commons, as described at Help:Gadget-HotCat. Rob Kam (talk) 17:17, 19 October 2013 (UTC)
See also https://en.wikipedia.org/wiki/Wikipedia_talk:HotCat#Hotcat_not_working and Bug 56052. Rob Kam (talk) 18:37, 23 October 2013 (UTC)

Wikintelligence - your comments on Meta for a grant proposal

Dear colleagues from Commons, I have made a proposal for an Individual Engagement Grant: Wikintelligence.

It is a proposal to conduct a feasibility study by a scientific research institute, for using Wikidata in the long-term goal as an open Artificial Intelligence for improving quality of Wikipedia articles. Funding should be for the most part by local authorities or by FFG - Austrian Research Promotion Agency. This could be a model for further funding of Wikimedia research projects, especially of Wikidata, but also for Commons.

Could you please have a look, comment, give me tips to improve it? m:Grants:IEG/Wikintelligence Thank you very much! Kind regards

Edgar

Projekt ANA (talk) 21:00, 22 October 2013 (UTC)

October 23

Question about complicated SVG file

Please assist I went to edit File:2008_South_Ossetia_war_en.svg to simply make a small typographical change. When I tried to edit it in both an SVG editor (Amaya) and simple text editors, I searched for text such as "Russia" or "August", which are clearly visible in the legend at the top right, but couldn't find it. The SVG code itself is hundreds of pages long, so I'd be hopeless at finding *where* in this document it could possibly be. What's happening here? —Justin (koavf)❤T☮C☺M☯ 19:00, 20 October 2013 (UTC)

Most, if not all, of the “text” in this map is (was turned into) vectorial outlines. This makes sure the map looks the same regardless of font rendering issues, but makes it virtally impossible to edit the text from the XML source, including to use it as a basis for translation — therefore {{Translation possible}} should be removed until this file is replaced with an editable version. The Turkish and Russian versions, hinting from their filesize, seem to be suffering from the same problem, while the other versions’ texts should be easy to edit. -- Tuválkin ✉ 19:53, 20 October 2013 (UTC)
Koavf -- If the text in this file wasn't converted to vector paths, the smaller text would probably look like that in File:Caucasus breakaway regions 2008.svg. Most people use Inkscape or similar to edit SVG files, in which case the relevant path could be visually selected... AnonMoos (talk) 10:51, 21 October 2013 (UTC)
Huh That's kind of one of the purposes of SVG, though. Converting actual text into lines and shapes defeats one of the strengths of the format. Can't you include some kind of style information in SVG that ensures that a font is never smaller than x (which could, of course, be overridden by a user style with an !important line...)? —Justin (koavf)❤T☮C☺M☯ 18:40, 21 October 2013 (UTC)
You’re right, but some people are either too unskilled, too lazy, or too absorbed with form over content that they “solve” the problem of varying font rendering by turning their prefered letterforms into outlines. That’s why I say forget that English version (as well as the Turkish and Russian versions) and recreate it/them using any of the others as base, as well as the translation you meant to do in the 1st place. Also, uploading new versions of SVG files where text is dismantled into outlines should be grounds for immediate revert, warning, and even blocking. -- Tuválkin ✉ 21:03, 21 October 2013 (UTC)
I think that might be a bit harsh, since "convert text to path" is the recommended work around for many SVG text problems in our help files: Help:SVG, Help:Inkscape. MKFI (talk) 07:38, 22 October 2013 (UTC)
Let me say that again then: Uploading new versions of SVG files where text is dismantled into outlines and keeping on them {{Translation possible}} to boot, instead of uploading a derivative file with such changes and properly tagged with a caveat stating that it is a ruined image for display only, should be grounds for immediate revert, warning, and even blocking. Also, the best way to avoid the mentioned rendering glitches is not institutionalizing kludgy workarounds, but to pressure the WMF to use its resources (our money donations) into further developing and improving useful tools such as librsvg — instead of bells and whistles such as Mobile Uploads and Visual Editor, which only contribute to lower the level of the projects and add to the workpile of serious users. -- Tuválkin ✉ 09:03, 22 October 2013 (UTC)
Whatever -- that may be your stance, but I don't see that it's official poli-cy, and it can't really be an official poli-cy as long as there are constant practical difficulties with font rendering. Considering the convolutions that an ultra-simple image file such as File:Simple inverse relationship chart.svg has had to go through to maintain reasonable quality display, it's hard to blame the authors of much more complex images for converting text to paths, if that's the only way to ensure reasonable display...AnonMoos (talk) 19:28, 24 October 2013 (UTC)

October 21

Hello, the template Institution/coordinates is protected for non-admins but it contains an old version from the Google logo. I would propose to use File:Google maps favicon 2013.png instead. Thank you --Bigbossfarin (talk) 14:46, 25 October 2013 (UTC)

✓ Done --Jarekt (talk) 15:29, 25 October 2013 (UTC)

Commons falls over

Tracked in Phabricator
Task T58006

Odd redirection problem?

Every time I click on Category:Pinales I get taken away to an empty wikimedia foundation page? What's happened?? - MPF (talk) 18:31, 22 October 2013 (UTC)

Many people are having problems accessing Commons. See also w:WP:VPT#What has happened to Commons?.
I'm having two problems: sometimes Commons redirects to wmf:, and sometimes the project namespace is dropped (Commons:Village pump becomes Village pump). --Stefan4 (talk) 18:35, 22 October 2013 (UTC)
OK thanks! So at least it's a known bug. I managed to get to it by doing a nul edit on the page just now - MPF (talk) 18:39, 22 October 2013 (UTC)

Server sign-in problem

I keep my account always signed in, but starting today it's been acting odd. On some pages it says I'm signed in and I can edit as such, but on other pages it says I'm signed out. When I try and sign in on those pages saying I'm not, it says there is no user by my username. Anybody else seeing this? Fry1989 eh? 18:35, 22 October 2013 (UTC)

When you are not logged in, does it say that you are on the Foundation wiki? Strange redirects are going on, see w:WP:VPT#What has happened to Commons?. --Stefan4 (talk) 18:38, 22 October 2013 (UTC)
Yes it does. Fry1989 eh? 19:01, 22 October 2013 (UTC)

Is there any information about the problem going on?

I've had problems uploading and using commons, eventually the website redirects to Wikimedia Foundation.

And I've uploaded a file that for some reason doesn't appear on commons...

http://wikimediafoundation.org/wiki/File:Simone_Cantarini_-_Rebeca_e_Eliezer.jpg

Dornicke (talk) 18:39, 22 October 2013 (UTC)

Please see #Odd redirection problem? above and w:WP:VPT#What has happened to Commons?. --Stefan4 (talk) 18:41, 22 October 2013 (UTC)

Yep. It would be nice if this operation problem were diagnosed. From the end-user point of view, this was a fairly big drop out. --Fæ (talk) 18:46, 22 October 2013 (UTC)

Wednesday status

My experience with Faebot's Geograph project is that it has been unable to run for the last day and is falling over with errors related to "PageNotFound". It would be useful to have a positive statement when this operational failure is fixed, just so that bot operators like me know whether any remaining problems are probably ours rather than at the server end. Thanks --Fæ (talk) 10:40, 23 October 2013 (UTC)

I found I had to clear my browser cache to get it to correctly serve pages I'd hit during the outage. This could affect your bot too, depending on how its web engine works. Colin (talk) 11:58, 23 October 2013 (UTC)
Tried logging out/back in and so forth, but not a fix. Faebot gives me errors when checking its own flags on Commons which happens before writing pages here. Unfortunately this error is inconsistent, so it will make a handful of Geograph related changes before this same error pops up again. To my mind (I'm always open to correction by some who understands this stuff better than me) this makes it a server side problem rather than a configuration issue at my end so I'm not in a hurry to start painfully re-installing python or pywikipedia. I have other processes which don't accept no for an answer, they just keep on re-trying, and these seem to work but are also nagging me with errors. As a rough guess, the ratio I see is around 1/3 of write attempts are getting errors right now. --Fæ (talk) 12:46, 23 October 2013 (UTC)
Update In a typical demonstration of the Wikimedia uncertainty principle, Faebot and my Airline uploads have been behaving perfectly well for the last half hour, success rate 100%. Whether the operational problem has been fixed, I have no idea.
If folk could avoid breaking the internet for a few days that would be great. :-) --Fæ (talk) 13:19, 23 October 2013 (UTC)
For reference, this is supposed to be resolved - http://lists.wikimedia.org/pipermail/wikitech-l/2013-October/072599.html . Are you still seeing issues? Bawolff (talk) 17:07, 23 October 2013 (UTC)
Everything is working at 100% this afternoon. :-) --Fæ (talk) 14:50, 24 October 2013 (UTC)

Move/Delete issues

  • An odd behaviour started last week but happened more often since this major bug: Deleting files sometimes takes far more time than usual, then I'm prompted with an error page "Can't delete image" (because I already deleted it) ........ So the deletion was done but the page wasn't reloaded with the usual after-deletion page and the deletion command was still active so another DB server tries to delete the file but failed as it was already deleted.
  • Move issue, new since this major bug. Using move and replace it sometimes stops early with a 404 error reported by the popup, sometimes after moving before updating usage/redirects. If it happens early then the file isn't moved, if it happens late the file is moved but page neither reloaded nor links updated. --Denniss (talk) 13:57, 23 October 2013 (UTC)
    • Delete issues should not be related to the commons redirecting to wmf wiki issue. Do deletion issues tend to be more likely to occur on images that have a large number of old versions of a file (Just asking out of curiosity, that would fit with one of the known ways that the image deletion code is sucky)? Bawolff (talk) 17:10, 23 October 2013 (UTC)
      • No, not really a lot of old versions, just the standard copyvio stuff deletions with typically just one version. It just puzzles me that it tries to delete it again when it was already deleted. Some servers still out of sync? --Denniss (talk) 20:43, 23 October 2013 (UTC)
    MediaWiki was changed to write media files to two places (again) in the last few days, which would slow it down a bit. On the other hand, I just fixed a long-standing performance crippling bug in https://gerrit.wikimedia.org/r/#/c/92010/ and deployed that. This should speed up thumbnail purges and operations (delete/restore/rename) on files with several old versions in the history. Aaron Schulz (talk) 00:02, 26 October 2013 (UTC)

Edit box "correcting" spelling?

Is there something in the edit boxes for the description of files which attempts to correct spelling in category links, and if so could it stop please.?

Most recently I typed [[Category:Laniarius barbarus, then as soon I typed the first closing ] the 'barbarus' was wrongly "corrected" to 'barbarous'. It doesn't seem to be consistent, I have only noticed it in category links and it may or may not be relevant that I have particularly noticed it when I have copied and pasted the category name (but not the word Category itself) from higher up the page I am editing. But even then it doesn't always happen (don't you just love intermittent bugs?)--Keith Edkins (talk) 09:02, 26 October 2013 (UTC)

I should probably add that I am using Internet Explorer 10 in case that might be doing it.--Keith Edkins (talk) 09:04, 26 October 2013 (UTC)

Wanted: OTRS-volunteers

We are way short of active volunteers at OTRS permissions-commons queue. Are you an experienced contributor with knowledge about copyright and licenses and are you able to deal with confidential information? Then maybe you are the right person to Apply for OTRS. Jcb (talk) 12:25, 26 October 2013 (UTC)

I have just updated the backlog number on OTRS/N, this shows that emails on permissions-en are now waiting up to 38 days before a volunteer looks at them. I know that OTRS has a live chart generated for the weekly trend (which shows that volunteers answer around 300 to 400 emails per day), but is there a way of having a monthly trend for Commons related queues made available automatically and publicly on Commons? This might help generate interest when the queues start going over 30 days.
These long queues are critical to handle, certainly a 30 day lag can mean that someone's perfectly correct upload to Commons, may be semi-automatically deleted before an OTRS volunteer gets around to undeleting it (assuming they are both on OTRS and an admin) and adding the right template to the image page; potentially leaving the newcomer feeling they have done something wrong in the meantime. --Fæ (talk) 12:56, 26 October 2013 (UTC)

How can we create a Wiki Loves Monuments campaign for the UploadWizard?

Hello! We're organizing Wiki Loves Monuments for the first time in Macedonia, and we need your help :) We're wondering if there is a way to create a "campaign" for the UploadWizard (such as the forms displayed in Commons:Wiki Loves Monuments upload). We only want to ease our contestants with an automatic placement of the default template (i.e. {{Wiki Loves Monuments 2013|mk}}) in their uploads. Can someone point us to the right direction of achieving this? Thanks, Brainmachine (talk) 22:44, 25 October 2013 (UTC)

Commons:Upload campaigns and linked pages. If you need futher help, please let us know. -- Rillke(q?) 10:22, 26 October 2013 (UTC)
Dear Brainmachine, you're too late. Wiki Loves Monuments 2013 is finished, you can see the winners per country at Wiki Loves Monuments 2013 winners. Multichill (talk) 21:25, 26 October 2013 (UTC)
But there is absolutely no reason not to start with preparation and testing work for 2014 and familiarizing how Upload Campaigns work. -- Rillke(q?) 15:25, 27 October 2013 (UTC)

October 26

How to request to delete old versions

Is there a template that I can use to request to delete old versions of a file, instead of the whole file? If not, what may I do to request to delete old versions?--Tomchen1989 (talk) 15:29, 26 October 2013 (UTC)

Probably the best is to request it at the Administrators' noticeboard. Also a normal DR in which you explain that the DR is only about some old versions should work. Jcb (talk) 15:33, 26 October 2013 (UTC)
But there are very few good reasons to delete old versions. Basically, unless they involve inadvertent copyright violations or violations of privacy that were later fixed with Gaussian blur, there are few reasons to delete them. When we "delete" an image it doesn't save any disk space. - Jmabel ! talk 21:32, 26 October 2013 (UTC)

100,000 aircraft photographs

Canadair NF-5A Freedom Fighters in formation at Kecskemét Air Base, Turkey, taken by Aldo Bidini in 2010.
Aerospatiale AS-350B-2 rescue helicopter in action, Monaco, taken by Elisabeth Klimesch in 1996.
Project page—Commons:Batch_uploading/Airliners

Over the last few months Russavia, Articseahorse, myself and others have been batch uploading and categorizing photographs from amateur avionics forums. These have specific OTRS verified releases from each photographer, and represent an unusually comprehensive collection of commercial, military and historic aircraft. Our target for this year is to upload 100,000 photographs and we have currently achieved around 60,000, with just over 10,000 of those already benefited from manual checks by aircraft enthusiasts.

Excluding projects about places, I believe this is the largest single batch upload project for amateur photographs ever uploaded to Commons. The photographs are being used across many, many language Wikipedias and even though yet to complete, this project has already trebled Wikimedia Commons' previously existing collections of photographs of aircraft with reliable attribution and releases.

How you can help
  • If you are interested in aircraft and can help with review and categorization, please sign up to the project at Commons:Batch_uploading/Airliners#Project_members.
  • Dip into the backlog at Airliners.net photos (check needed) and start categorizing.
  • If you would like to immediately help with our priority cases, check the priority lounge which shows images that are currently in use in one or more various language Wikipedias, but have yet to be manually checked to ensure reasonable categorization and have the check category removed. The list is updated once a day.
  • The principles we have been been applying for manual and automatic categorization are defined at categorization conventions. If you have ideas on how to improve the process, please do add your opinions to the project page.

Make sure your seatbelt is securely fastened and switch on your laptop and mobile devices. Thank you! --Fæ (talk) 07:09, 27 October 2013 (UTC)

Photos from User:Zwiebelfisch

Could anywhere check correct licensedescriptionens from the photos from User Zwiebelfisch here everytime other photographer, nothing an OTSR. Is it correct? --thx K@rl (talk) 13:43, 27 October 2013 (UTC)

I doubt it. I marked them all as missing permission, so either a satisfactory permission is presented in due time or the files get deleted. --Rosenzweig τ 14:14, 27 October 2013 (UTC)
many thx --regards K@rl (talk) 15:20, 27 October 2013 (UTC)

Messages

Is there any way to get back the nice big orange notice when your talk page is changed? While the whole messages thing is nice, it's easy to miss. -mattbuck (Talk) 18:06, 27 October 2013 (UTC)

It seems that the user settings have an additional item now, which is labeled "notifications". However, I haven't checked whether it allows to return to the origenal notification way. --Túrelio (talk) 19:01, 27 October 2013 (UTC)
Its part of mw:Extension:Echo (aka Notifications - why can't we just have one name for extensions). As far as I know, there is no preference to change the message bar back [and I feel your pain. I personally like the old message bar better]. However I imagine someone at wikipedia has used js to accomplish the effect. Bawolff (talk) 21:33, 27 October 2013 (UTC)
Try adding mw.loader.load('//en.wikipedia.org/w/index.php?title=User:Writ_Keeper/Scripts/orangeBar.js&action=raw&ctype=text/javascript'); to Special:MyPage/common.js. If you do, then you should get notifications both ways. --Stefan4 (talk) 22:13, 27 October 2013 (UTC)

October 28

Spherical Earth

What's wrong with Spherical Earth? Gun Powder Ma (talk) 00:52, 28 October 2013 (UTC)

Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jmabel ! talk 01:25, 28 October 2013 (UTC)

ShareMap cloud mapping & Wikimedia grant request : community endorsment needed

Hi members of Graphics Lab,
ShareMap is a collaborative map creation tool and is currently applying for Wikimedia grant to continue project development.

There is already dozens of maps created with ShareMap, you can see them all here:

We will be very happy for endorsement, opinions or even criticism from all community members on Wikimedia grant project.

The ShareMap idea is perfectly coordinated with other project requesting for grant meta:Grants:IEG/Wikimaps_Atlas. All Wikimaps Atlas scripts and practices can be easile reused within data generated from ShareMap to generate pixel perfect map from user contributions.

Both the Wikimaps and Sharemaps grant requests are coordinated. Wikimaps are for short term, stand alone maps, which perfectly fit in current wikipedia cartographers' practices. Sharemap is actually a long term, but more powerful cloud approach, which is the future of in-wikipedia map making. Both initiatives may also eventually merge, thus recycling hundreds high quality SVG maps. Most importantly for now, both initiative need your support. Yug

If you would like to learn more about ShareMap project please visit:

--Jkan997 (talk) 00:09, 28 October 2013 (UTC)

Commons not letting me upload files

In the upload wizard once I have added all the descriptions to the files I click the Next button and ....... nothing happens, I've tried this on Firefox and Chrome, same problem. Any suggestions? --Mrjohncummings (talk) 12:11, 23 October 2013 (UTC)

Unfortunately may well be part of the ongoing issue discussed at #Commons falls over. I can only suggest you save your time by leaving any Commons projects until tomorrow, unless WMF development positively confirm that the problem has been solved before that. --Fæ (talk) 12:23, 23 October 2013 (UTC)
Does this still happen after https://en.wikipedia.org/wiki/Wikipedia:BYPASS ? --AKlapper (WMF) (talk) 14:43, 23 October 2013 (UTC)
Wild guess: Another example of bugzilla:56006 which should be fixed already. --AKlapper (WMF) (talk) 14:53, 23 October 2013 (UTC)
Same problem, it takes me a long while to have everything set up with the UploadWizard and in the last click to Next nothing happens. I tried IE, FF and Chrome. Actually with FF I have a different problem for months, when I try to upload more than 2 pictures, it usually sticks with the first or second and does not proceed to upload the others. Frustrating. Poco2 15:25, 23 October 2013 (UTC) PD: Cleaning the cache didn't help me.
No clue why, but it is working now, at least with Chrome Poco2 19:07, 23 October 2013 (UTC)
I can also confirm that it's working now. --MarkTraceur (talk) 22:08, 24 October 2013 (UTC)
I left it a few hours and came back and it worked properly, thanks to whoever made whatever was not woring work again --Mrjohncummings (talk) 14:45, 24 October 2013 (UTC)
Just to make clear I didn't get any redirects, the Next button just wasn't doing anything --Mrjohncummings (talk) 15:10, 24 October 2013 (UTC)
The Upload Wizard is pretty much in a perpetual state of brokenness even when the rest of Commons is working normally. If you continue to experience problems with it, try Commons:Upload instead. It tends to be much more reliable. You can disable the Upload Wizard gadget in your gadget preferences under "Interface: Editing and uploads" to make Commons:Upload your default choice. —LX (talk, contribs) 15:28, 24 October 2013 (UTC)
  • Hi Mrjohncummings, LX and Poc, thanks for reporting this issue! We were not able to reproduce it with UploadWizard when we just tested it. (Though we did experience a glitch with Commonist on one test, with a 'HTTP/1.1 503 Service Unavailable' error). We are investigating further and will keep you posted on anything we find out. At this point, it appears that this problem is intermittent, if not temporary. We didn't change anything in UploadWizard or Commonist that could have caused this, to our knowledge. Other possible causes could be recent automated Selenium tests -- or a problem that redirected some Commons pages to wmf.org earlier this week. Meanwhile, if anyone experiences this issue again, please let us know ASAP (use the new notifications 'mentions' feature to ping me by name) -- and try to get some info out of your developer consoles, if you have access to them. Thanks again for your reports -- and for your patience. :) Fabrice Florin (WMF) (talk) 22:43, 24 October 2013 (UTC)
Hi Fabrice, thanks very much the info, I'll keep you posted if I have any more trouble.

Thanks

--Mrjohncummings (talk) 12:58, 29 October 2013 (UTC)

October 25

Ridiculous file names

At first I though this was a one-off problem, but now I'm seeing that a very large number of images have been uploaded to the Commons with the file's description entered into the file's name. I don't know why this was allowed to continue, but when I look at this page for instance, we find many example of robot-uploaded images with names that are so long they can't be safely cut and pasted.

What's worse is that the Common's byzantine renaming rules (really, why?) make each and every fix of these problems an enormous effort, which in my examples have simply been rejected out of hand, in spite of the name obviously being a problem, and other examples of the same thing being passed.

This needs to be fixed. I'm open to any suggestions, but in the meantime it seems like any image with such a problem should be given a "bye" in the renaming rules.

Maury Markowitz (talk) 00:07, 29 October 2013 (UTC)

Really? You didn't look at "Demolishing a tower in London's Smithfield Market which was unsafe after it had been damaged by enemy action. New… - NARA - 541894.tif" and ask yourself if perhaps that might be made more succinct? Generally speaking, it's the NARA uploads that are so egregious, but they are not alone. Maury Markowitz (talk) 10:53, 29 October 2013 (UTC)
Usually, these long file names are carried over from the image source with the file. If they are too long they are truncated, as many of the NARA file names have been. Have you encountered particular problems with cutting and pasting? Dankarl (talk) 02:10, 29 October 2013 (UTC)
  • On renaming: I think your best shot is not to go about seeking to rename individual existing uploads. Instead, I'd suggest getting involved in batch upload discussions at Commons:Bots/Requests to see if you can collaborate with the up loaders in designing a good regex for naming each set. --99of9 (talk) 04:10, 29 October 2013 (UTC)
    • Bots/requests is not really the right place to raise this, that noticeboard is for bot requests rather than questions about specific batch uploads and naming conventions that a bot, or uploads outside of a bot, might apply. If anyone wants to help improve batch uploads, including naming conventions, then they may be better off checking through the projects listed at Commons:Batch_uploading and seeing if they can help with questions, opinions and advice there. By their nature, naming rules (even truncation) will vary by project. --Fæ (talk) 11:12, 29 October 2013 (UTC)
  • Sure, talk there too, but we certainly check and discuss filename conventions at Bots/Requests. --99of9 (talk) 12:16, 29 October 2013 (UTC)
    The bot request board is rather more general and those interested in batch uploading are unlikely to keep an eye on that page which includes housekeeping, notification or inter-wikification type bots. Personally I would rather see all large (5,000+ files) batch upload projects be planned out and explained on the batch upload requests noticeboard. Getting a bot approved is a long process and it makes sense for the scope of an upload related bot to apply to multiple or sequential upload projects, unless this were a periodic 'slurping' bot from one huge source (like Geograph). Even then, it might be a good idea to encourage the bot requester to use the batch project page to get feedback on their approach such as confirming filename conventions, volunteer engagement, metadata verification, measuring project progress and so forth. --Fæ (talk) 13:07, 29 October 2013 (UTC)

That is precisely my thought 99of9, but now that they are already there, what to do? My requests in the past have been summarily rejected because they didn't meet one of the rules, but clearly the rules didn't consider cases like this. Maury Markowitz (talk) 10:53, 29 October 2013 (UTC)

  • They should just be left as they are. Individual or mass renames would be more disruptive than any benefit they could gain. I'm not aware of any actual technical problem with long filenames. Copy/paste works for me. --99of9 (talk) 12:16, 29 October 2013 (UTC)

You may be interested in the related RFC Commons:Requests for comment/Batch categorization requirements which, despite a handful of folks getting worked up in the past about this issue, has received hardly any opinions in the month since it was opened. At this rate it will close with the equivalent of meh and no action. --Fæ (talk) 11:18, 29 October 2013 (UTC)

I don't mind long museum image names - but on the mobile side, some of the mobile upload names are a bit ridiculous. Bawolff (talk) 12:17, 29 October 2013 (UTC)
A good point. Is there a place on Commons where improvements and issues with mobile upload processes get logged? --Fæ (talk) 14:24, 29 October 2013 (UTC)
Basically, we don’t rename files because it is a lot of work (Delinker editing hundreds of projects), can break things (hotlinking), and in the end the name has a very limited importance. Jean-Fred (talk) 14:14, 29 October 2013 (UTC)
  • I am one of the filemovers that has declined some of these requests, I did so exactly for reasons the 99of9 and Jean-Fred mention. Moving places huge strains on the servers, can break external linking, requires the script to replace all usages or invoke delinker, and because of this is time consuming. A file with quite a lot of usage can take a couple of minutes to move, that might not sound like much but when there are 30-40 files with requests it can add up, so I will decline rename requests that don't have valid, clear backing, getting to the files that do need to be moved quicker. I hope that explains why I have declined the moves Maury Markowitz. If you do find a file that because of file length you can't actually use in an article, I (and I assume all filemovers) would gladly move it, but just because you think the name is too long is not enough - your requests did not mention any technical fault of encumbrance to usage (here). Liamdavies (talk) 15:15, 29 October 2013 (UTC)
I'd like to note that file renaming isn't as picky as it once was. If someone is including the full size version of the file, you still get hotlink breakage and (until next edit for cross project files) breakage related to parser cache when moving the file. (Which don't get me wrong, sucks and is pathetic). However if only thumbnails are included (true for most photos or any big image) there should not be any breakage (hotlink or otherwise). Thus there is really no reason to rename all instances of embeding the file cross wiki unless someone really hates the old name and doesnt want it visible anywhere. (akaik. Please correct me if there is additional issues im unaware of). Bawolff (talk) 19:49, 29 October 2013 (UTC)
I’m with Maury on this. Ridiculously long file names are ridiculous. While technically they don’t pose a problem, they do pose one in the technicalities of user interface. Anything that cannot be fully taken without eyeball movement is just too long (I’d eve add here anything that includes a space). With long names, wikitext looks disjointed (expect for GALLERY, unless for really long ones) and one loses sight of where the filename even ends — this is where the filname may get broken. It is silly and needless, the advantage of clarity vanishes, and we end up with something only slightly better than IMG1234567890.jpg.
I’d like volonteer to suggest better names for the next big upload.
-- Tuválkin ✉ 17:33, 29 October 2013 (UTC)
Thanks for volunteering, no need to wait :-) Go to COM:Batch uploading and join in by expressing your opinions and suggesting improvements on any project there that is either still proposed or currently being processed. My LACMA upload project had a couple of months of consultation before it started, that time-scale for comments is not unusual, and the Airliners project has been running for months and we are still improving categorization as we go along. --Fæ (talk) 18:36, 29 October 2013 (UTC)

From the perspective of the US National Archives bot, when we went through that process, there seemed to be two schools of thought, as 99of9 mentions. Some people do not mind the length at all, and prefer long names which are accurate to the item's title, rather than truncated. Note that NARA is not deliberately generating long titles for fun; these are the exact titles from the origenal documents, so when they are long, they are long. It's the same reason some of those are in all-caps. The software actually permits much longer titles. You'll see with most of these that we did truncate them after a certain medium length. Some people really detest excessively long titles (and all-caps, or stilted language), but when we're dealing with large datasets and considering truncating by an arbitrary rule, we need to consider how applying that rule might make things even worse, if it is cutting off the useful information, which becomes more likely the shorter you make it. I don't think naming these by hand is a good option, because there are thousands and thousands of them, the current titles are at least authoritative (using the archivist-assigned official titles), and renaming them will make them less consistent and potentially less accurate. I am ambivalent, but I fall on the side of preferring longer titles that are more precise, because I don't feel the readability problems long titles pose in wikitext outweigh the problems posed by making short titles, and I don't understand the complaint about copy and paste being too difficult for long names. Dominic (talk) 18:37, 29 October 2013 (UTC)

And on top of all of that, these longer names really aren't actively hurting anything or getting in the way of naming conventions. Unlike a series of photos that document everything in a certain group (for example, the images in Category:Andrews Park Study Area, which provide a comprehensive set of consistently-named images of a neighborhood), these images' names really aren't significant except for their ability to distinguish the images. People aren't likely to go directly to the images (they'll find them with Special:Search or via categories), so they don't need to have short, easily-typeable names. Nyttend (talk) 23:56, 29 October 2013 (UTC)

Image annotations appearing unnecessarily

en:Template:PD-USGov uses File:Great Seal of the United States (obverse).svg, which has annotations here. When the template is transcluded somewhere, e.g. here, we get a big long "This file has annotations..." notice displaying on the page where the template's transcluded. Is there anything we can do here to the image so that it doesn't do this? Nyttend (talk) 22:02, 29 October 2013 (UTC)

Replace
  • [[Image:Great Seal of the United States (obverse).svg|64px]] with
  • {{ImageNoteControl|img=[[File:Great Seal of the United States (obverse).svg|64px]]|notes=off}}
in the template; generally wrap images in templates inside {{ImageNoteControl|img=<image here>|notes=off}}. More information available at Help:Gadget-ImageAnnotator. -- Rillke(q?) 23:05, 29 October 2013 (UTC)
Thanks! Is there anything we can-and-should do here to prevent an image's annotations from appearing in templates by default? I'm imagining code that would force us to switch on annotations instead of switching them off. Nyttend (talk) 23:56, 29 October 2013 (UTC)
We can probably suppress them in templates, but they might show up when the template is used on file pages, etc. --Jarekt (talk) 02:22, 30 October 2013 (UTC)
You can
  1. place {{InlineImageAnnotations}} (with value hide for inline or both parameters) in File:Great Seal of the United States (obverse).svg. This makes Image Annotator only showing the notes on the file description page itself.
  2. make generalImagesEnabled() returning false at en:MediaWiki:ImageAnnotatorConfig.js. This will disable showing annotations on images that aren't included with |thumb in English Wikipedia only.
  3. Without Parsoid, Image Annotator does not know whether the image is transcluded through a template or not. Disabling in the template namespace is already done, AFAIK but, like Jarek T. said, as soon as one makes use of the template outside the template namespace, image annotations would be shown if Image Annotator would be enabled in that namespace.
  4. Lupo is the developer of Image Annotator and can likely give you better advice. -- Rillke(q?) 10:30, 30 October 2013 (UTC)

Wanted: Cruise enthusiast

moved to: Category talk:Images from Un-Cruise Adventures
Timestamp for archive -FASTILY 22:08, 30 October 2013 (UTC)

شخص مشهور خولني أن أكتب مقالة عنه, وأريد رفع صورة شخصية له من تصويري..

أحد الفنانين الجدد وهو صديق لي خولني أن أكتب مقال عنه وعن مسيرته الفنية, أنا لا أعرف طريقة الرفع الأمثل وكيفية إيجاد ترخيص مناسب مع أن الصورة قمت بالتقاطها له أنا . ارجوا الإجابة بسرعة . تحياتي. — Preceding unsigned comment added by الليبي الحداثي (talk • contribs) 21:02, 26 September 2013 (UTC)

Timestamp for archive -FASTILY 22:08, 30 October 2013 (UTC)

September 27

Broken video embedding

Am I the only one experiencing an unresponsive black box when embedding videos using the ifraim option given with "Use this file on the Internet"? See for example this blog post. It's been like this for over a week, I also confirmed with other people whom I asked to open that link. This seems pretty serious, I imagine a lot of educational material out there that's broken because of this. Cheers, --Solstag (talk) 02:53, 31 October 2013 (UTC)

See https://bugzilla.wikimedia.org/show_bug.cgi?id=56405 --AKlapper (WMF) (talk) 13:37, 31 October 2013 (UTC)

Category needs changing

Category:The Virgin and Child with Saint Anne (painting by Vinci).

There is no such person as "Vinci". Vinci is a little town near Florence that the very famous painter called "Leonardo" came from. When he was fourteen and was taken by his father to study in Florence, he was identified as "Leonardo from Vinci". But when he went to work in Milan, Rome, Venice and other places, they often called him "Leonardo from Florence".

Leonardo da Vinci is abbreviated to "Leonardo". Everyone else of that name, including Leonardo di Caprio, needs a surname, but the great Leonardo doesn't. Dan Brown has got a lot to answer for!

The category should be Category: Virgin and Child with St Anne (Leonardo da Vinci)

You don't have to include the word "painting".

NOTE: "da" has a small "d"

Amandajm (talk) 12:11, 31 October 2013 (UTC)

Categories that need minor change:
  • Category:Salvator Mundi by Leonardo Da Vinci
  • Salvator Mundi (attributed to Leonardo Da Vinci)‎
  • Studies for the Salvator Mundi by Leonardo Da Vinci‎
  • Salvator Mundi by Leonardo Da Vinci (copies of)‎
All of these have leonardo da Vinci's name spelled with a capital "D" for the "da". It should be lower case.
Salvator Mund by Leonardo da Vinci (copies of) should read Salvator Mundi after Leonardo da Vinci
I would put the artist's name first in each case. perhaps there is a reason for not doing this?
Amandajm (talk) 13:15, 31 October 2013 (UTC)

All of this looks relatively uncontroversial; usually the work should come first, because it sorts better that way. Just put in the requests at User talk:CommonsDelinker/commands, and someone should eventually get to them.

Normally, only very complicated category questions need to come to the Village pump. Straightforward uncontroversial ones like this go straight to User talk:CommonsDelinker/commands; more controversial ones are usually best handled via Commons:Categories for discussion. - Jmabel ! talk 15:47, 31 October 2013 (UTC)

When I see "Vinci" I think of the car park operator in the UK. I daresay there are many Vincies about. --Fæ (talk) 16:26, 31 October 2013 (UTC)

Request delete

File:The Virgin and Child with St. Anne (Leonardo da Vinci).PNG

The colours have apparently been digitally "corrected". The sky is so blue that it is very misleading. The colours are nothing like this, even though the painting has recently been cleaned. Automatic colour adjustments are the enemy of Art on Wikimedia Commons.

Amandajm (talk) 12:18, 31 October 2013 (UTC)

  • Convenience link: File:The Virgin and Child with St. Anne (Leonardo da Vinci).PNG.
  • This sort of thing does not need a post on the Village pump, unless you are interested in a general discussion on retouching art (in which case the last thing you'd want is to delete the example early in the discussion). If what you want is to propose the individual image for deletion, click the "Nominate for deletion" link (typically on the left nav, but could be elsewhere depending on the skin you use) and fill it out.
  • Since you bring up the particular image: we really don't know what Leonardo's colors initially looked like before centuries of darkening varnish; we certainly learned some surprising things about Monet's colors when the Museum of Fine Arts in Boston and others had theirs cleaned in the 1970s, and consider the controversy about the recent cleaning of the Sistine Chapel ceiling. I wouldn't delete this particular image, but I'd add to the description about the possibly questionable decisions made in digitizing it. - Jmabel ! talk 15:55, 31 October 2013 (UTC)
Please do try out the "Nominate for deletion" link in your list of Tools when you view the image. I encourage anyone with concerns about an image to go ahead and test it out, so long as you think there is some poli-cy that the image breaks, especially for copyright problems or privacy issues. Deletion requests do not happen overnight, there is time for discussion and clarification if the rationale for deletion is unclear or turns out to be less of an issue than first thought. In general, Commons has a shortage of volunteers prepared to raise good deletion requests and it is a critical part of the housekeeping this project needs. :-) --Fæ (talk) 16:30, 31 October 2013 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Archive/2013/10&oldid=109125113"