Commons:Village pump/Proposals/Archive/2012/03

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

gadget for image promotion

Could we have a gadget that can be used to easily nominate images to QI, FPC, VI, etc all in one place (rather like the QI nominator gadget but for VI and FPC also.) --Gauravjuvekar (talk) 14:13, 24 January 2012 (UTC)

Vote for jStore. Somehow we have to store the data you entered and this is an easy way. -- RE rillke questions? 21:12, 20 March 2012 (UTC)

Author information on file pages must be clear and machine-readable, even with user customisation

Relevant guideline: Commons:User-specific galleries, templates and categories policy

Hi folks,

We currently welcome users to customise file descriptions pages a lot, mainly through custom templates displaying their name, showing off their cameras, etc.

As far as I am concerned, I dislike custom user templates − i18n issues, screwing-up the visual style, nest for additional ludicrous reuse conditions, unhealthy implied sense of ownership − and I strongly believe they should be strictly controlled for abuses, but well, based on previous discussions, this is not going to happen anytime soon. Fair enough.

The huge problem with having custom stuff, is that it can be a real Hell to parse license and author − two pieces of information of the uttermost importance in our free licenses world − especially for machines. There has to be a clear, machine-readable author indication, so it can be easily retrieved (let’s dream of an API...). For example, I am currently tutoring two students who are building a Wordpress plugin to embed Wikimedia Commons media with appropriate licensing information, and they struggle with that.

We tackled the license issue by enforcing that a “real” license template should always be used (no custom license template or one transcluding a standard template).

As for the author, nothing at the moment. I made a proposal a year ago which was not met with much enthusiasm, so I would like to reiterate it with the following, tentative writing:

“The author field of the {{Information}} template (or equivalent) should display the author, in text format. Users are welcome to add fancy templates, but outside of it.”

Going through some pictures of the day for examples: bad practice, good practice.

Thoughts? (feel free to amend the wording so it reads better)

Jean-Fred (talk) 15:23, 5 March 2012 (UTC)

As a JavaScript hobbyist developer, who tried to make our slideshow display author and license in a compact way, who wrote the a gallery script showing license information below each image and VisualFileChange, I strongly encourage such requests. If the mess with the image description pages continues, no one will be able to reuse them automatically. And only automated credit generation is a grant for proper reuse. On my talk page, you see another user attempting to do the impossible.
Of course, if credit information would be saved in a different database table field, we could have an API which would be the best. -- RE rillke questions? (ریلکه) (里尔克) (リルケ) 15:46, 5 March 2012 (UTC)
I definitely agree with the idea but would forcing out fancy stuff be enough to make it machine readable ? There are other things that are difficult to remove from the author field. For example indicating the particular role of each contributor of a derivative work. So should we somewhow signal that something is an author name ?--Zolo (talk) 16:03, 5 March 2012 (UTC)
By the way, {{Artwork}} display the artist as the author, and the photograph is only mentionned in the source, even when he is the only one that really needs to be credited. This confuses StockPhoto (see here for instance). Should we add a {{Information}} to {{Artwork}} to solve the problem. -Zolo (talk) 16:10, 5 March 2012 (UTC)
What about RDF as a machine readable format ? That's what it was built for, after all. CC even has a schema for its licences. Dublin Core is also an option.
--EdouardHue (talk) 20:30, 5 March 2012 (UTC)
A closely related but different problem. In fact, though we do not implement RDF nor DublinCore nor CC REL, we do provide some machine-readability − see Help:Machine-readable data. So the author field contents are indeed wrapped in a machine readable tag, but if the field is full of crap, this becomes useless.
As for standard format support, this has been a feature request for like forever (DC: strategy:Proposal:Dublin_Core ; CC REL: bugzilla:9666 ; or whatever.
But with the apparent near-resolution of bugzilla:33886, seems we can finally see the light at the end of the tunnel. Yay! Jean-Fred (talk) 01:01, 6 March 2012 (UTC)
But you still get a lot of overhead if you actually only want the license and author -- you must use the rendered version (or let a tool do it). -- RE rillke questions? (ریلکه) (里尔克) (リルケ) 12:10, 6 March 2012 (UTC)
Ok, there is support so far, but clearly not enough opinion expressed. So, how shall we move forward with this? Jean-Fred (talk) 12:30, 18 March 2012 (UTC)
I strongly agree with the sentiment of the proposal. Thank you for pushing these issues, Jean-Fred. I think there should be much clearer policy/guidelines on this. Isn't Commons:Licensing#License_information the policy that this proposal should be addressing? If this was reworded so that users should use one of the standard templates ({{Information}}, {{Artwork}}, {{Book}}...), and specify more strictly what the contents of fields should look like, that would help a lot. Whether the templates then use a standard metadata format is then a secondary issue (although it helps if the fields match up well?).
What I've found most confusing when working on usecommons is not that there's sometimes junk in the author field, but that there are so many fields to look for author information in. I've used the same priority order as MediaWiki:Gadget-Stockphoto.js which is:
  1. Use fileinfotpl_credit from {{Credit line}} if available (for both author and license)
  2. Use licensetpl_attr if available from any of the license templates
  3. Use licensetpl_aut if available from any of the license templates
  4. Use the creator field from the {{Creator}} template, sometimes found inside other information templates
  5. Use fileinfotpl_src for attribution
  6. Use fileinfotpl_aut for attribution, cleaning the field with various heuristics.
I find this a bit of a mess... what can be done about it? /skagedaltalk 12:44, 20 March 2012 (UTC)

New usergroups and user right changes

Here are a few proposals. It is a collection of previous suggestions. It will be announced in a site-notice or watch list notice after a while if it turns out practicable. See also Commons:Administrators' noticeboard/Archive 31#Suggestions for new flags. — Preceding unsigned comment added by Rillke (talk • contribs) 2012-01-31T17:04:13‎ (UTC)

General discussion

New group: Maintainer

1pro 5contra

Reasoning: Due to multilingualism, Commons has a lot of maintenance-overhead and will ever have. Scripts require i18n, protected templates, too. We have ~60 Gadgets and far more scripts or templates requiring translation. We have only some users caring about work requests for bots. Assigning this rights to trusted users with a clear mandate for maintenance jobs and not doing any controversial editing.

Rights to include:

  • editinterface: Edit the user interface
  • protect: Change protection settings and edit cascade-protected pages
  • abusefilter-log-detail: View detailed abuse log entries
  • abusefilter-modify: Create or modify abuse filters
  • apihighlimits: Use higher limits in API queries
  • suppressredirect: Not create redirects from source pages when moving pages
  • rollback: Quickly rollback the edits of the last user who edited a particular page

This user group should be assigned after a community election like currently done for adminship and should be removed after inactivity or when abused.

Voting: Support

Voting: Oppose

  •  Oppose this bundle for inclusion of editinterface and abusefilter; these require not just trust "this user is a good-faith contributor", but trust "this user knows what they're doing in quite technical areas". They should be assigned only when those technical abilities have been specifically evaluated. En.wp has a usergroup for abusefilter managers - if we want more people to have access, I think that's the way to go. Strip these two rights out, plus abusefilter-log-detail as that will (probably) go to Patrollers, and I don't think there's enough left to justify the complexity of a new usergroup. Rd232 (talk) 20:07, 31 January 2012 (UTC)
  • That simply are admin jobs. editinterface is editing all MediaWiki pages (incl) .js? Those people should be trusted enough to handle also the few rights which admins have. And: I am not really overwhelmed by that proposal at all. E.g. probably only few people will know what the rights include and what not. I guess the "protect" should only be allowed to be used for Interface pages but not to protect files which are at edit war or similar? --Saibo (Δ) 21:52, 31 January 2012 (UTC)
  • No need to unbundle the sysop group here - anyone who is trusted with all of those rights should be trusted with the entire sysop package. Ajraddatz (talk) 19:03, 1 February 2012 (UTC)
  • --Marco Aurelio (disputatio) 14:00, 7 February 2012 (UTC) No hay justificación alguna para desmantelar la figura del administrador y crear más y más jerarquías. Lo que necesitamos son administradores activos; no nuevos grupos de usuarios ni más votaciones.
  •  Oppose per above. -FASTILY (TALK) 07:05, 24 February 2012 (UTC)

Discussion

"this user knows what they're doing in quite technical areas" — of course. But if you have an admin from en.wp or being in a trusted role (technically, too) in another Wikimedia project, it is likely that they will fail here if they've not enough experience. You do not need a specific Commons-knowledge to fix js-errors of common nature or arising due to software-changes. I just see me confronted with a big feature-request queue and scripts needing inspection. -- RE rillke questions? 21:55, 31 January 2012 (UTC)
if we want to support technically capable users from other projects to contribute here, then I think specific usergroups are best: one for editinterface and one for abusefilter. Those shouldn't be handed out as easily as, say, rollback, though. Maybe specify 1-week debate and advertising somewhere on the user's home project (user talk page perhaps). Rd232 (talk) 22:04, 31 January 2012 (UTC)
"anyone who is trusted with all of those rights should be trusted with the entire sysop package": But won't be if not participated in DRs. I will never support someone who never dealt with licensing stuff as an admin here on Commons. -- RE rillke questions? 19:25, 1 February 2012 (UTC)
Not all admins should be forced to participate in deletion requests - your own standards for adminship shouldn't cause the creation of an entirely different group. Ajraddatz (talk) 20:28, 5 February 2012 (UTC)
This is not only my view on this matter. Please have a look at the last RfAs. -- RE rillke questions? 08:51, 23 February 2012 (UTC)
We have with Commons:Administrators/Requests/M0tty a case of a nomination mainly the L10n maintenance tasks who were successful (18 approval, 0 oppose). --Dereckson (talk) 19:35, 3 March 2012 (UTC)
M0tty has >70 deletion requests, and >400 edits in the Commons-namespace and yes, I am happy that M0tty is admin now. -- RE rillke questions? 20:17, 3 March 2012 (UTC)

New group: Deleter

1pro 11contra

Reasoning: ~1000 deletions, >150 regular deletion requests, > 100 files without source or permission per day on Commons. Especially for the deletion-requests we need some users with experience and time. Why not a trial-admin?

  1. The sysop-usergroup allows far more dangerous changes than deleting a file.
  2. WMF will not allow displaying deleted content to a wider user-group for legal reasons.
  3. Viewing deleted text is not so useful on Commons and may raise privacy-concerns.

Rights to include:

  • autopatrol: Have one's own edits automatically marked as patrolled
  • delete: Delete pages
  • deletedhistory: View deleted history entries, without their associated text
  • rollback: Quickly rollback the edits of the last user who edited a particular page

This user group should be assigned after a community election like it is currently done for image-reviewers (asking a few questions, ...) and should be removed after inactivity or doubtful behavior.

Voting: Support

Voting: Oppose

  •  Oppose I don't see how this helps. What's needed is more users willing to do the hard work of carefully reviewing and closing deletion requests; the actual act of deletion (for requests closed "delete") can be delegated to admins (if necessary we can look at how to streamline that delegation). And it's these acts of reviewing and closing which are the real preparation for being accepted as admin, in relation to handling deletions. Also, there is a longstanding reluctance to give users the ability to do things they cannot undo; to many, this doesn't feel right. Rd232 (talk) 17:24, 31 January 2012 (UTC)
  •  Oppose per Herby. Experienced users should run a request for adminship. No need for this group. --High Contrast (talk) 19:38, 31 January 2012 (UTC)
  • Rd232 says it well: we need people commenting and summarizing at DRs - not the actual deletions. Also the no self-undo is a problem. --Saibo (Δ) 22:05, 31 January 2012 (UTC)
  •  Oppose It is relatively easy to become a sysop here. So, users with an extensive experience in the deletion process should apply for adminship. Ruslik (talk) 08:23, 1 February 2012 (UTC)
  • Per above, the issue here is a lack of commentors on RfDs, not a lack of people to close them. Also, as Herby said, if people can be trusted with this there is no reason to not trust them with the entire sysop package. Ajraddatz (talk) 19:04, 1 February 2012 (UTC)
  • --Marco Aurelio (disputatio) 14:03, 7 February 2012 (UTC) Por lo expuesto por Herbythyme y los que me preceden. No hay justificación alguna para desmantelar la figura del administrador y crear más y más jerarquías y votaciones. Lo que necesitamos son administradores activos e interesados con el proyecto.
  •  Oppose - per comments above. Sysop rights is good enough. --Sreejith K (talk) 15:59, 7 February 2012 (UTC)
  •  Oppose - Per Herby. Tiptoety talk 04:36, 23 February 2012 (UTC)
  •  Oppose -FASTILY (TALK) 07:03, 24 February 2012 (UTC)
  •  Oppose Too close to full admin. Persons ready for being deleter can be admin as well. Lymantria (talk) 17:46, 2 March 2012 (UTC)

Discussion

Trial-admin

0pro 7contra

Reasoning: Same as other new user groups: Helping to reduce the backlog and gaining useful users.

Rights to include: (user is sysop-usergroup is assigned to the user for a limited time)

This user group should be assigned after a community election like currently done for adminship and should be removed after inactivity or when abused.

Voting: Support

Voting: Oppose

Discussion

Right-change: Patroller

abusefilter-log-detail: 5pro 2contra

Reasoning: Special:Permalink/66349249#Abuse filter log details

Rights to include:

Maybe:

  • + suppressredirect: Not create redirects from source pages when moving pages

Voting: Support

After hearing other users, unwatchedpages and suppressredirect may not be suitable for patrollers. Techman224Talk 03:39, 1 February 2012 (UTC)

Voting: Oppose

  •  Oppose unwatchedpages as too dangerous and not that useful.  Oppose suppressredirect as not relevant enough. Rd232 (talk) 19:57, 31 January 2012 (UTC)
  •  Oppose unwatchedpages doesn't have much usefulness here on Commons and is easily abused, especially with as few active patrollers as we have. suppressredirect should almost never be used, see also m:User:Krinkle/Don't delete redirects. –Krinkletalk 13:53, 7 February 2012 (UTC)
  • Privacy concerns. No. --Marco Aurelio (disputatio) 14:07, 7 February 2012 (UTC)
    • No to all? The user pressed save. Is it impossible to hide/oversight such a log-entry? -- RE rillke questions? 14:30, 7 February 2012 (UTC)
      • Yes, no to all. Sorry to be that guy here. Suppression (or better said, hidding from the sysop's view abuse filter log entries is possible; but because that's possible I think there's no reason to open the box and let everybody see into it. FYI I'm a frequent reviewer of the abuselog and also a frequent requestor of abuselog events suppression at oversight-commons. I've seen there not only nasty attacks or plain vandalism, but more serious issues like outright libel, highly personal data (fullnames, addresses, telephone numbers and so on); most of those put there in bad faith to attack others (users and non-users). I do not think there's any benefit letting people see those, as it happens with deleted revisions. When I come across one of them I approached the oversighters and so they could decide whether to hid or not. In fact most of the things caught by the filter are bad by default (except false positives). It's good it's limited to sysops only so only a limited number of (trusted and community approved) users can see those entries, and in case such a problematic log entry is generated (and I bet there are many of them), the risk is lower and can be handled easily. I think those rights are too problematic to be given out without due caution. About suppressredirect/unwatchedpages I think Krinkle & Rd232 have a good point. Best regards. --Marco Aurelio (disputatio) 15:33, 7 February 2012 (UTC)
  •  Oppose Per above. -FASTILY (TALK) 07:04, 24 February 2012 (UTC)

Discussion

  • 'abusefilter-log-detail' is assigned to '*' on enwiki without any problem. Why is it assigned to sysops here? At least 'autoconfirmed' should have it. Ruslik (talk) 08:26, 1 February 2012 (UTC)
  • "suppressredirect as not relevant enough" — Thought it could be useful when patrolling new pages but I agree. -- RE rillke questions? 19:28, 1 February 2012 (UTC)
    • On Wikipedia, maybe (to move pages without unnecessary redirects). On Commons, page moves with unnecessary redirects are much less frequent. You could make more of a case for rollback or filemover rights - but each of those already has its own usergroup, and I think it's best left that way. Rd232 (talk) 00:00, 2 February 2012 (UTC)

Right-change: Image reviewers

10pro 0contra

Reasoning: Reedy fixed the upload by url so it can be used for internal transfer (from upload.wikimedia.org). Currently reverted because Siebrand requested so. It since Image reviewers are supposed to be trusted concerning licensing-issues, it should be no problem. See also: Commons:Village pump/Archive/2008/07#Upload by URL

Rights to include:

Voting: Support

Voting: Oppose

Discussion

New group: Editall

This is an alternative to the proposed "Maintainer" group.

1pro 4contra

Reasoning: Due to multilingualism, Commons has a lot of maintenance-overhead and will ever have. Scripts require i18n, protected templates, too. We have ~60 Gadgets and far more scripts or templates requiring translation. We have only some users caring about work requests for bots. Assigning this rights to trusted users with a clear mandate for maintenance jobs and not doing any controversial editing.

Rights to include:

  • editinterface: Edit the user interface (ability to edit the MediaWiki: namespace)
  • editprotected: Edit pages protected as "Allow only administrators" (ability to edit protected pages and files)

Voting: Support

  • This would allow technically capable users, especially those with a track record on other projects, to have direct access to scripts and gadgets. It would also allow non-technical trusted users to edit protected messages (MediaWiki messages or protected templates), which is important for localization. Rd232 (talk) 00:45, 1 February 2012 (UTC)

Voting: Oppose

  • Really don't see a need for this. If you can trust them with abusefilter, editinterface and editprotected, why not the entire sysop package? There is no rule that admins must use all of the tools, they can just use as many as they need. That also means that they avoid technical issues of wanting to do something, but still not having the rights to if that ever came up. Ajraddatz (talk) 19:09, 1 February 2012 (UTC)
    • There are editors who might go for these rights who might not want to be sysops, particularly if they're mostly active on another project. Apart from the trouble of having to go through RFA, becoming sysop on a project carries responsibilities that not every editor wants. Particularly for the technically-oriented editors we really want more of, I think it's definitely worth the trouble to create a package of rights that makes it more likely they'll contribute to Commons in this area. Also, for technically-oriented editors, we don't really want them to become full sysops and potentially distracted with other stuff like everyday deletion and blocking which others can do. Rd232 (talk) 20:00, 1 February 2012 (UTC)
      • I suppose it would be beneficial, you make a good point (especially in regards to them not wanting the whole sysop stuff). On aside, sysop tools have never distracted me too much, and I doubt they would do so for others. Ajraddatz (talk) 23:32, 1 February 2012 (UTC)
  •  Oppose editinterface is too powerful to be used just for translations. Mostly due to the fact that all our site resources in JavaScript and CSS are stored here (which enable a user to do very malicious things such as stealing user cookies, manipulating buttons and what not). Hopefully these will go into their own namespace soon (Gadgets 2.0 is on it's way), but until that, this seems like a very mixed view. See also Rd232's Support-message. While reading that I basically see a good reason to oppose, it mixes two very different actions. –Krinkletalk 13:59, 7 February 2012 (UTC)
    • Well, yes, OK, but editinterface is used for translations, and non-techy users wouldn't be able to do the malicious things you mention, so what it comes down to is trusting techy users. That's more about the procedure for giving out the rights than the right itself. So for instance, we could limit Editall to users who are sysops on other projects - that would exclude plenty of good users, but ought to be both safe and easy to administer. Rd232 (talk) 02:21, 9 February 2012 (UTC)
  • --Marco Aurelio (disputatio) 14:08, 7 February 2012 (UTC)
  •  Oppose per above. -FASTILY (TALK) 07:04, 24 February 2012 (UTC)

Discussion

Consensus

It appears that the only consensus we have here is to add the abusefilter-log-detail right to the patrollers group and adding the upload_by_url right to the image reviewers group. I suggest that we file a bugzilla bug to add those, any objections? Techman224Talk 20:59, 19 February 2012 (UTC)

I agree. I wouldn't oppose if someone wanted a more widely-advertised discussion though, so I'd wait a few days before doing it. Also, are we sure that we don't want to do anything to make it easier for techy users to contribute without having to go through RFA? My Editall proposal was the most recent approach, and I was quite surprised it didn't get more support. I imagined it as a right to be given primarily to users who are highly trusted (especially as demonstrated by track record elsewhere) but aren't going to get involved enough in Commons to do an RFA. Standards for it could easily be set pretty high (eg: current sysop on another project for easy access via COM:RFR; otherwise an election required using RFA pass/fail standards) - it would still be better than nothing. Rd232 (talk) 21:53, 19 February 2012 (UTC)
Well the community decided. If they do not need more people caring about i18n and suffer from veiled paranoia, it's not my problem. I just don't understand how a new user group would create more bureaucracy. It would add flexibility. Let's go to bugzilla. Who wants? Please add a link here when done. Thanks in advance. -- RE rillke questions? 16:38, 18 March 2012 (UTC)
  • For the person on Bugzilla verifying the voting:
    • Opening: diff=66350109&oldid=66149183
    • Closing: diff=68515764&oldid=68505763
    • Watchlist announcement: diff=67394870&oldid=66353864

-- RE rillke questions? 16:38, 18 March 2012 (UTC)

  1. Looking at Bugzilla: Bugzilla: 14919 Enable Upload by URL for admins on Commons has been "resolved duplicate" of the main "upload by URL" bug, Bugzilla: 20512 (Enable $wgAllowCopyUploads (upload by URL)), so maybe there's not much point filing a bug for that until 20512 is resolved.
  2. Bugzilla: 35545 - Grant the abusefilter-log-detail right to patrollers on Commons.

Rd232 (talk) 23:19, 27 March 2012 (UTC)

Full URLs in license templates

I propose that the following templates:

{{Cc-by-sa-3.0-migrated}}, {{Cc-by-layout}}, {{Cc-by-sa-layout}}, {{Cc-zero}}, {{FAL}}, {{GFDL}}, {{GFDL-1.2}}, {{GPL}}, {{LGPL}}

– and other templates I might not have found that set the licensetpl_link metadata field (although I've searched through all of License tags with a script) are changed as follows: The URL for the license links have http:// prepended so they become fully qualified, non-ambiguous URLs. For example, on {{GPL}}, the code

<span class="licensetpl_link" style="display:none;">www.gnu.org/licenses/gpl.html</span>

is changed to:

<span class="licensetpl_link" style="display:none;">http://www.gnu.org/licenses/gpl.html</span>

I posted about this on the village pump (read this link for more info), but alas got no response on this super-important matter of life and death! :) I'll add links to this proposal on the talk pages of these templates. Maybe I should go ahead and add {{Editprotected}}? /skagedaltalk 20:06, 20 March 2012 (UTC)

Actually, I tried to do this a while ago and it completely broke the StockPhoto tool, and I could not really figure why. So I guess we need someone to be ready to fix the script if we go with this. :) Jean-Fred (talk) 00:08, 21 March 2012 (UTC) (sorry, forgot to answer you on the VP >_>)
Oh, thanks. That's weird! I'll do some testing in User:-space and see what happens. /skagedaltalk 05:24, 21 March 2012 (UTC)
Ah, got it. Have done some testing on this page. Of course, if you write an URL in wikitext – like http://www.gnu.org/licenses/gpl.html – it is automatically turned into a link (an <a> tag with lots of attributes). As we also see above here. Don't know why I didn't think of that. This confuses Stockphoto, and is not what we want for machine readability. However, MediaWiki has the <nowiki> tag that can be used for such purposes! But we can't wrap the whole span in a nowiki, since the {{Cc-by-sa-layout}} stuff uses template code to build various urls, and those can't be in <nowiki>.
Therefore, my new proposal is: prepend <nowiki>http://</nowiki> to the urls. Like so:
<span class="licensetpl_link" style="display:none;"><nowiki>http://</nowiki>www.gnu.org/licenses/gpl.html</span>
Yes, this looks funny in wikitext, but templates do anyway, and generates the proper HTML, which is of course what is important.
You can verify that it works well with Stockphoto by testing on the me drinking coffee image page (I will restore that page back to normal after these changes go through (or not)). /skagedaltalk 19:27, 22 March 2012 (UTC)
Looks good. Unless opposition I shall implement this soonish. Jean-Fred (talk) 11:54, 27 March 2012 (UTC)
✓ Done in all nine templates mentionned above. Thanks for helping Skagedal. Jean-Fred (talk) 21:26, 27 March 2012 (UTC)
Nice! Thank you! /skagedaltalk 21:29, 27 March 2012 (UT<C)

use commons to offer "information" instead of just multimedia files

There are these Templates in the englisch wikipedia:

It would be nice, if all pages what have been created with the Templates LSR and LPR could be moved to commons and then could be linked to from all wikipedias. Is this possible? en User_talk:Doors5678

Crosswiki template transclusion has to then be enabled in the Mediawiki software, and a scalable technical solution has to be implemented (unsure of the status of this?). This is tracked at Bug 4547. Whether this is a good idea was discussed on the village pump a year ago with unclear consensus. /skagedaltalk 18:50, 29 March 2012 (UTC)
Look at this now: Wikidata – The Wikipedia data revolution – awesome! Looks like we'll have an even better solution for this problem by the end of the year! /skagedaltalk 21:38, 30 March 2012 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2012/03&oldid=70138997"