Commons:Village pump/Proposals/Archive/2013/02

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

Newspaper view

Currently, newspapers are quite hard to read within Wikimedia Commons. For instance, on this file, you can't read the text without downloading the PDF. I can browse it page by page, but I can't download that page in sufficient resolution to be able to read it.

The solution could be:

Any thoughts about this? Bogdan (talk) 21:53, 30 January 2013 (UTC)

Interesting, you can blow it up to a ".pdf.jpg" for the predefined resolutions, but if the full resolution isn't one of those choices, you can't do it. I don't have the faintest idea how that could be changed, but if it were, the current "Full resolution" link should do what you want, with a new "Download PDF" option doing what "Full resolution" currently does. – Philosopher Let us reason together. 00:19, 31 January 2013 (UTC)
Yes, I've run across this sort of thing before, it's frustrating.
  • Your first suggestion seems like an uncontroversial improvement, I would suggest filing a bug on bugzilla.wikimedia.org. (Let me know if you can't figure out how to do that.)
    Bug created at https://bugzilla.wikimedia.org/show_bug.cgi?id=44531 Bogdan (talk) 09:46, 31 January 2013 (UTC)
  • Your second suggestion doesn't seem right, though -- because it's redundant of a different way we handle it. Are you familiar with the Wikisource editing interface? If not, look at this page to get an idea; and for an example of what it looks like before a human has edited the text, take a look at this page. It pulls an OCR layer from the PDF file (assuming it exists; most scanning software these days will create this layer) and pre-populates the edit screen. I think making improvements to that system so it is more user-friendly for editors would be the better path, rather than taking the approach of Google News. (Another possibility might be to upload the file to the Internet Archive, which does have a web reader -- but it's designed more for books, I'm not sure if it supports zooming elegantly.) -Pete F (talk) 02:03, 31 January 2013 (UTC)
Internet Archive BookReader software is FLOSS. We might want to integrate it on Wikimedia Commons. Looking at this plugin which integrates it into the Omeka CMS, it does not seem that much work. Jean-Fred (talk) 10:31, 31 January 2013 (UTC)
Apparently the IA BookReader is based on scanned JPEG2000 images, with on the fly conversions to JPEG or PNG on IA servers. I don't see how this could help with PDFs on commons. –Be..anyone (talk) 10:00, 1 February 2013 (UTC)

Choices of size of image

About a week ago, this was a Featured Picture on the English Wikipedia:

File:Blois Loire Panorama - July 2011.jpg

On the image page it is offered in no less than six sizes, one of them quite large:

  • 320 × 109 pixels
  • 640 × 219
  • 800 × 274
  • 1,024 × 350
  • 1,280 × 438
  • 12,000 × 4,105 (14.95 MB)

The five smaller sizes appear to be chosen to fit various displays or something like that. They are fine, but I suggest that when an image is this large, it should also be offered in one or more larger intermediate sizes, so that if people are on a slow or expensive connection (or for that matter if Wikipedia is serving slowly, or they just want to be nice to the servers) they have a wider choice of options. Something like 2,560 × 976 and 5,120 × 1,952 pixels would be appropriate in this case. (Also, I suggest the number of megabytes should be shown for these larger sizes if it is more than, say, 1 or 2 MB.)

This suggestion applies to all large images.

I previously posted this comment to the Wikipedia Village Pump (from a different IP address), and it was noted in response that I can construct a URL to deliver any size I like. That's good to know, but I'm talking about what should be offered on the image page.

There was also a response from a user PrimeHunter, who said in part:

The displayed sizes are determined by mw:Manual:$wgImageLimits. That page includes (10000,10000) in the alleged defaults, but it was apparently removed after https://bugzilla.wikimedia.org/show_bug.cgi?id=34041#c9. It is not in http://svn.wikimedia.org/doc/DefaultSettings_8php_source.html which says:
01060 $wgImageLimits = array(
01061         array( 320, 240 ),
01062         array( 640, 480 ),
01063         array( 800, 600 ),
01064         array( 1024, 768 ),
01065         array( 1280, 1024 )
01066 );
bugzilla:16081 is an old but still open request to add other large sizes.

So I guess what I'm requesting is a change to that table to include some widths greater than 1,280 pixels. And perhaps a change to the code that reads it, to provide the file size for the newer sizes. PrimeHunter suggested this forum as an appropriate place for the request, so here it is.

--65.94.50.13 06:16, 20 January 2013 (UTC) [confusing typo fixed later]

I agree with this request. Yann (talk) 06:43, 20 January 2013 (UTC)
I agree as well; it seems likely that the software could make better active determinations about the size as a function of the original image size. -Pete F (talk) 00:57, 22 January 2013 (UTC)
I also support including in that array the HD resolution (1920×1080), which is getting really common on many devices. The array was created a decade ago and it didn't keep the pace with the resolution increases. Bogdan (talk) 17:46, 12 February 2013 (UTC)

Template:Pd-ItalyGov

I wonder if I can add the tag {{PD-ItalyGov}}, which in a nutshell put in PD (Public Domain) texts of laws, constitution, judgments and any other official document of the Italian government. Currently it no exist. The law article in English §5, in French §5 or in Italian §5.

Public domain This file shows or is part of a text of official act published and distributed by the Italian State or Italian public administration. According to Italian copyright law, this work is in the public domain in Italy unless the copyright has been reserved explicitly. §5 of Italian copyright law specifies that no copyright exists in such material: "The provisions of this Law shall not apply to the texts of official acts of the State or of public administrations, whether Italian or foreign."

Thanks --Raoli ✉ (talk) 04:06, 10 February 2013 (UTC)

Looks OK, but I'd prefer a more specific name, such as {{PD-Italy-EdictGov}} (in line with {{PD-UK-EdictGov}}) or {{PD-Italy-exempt}} (in line with {{PD-Croatia-exempt}}, {{PD-Japan-exempt}}, {{PD-Slovenia-exempt}}, {{PD-South-Africa-exempt}} etc). To indicate the copyright situation in the United States, the tag could also transclude {{PD-EdictGov}}. —LX (talk, contribs) 09:30, 10 February 2013 (UTC)
I've thought Pd-ItalyGov because it shall be applicable to every act of the Italian Government without limitations. The license tag already indicates a situation of PD in the world for the Italian acts, therefore it is PD in the USA. Insert the template "PD-EdictGov" seems me redundant. The PD-Italy-exempt seems me too general because there is already a PD for Italy: {{PD-Italy}}. Raoli ✉ (talk) 22:55, 11 February 2013 (UTC)
The reason for the EdictGov name would be to clarify that not all works of the government are free, just the edicts "official acts" are free. – Philosopher Let us reason together. 21:19, 13 February 2013 (UTC)
Ok, i agree with you. Can we made this new license? --Raoli ✉ (talk) 23:26, 13 February 2013 (UTC)
It's not a licence, it's an exception to copyright law. -- SERGIO (aka the Blackcat) 13:25, 14 February 2013 (UTC)
I think he meant "copyright tag". I've created it at Template:PD-Italy-EdictGov. – Philosopher Let us reason together. 20:34, 14 February 2013 (UTC)
Yes. --Raoli ✉ (talk) 01:11, 17 February 2013 (UTC)

Elaborate whether mw:Extension:UniversalLanguageSelector is suitable for Commons

This window opens when clicking a language link in the personal link area.

Dear community!

As you have probably noticed, translatewiki and now also metawiki have Extension UniversalLanguageSelector enabled. I think since we are a multilingual project, there could be benefit in enabling this at Commons as well. Comments are welcome. -- Rillke(q?) 15:25, 19 January 2013 (UTC)

Seems useful. Just wondering how it would/could work with our MediaWiki:AnonymousI18N.js
See also Commons-l, where guillom started a similar discussion.
Jean-Fred (talk) 13:54, 21 January 2013 (UTC)
These people formerly communicated on-wiki but now they seem to prefer the mailing list.
So here is a list of features that currently available at Commons:
I am still confused by some questions:
How could we migrate all our stuff efficiently?
Will there be a way for users to turn the extension off in their preferences? mw:Help:Extension:Translate contains a lot of blah-blah but nothing specific (and is biased cf. „essential features“).
While translatewiki.net welcomes me in my native language, Meta does not and does not offer selecting a language for anonymous users. Why?
If I go to https://www.mediawiki.org/wiki/Help:Extension:Translate?uselang=es , the page is displayed in English, my expectation would be Spanish. -- Rillke(q?) 21:46, 21 January 2013 (UTC)
Very good overview, thanks.
Persistent language setting/selection for anonymous users is currently achieved by persistent ?uselang= (through AnonymousI18N). This feature is a must have (whether using uselang or something else).
Jean-Fred (talk) 22:02, 21 January 2013 (UTC)
Rillke, the reason why I replied on Commons-l is very simple, mediawiki-i18n was cc'ed and I wanted to keep it so (the discussion probably started there for the same reason). Some things have to be decided by the community and as I said definite answers can come only from the devs; some things also require a parallel discussion among devs... --Nemo 14:09, 22 January 2013 (UTC)
About Extension:Translate: translatable pages work a bit differently. The content of a single page does not vary per interface language, but there is a little helper: https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Extension:Translate?uselang=es goes directly to the page in your interface language (in this case Spanish because it is overridden from the url). There are also other methods for making stuff translatable which can be more suitable. Those are mentioned in the documentation too.
There is also the TranslateSVG extension that is in my opinion quite promising.
As for ULS, it does multiple things:
  1. Webfonts and input methods
  2. Language selection
  3. Language detection for anon users
Due to technical challenges we've not been able to enable all features of ULS for anonymous users yet, except in translatewiki.net.
What exactly would you want to turn off in preferences? Both ULS and Translate are very non-intrusive, except for webfonts and input methods, which can be disabled from the ULS UI.
– Nikerabbit (talk) 14:44, 22 January 2013 (UTC)
Thanks for the summary and the information about why it isn't fully working at meta. Technical challenges :P - in the non-business-environment also called bugs or issues. It is much appreciated. I remember times where IME/Narayam made IE really sluggish; even when disabled in UI. I will test it on my local wiki and hope some people familar with Commons templates will do the same or take the offering by Nemo and ask translation admin rights on mediawiki.org or Meta and set up some pages for translation, return with good ideas how we can migrate the current system and that the devs are now careful enough not to set up synchronous event listeners that do heavy operations. -- Rillke(q?) 00:59, 24 January 2013 (UTC)

Reading mw:Extension:UniversalLanguageSelector and mw:Help:Extension:Translate it does sound like it has advantages. Tracking how up-to-date translations are is a particular advantage - it's almost impossible to get a grip on that in the current system. My questions would be

  1. how difficult would it be to introduce it? (What would immediately break / how much would need changing on Day One to avoid breakage? To what extent can conversion be done gradually over time, after the Extension is installed?)
  2. are there any identifiable downsides compared to the status quo?

Maybe users with experience of the extension can clarify this. Rd232 (talk) 13:59, 19 February 2013 (UTC)

Well, I'm quite negative of introducing Extension:Translate in Commons. The extension UI is not so convenient for translators. When I find minor typos, because section editing is locked, I had to find all text again in Special:Translate on Meta. And cursor often goes front of textbox and breaks translation while I write the translation. (Maybe this issue can be confined to my computer or browser) – Kwj2772 (msg) 15:44, 22 February 2013 (UTC)
Looks like bugzilla:37589?
Conversion can surely be gradual (the problem is rather how to accelerate it, see Meta and mediawiki.org), but the details of it depend on the local custom scripts and templates. Search is indeed one of the areas which are being worked on, but "where does typo X come from" is much less of a problem here on Commons than "what the hell do I have to translate among those two thousands translatable templates?" (a question that, as a translator, I've had for a few years and I never managed to get an answer for, with the result that I never translated a single line here on Commons, I suspect). --Nemo 10:40, 23 February 2013 (UTC)

Next steps and Wikimania

Jean-Fred got translation admin rights and is familiarizing with Translate on Meta; I think you all may also be interested in wm2013:Submissions/Multilingual Wikimedia Commons - What can we do about it, it looks very impressing. There's still plenty of time to adjust focus of submissions before the deadline, so I think your feedback on what could be done/said at Wikimania will be very useful, whether you're attending or not. Of course it would be nicer to have achieved something before July. :) --Nemo 10:30, 18 February 2013 (UTC)

List view on categories

On some categories such as this: Category:Books by Nicolae Iorga, the pictures don't say much and the lack of a full name makes it hard to find anything. Is it possible to have some kind of a list view (with the full name of the file displayed) for some categories? Bogdan (talk) 19:33, 13 February 2013 (UTC)

I like this idea. Perhaps there could be an option that permits the reader to toggle from one view to the other (as opposed to having to set this on a per-category basis)? -Pete F (talk) 20:08, 13 February 2013 (UTC)
Inserting __NOGALLERY__ makes it to display the list of the items in the category, but I absolutely support the idea of making it toggle-able, especially for books, music/sound records, pdf files, letters, videos, slide shows, timed text ... --Foroa (talk) 06:30, 14 February 2013 (UTC)
 Support --Jarekt (talk) 12:41, 14 February 2013 (UTC)
Long Image Names in Categories is an existing gadget that can be turned on in Preferences so you can see the full image name. (It's on by default for new users.) User:Rillke could probably create a per-category toggle for it. A full-on List View might be harder, I'm not sure. Rd232 (talk) 22:57, 15 February 2013 (UTC)

Automatic removal of Uncatgorized-template

When a category is added, the Uncategorized-template remains there unless you remove it. Not everybody does that. The result is that there are a lot of images in Category:All media needing categories as of 2013 which are in fact categorized. Is it possible to remove the template automatically when a category is added? --Jonund (talk) 12:08, 15 February 2013 (UTC)

HotCat removes the template automatically. Ruslik (talk) 11:53, 28 February 2013 (UTC)

Problem searching for specific content. Suggestion for meta data

When searching for media in Wikimedia Commons, search terms will frequently pull up material that has no relation to the term other than that the term is used in the catch-all description field. The term may not apply to the media object at all, but instead to the attitude of the submitter or some other state not directly related to the object.

Meta data related to a media object could be segregated and thus make those objects more searchable.

From this user's experience, it seems that the meta data being used to identify each media object contains not only descriptions of the object itself, but descriptions about the submitter's attitudes and other, perhaps less relevant data.

For example, I wanted to search for images portraying the emotion of gratitude. I got a great deal of returns for the "Grateful Dead." Then I searched for "grateful -dead" and still had too many objects for which "grateful" only applied to the submitter's attitude. For example: "File:Meuse-Argonne Offensive - Map with Vauquois highlighted.jpg," the description contained, "We gratefully acknowledge the accomplishments of the department's former cartographer, Mr. Edward J. Krasnoborski,..." The World War I map contained nothing of gratitude in its image or substance.

Suggestion

Segregate meta data.

Create a field or fields for description of the media object only. These fields should not contain acknowledgements, attitudes of the rights holder or any other "peripheral" data concerning the media object. Such additional information could be relegated to a "Miscellaneous Description" field.

It might be beneficial to further segregate this description -- topic, media type, conditions under which photographs or audio files were obtained, film type and speed for photographs, audio file sound specifications, and the like. My own interests in searching for content involves the "topic" field.

I suspect that the topic field could be further broken down much as a thesaurus is segregated by concepts. Additional field breakdowns would be conditional. For instance, fields that involve attitudes or emotions of people would not be available for pictures of WWI maps or audio files of song birds.

The idea is to create an intelligent search capability for pointing to specific content in multi-dimensional concept space. Each idea has a set of vectors, not only in its own identity, but also its applicability and its relations to other ideas. As an analogy, a productive writer will care not only for their own health, but also the health of their writing skills, the health of the equipment they use, the health of the relationships they have, the relative health of their resources, and the health of the environment in which they produce. All of these individual and separate "concept vectors" work in harmony to deliver the desired, final result.

I know that this would require a monumental effort to accomplish, but it should be quite worth the effort in benefit to all those who search.

LoneStar77 (talk) 04:08, 23 February 2013 (UTC)

You might want to check Commons:Requests for comment/improving search. Jean-Fred (talk) 12:41, 23 February 2013 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2013/02&oldid=93102143"