Someone in the thread on friendliness mentioned that categories are
always in one language (usually english). Well still a long way from
fixing the issue, perhaps if we allowed unrestricted
{{DISPLAYTITLE:...}}, combined with the {{int: hack, that'd allow
better translatable categories. (of course you'd only be able to use
the actual category name in [[category:Foo]] links. I suppose one
could use a bot to automatically change links to redirect categories
to their canonical name, but then we're getting really really hacky).
Anyways, just a thought.
cheers,
bawolff
It is possible to include non-free content in creative commons free
content, as these licences explicitly do not restrict the rights
granted by other laws.
http://wiki.creativecommons.org/Frequently_Asked_Questions#Do_Creative_Comm…
However, I have seen many images deleted on Commons when they contain
fair-use/fair-dealing components within them.
Commons currently has a policy which rejects fair-use, however that is
for images where the fair-use context is external to the media file on
Commons (the wikipedia page).
http://commons.wikimedia.org/wiki/Commons:Fair_use
There are many situations where the fair-use context is embedded in
the media file, such as an image within an image, an image within a
video, or a parody.
Are there examples of fair-use within media on Commons?
The specific case I am interested in this video.
http://www.youtube.com/watch?v=EHqFoK2EHls
specifically all of the logos on the backdrop for the interviews at
0:25-0:35,0:58-1:06,1:11,1:29,2:04
The creator of the video can't possibly secure free content releases
for those logos, and should not need to.
The copyright holders of those logos clearly put them in the public
knowing they would be used in this context, without giving permission
to everyone who had a camera at the scene.
In Australia, this may also fall under the Copyright Act section 67
http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/s67.html
However that depends on whether "television" can be stretched to
include youtube videos if the same content was also distributed on
broadcast television.
This section is omitted from our Freedom of Panorama template.
http://commons.wikimedia.org/wiki/Template:FoP-Australia
Should section 67 be added to the FoP template, or would it be better
to create another class of templates for broadcast television
containing incidental elements of non-free content?
--
John Vandenberg
Hi all,
I write to you on behalf of the public domain working grouf of the
Open Knowledge Foundation. We are currently developing an automated
system to identify the legal status of different types of works (i.e.
to determine whether or not they are in public domain). In order to do
this, we need to gather the necessary metadata to determine the legal
status of these works. This includes information such as title,
author, date of publication, etc.
You can find more information about the project on our site
http://publicdomain.okfn.org/calculators.
A preliminary implementation of the project can be seen at
www.publicdomainworks.net (site still under development).
Incorporating the metadata from the Wikimedia Commons archive into our
database would be extremely useful both for us, since it would greatly
increase the quality of our results.
eg. in the case of
http://commons.wikimedia.org/wiki/File:Cyphoma_signatum_(Fingerprint_Cowry_…
- we would like to retrieve the information from the Summary section
If I understood correctly, the metadata regarding the works of the
archive is primarily text/html based.
Hence, I would like to know (a) whether there exists a database where
this metadata can be retrieved, or alternatively (b) whether would you
be interested in switching to a more structured database contained all
the relevant metadata about those works?
Looking forward to your answer,
Primavera
On Mon, Aug 15, 2011 at 3:25 PM, Ian Baker <ian(a)wikimedia.org> wrote:
> I've made the following changes, which can be tested on
> commons.prototype.wikimedia.org
> 1. Refactored UploadStash to use the database for metadata storage. This
> enables simultaneous multiple-file upload (not multi-file selection, yet).
Hi folks,
this feature is now in production, so do check it out and let us know
if it's broken:
http://commons.wikimedia.org/wiki/Special:UploadWizard
If you select multiple files, it'll try to upload up to 3 at the same
time, which should speed up your upload in many cases. Again, as Ian
says, this feature is not to be confused with multi-file selection,
which we'll definitely implement as well. :-)
Thanks to Ian and Neil for getting the new code out the door.
Erik
--
Erik Möller
Deputy Director, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
http://commons.wikimedia.org/wiki/Commons:Usage_guidelines_for_public_domai…http://commons.wikimedia.org/wiki/Commons_talk:Usage_guidelines_for_public_…
As you can guess just by the title, the talk page has descended into
"be *respectful* of the dear creators" versus "free everything! NO
COMPROMISE!" This will be clearer if you know it was based on the
(highly aspirational and unworkably vague) Europeana guidelines.
I've suggested we keep it academic - whereas the Europeana fluff is
not widespread accepted practice, listing academic provenance *is*.
e.g. creator, retoucher/scanner, hosting institution.
Anyway, there's the talk page - have at it.
- d.
Caroline: those are just test values to show that it's working. On real
Commons we'll have the usual blacklist.
On 8/15/11 3:29 PM, Caroline Ford wrote:
> Hi
>
> I can't see how Nyancat could end up on commons (it would be fair use,
> for a start) but *fail* seems too broad. How many files on commons
> already would be affected by a ban on titles containing fail?
>
> Caroline
>
> On 15 August 2011 23:25, Ian Baker <ian(a)wikimedia.org
> <mailto:ian@wikimedia.org>> wrote:
>
> I've made the following changes, which can be tested on
> commons.prototype.wikimedia.org <http://commons.prototype.wikimedia.org>
>
> 1. Refactored UploadStash to use the database for metadata storage.
> This enables simultaneous multiple-file upload (not multi-file
> selection, yet).
>
> 2. Added support for TitleBlacklist in the UI (via the new
> TitleBlacklist API). Currently the blacklist is the file I use for
> API unit tests, which looks like so:
>
> .*[Ff]ail.*
> .*[Nn]yancat.* <errmsg=blacklisted-nyancat>
>
> So, it will only fail on titles that contain "fail" or "nyancat".
> It should be straightforward to use a wiki page instead, if anyone
> feels the need to test things that file doesn't include. I don't
> actually have permission to create the
> "MediaWiki:Blacklisted-nyancat" page, so if someone wants to test
> custom errors, it'd make sense to make that (for a couple
> languages... for /fr, I recommend the text "C'est l'erreur Chat
> Nyan.") They should work fine, though, since that's all existing
> code in TitleBlacklist.
>
> The user sees the custom error when s/he clicks the "More Info"
> link. That message is often very long and informative, and wouldn't
> fit on the page inline.
>
> 3. There is a blacklist error reporting page, at
> http://commons.prototype.wikimedia.org/wiki/UploadWizard_blacklist_issues
> When a title is blacklisted, the user has the option of commenting
> on that entry with the "Send Feedback" link. The location of this
> page is configurable in LocalSettings.php.
>
> I think that's it. We're looking at deploying the first change on
> Wednesday, and the others next week (barring serious issues).
>
> -Ian
>
>
> _______________________________________________
> Commons-l mailing list
> Commons-l(a)lists.wikimedia.org <mailto:Commons-l@lists.wikimedia.org>
> https://lists.wikimedia.org/mailman/listinfo/commons-l
>
>
--
Neil Kandalgaonkar (| <neilk(a)wikimedia.org>
I've made the following changes, which can be tested on
commons.prototype.wikimedia.org
1. Refactored UploadStash to use the database for metadata storage. This
enables simultaneous multiple-file upload (not multi-file selection, yet).
2. Added support for TitleBlacklist in the UI (via the new TitleBlacklist
API). Currently the blacklist is the file I use for API unit tests, which
looks like so:
.*[Ff]ail.*
.*[Nn]yancat.* <errmsg=blacklisted-nyancat>
So, it will only fail on titles that contain "fail" or "nyancat". It should
be straightforward to use a wiki page instead, if anyone feels the need to
test things that file doesn't include. I don't actually have permission to
create the "MediaWiki:Blacklisted-nyancat" page, so if someone wants to test
custom errors, it'd make sense to make that (for a couple languages... for
/fr, I recommend the text "C'est l'erreur Chat Nyan.") They should work
fine, though, since that's all existing code in TitleBlacklist.
The user sees the custom error when s/he clicks the "More Info" link. That
message is often very long and informative, and wouldn't fit on the page
inline.
3. There is a blacklist error reporting page, at
http://commons.prototype.wikimedia.org/wiki/UploadWizard_blacklist_issues
When a title is blacklisted, the user has the option of commenting on
that
entry with the "Send Feedback" link. The location of this page is
configurable in LocalSettings.php.
I think that's it. We're looking at deploying the first change on
Wednesday, and the others next week (barring serious issues).
-Ian
The foundation mailing list recently discussed "Like"-buttons for
articles, to improve community building and attract new editors.
I thought about improving Commons for the less-techie community. So I
looked at Flickr, and the "community" part on image pages consists
mainly of comments and favourites counter.
Commons can have comments (say that quickly three times in a row!) on
file talk pages, but I've rarely seen "oh, I like this" as a comment
there. Nothing wrong with that, Commons has a more "serious" aspect to
it...
But what if, in addition to the usual Wikimedian ways, there were easy
"favs" and "comment" functions in Commons? Right under the image
description? Have a look (you need to be logged in for the full
flavour):
http://commons.wikimedia.org/wiki/File:Sanger_Institute_and_Hinxton_Hall,_C…
Beneath "Licensing", there is now "Comments and favourites", with a
few test comments of mine. I've also added this as a "favourite" of
mine, being my own image and all ;-)
If you are logged in, you can add one-line comments (with wiki
syntax), and set/remove the file as a personal favourite. These
actions are stored and logged in two ways: On the talk page on the
file, wrapped in templates, and on your user subpages:
http://commons.wikimedia.org/wiki/Special:MyPage/My_file_comments
and
http://commons.wikimedia.org/wiki/Special:MyPage/My_favourite_files
respectively.
For the technically inclined, script is here:
http://commons.wikimedia.org/wiki/MediaWiki:FileComments.js
There could be plenty to do in terms of development: Editing/removing
comments (comment author and admins only?), fancy comment input
dialog, a "Log in or Sign up to comment" link for anons, etc.
So: Comments? ;-)
M.
Hi folks,
are you still experiencing issues uploading through
Special:UploadWizard or Commonist? I just did a quick test with no
problems, but I only have spotty connectivity right now. Our ops team
found that one of the API servers was incorrectly configured, which
has been fixed. But please continue to report problems, here or at
https://bugzilla.wikimedia.org/show_bug.cgi?id=30201 . Detailed
reports are appreciated.
Thanks,
Erik
--
Erik Möller
Deputy Director, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate