Multimedia:Upload wizard/Tech notes

From Wikimedia Usability Initiative

Features / TODO

See Multimedia:Upload wizard/Features

Compatibility

See Multimedia:Upload wizard/Compatibility

Current Commons behavior

Some behavior is important to replicate; others we are deliberately changing anyway...

Descriptions

Commons form uses standard FUBAR-sort for languages (based on language code, which is roughly ISO 639). We are using unicode sort, which groups related langs together. Should move to the planned universal language typeahead widget

Uses languages to group like so: lang = English , description = "foobar", you get {en|1=foobar}. And so on for each language.

It is permissible to have a description in "unknown language". Or multiple descriptions. In that case the form simply doesn't wrap it in a language template. If you have multiple "unknown language" you get them all concatted together and mixed in with actual lang-template-wrapped descriptions. This seems bogus to me, under what circumstances do you not know the language you're entering? (editing is different). We should make 'unknown language' an error.

Licensing

Own work + CC-BY-SA-3.0 + GFDL

  • Information template:

<h2>{{int:filedesc}}</h2> {{Information |Description={{en|1=This is my description of what it all is}} |Source={{own}} |Author=[[User:NeilK|NeilK]] |Date= |Permission= |other_versions= }}

  • License template:

{{self|cc-by-sa-3.0|GFDL}}

  • added immediately to categories (server-side; we don't have to do anything); request paran pprop=text|categories to see
CC-BY-SA-3.0
License_migration_redundant
GFDL
Self-published_work

Third party

I do not know the license: {{subst:nld}}

Strangely, we are allowed to assert "ownwork" here. Ownwork, copyleft, attribution required (CC all versions): {{self|GFDL|cc-by-sa-all|migration=redundant}}

Own work, self: {{PD-self}}

Own work, self, cc-by (no sa): {{self|GFDL|cc-by-3.0|migration=redundant}}

Third party licenses don't have the "self" template.

Creative Commons Zero: {{cc-zero}} Creative Commons by sa 3.0 {{cc-by-sa-3.0}} Free Art License {{FAL}} (not one of our preferred licenses) etc.

From Flickr and I do not know the license: {{subst:template 2|flickrreview|subst:nld}}

From Flickr and I do know the license (for example, cc-by-sa-2.0) {{subst:template 2|cc-by-sa-2.0|flickrreview}}

Categories

Uses HotCats to prefill as you type. Then during posting, simply emits category wikitext, e.g.

[[Category:Foo]][[Category:Bar]]

HotCats recently added up arrows and down arrows to select supercategories or subcategories of the currently-selected category.

You can only do this after you've added the category already. However, once you're in super- or sub- browsing mode, you can keep going in that direction. When you finally make a selection, that replaces the current category.

This seems like a very difficult feature to explain to new users, and also overlaps with the question of how to create a new subcategory on the fly. If I'm looking for Animalia, Felix, Felix domesticus, and then there's no Felix domesticus canhazcheeseburger then what? Why can't I just make it, with the appropriate parentage?

This is why tags are soooo much easier than categories. Why do we keep trying to make this work?

According to Lupo (author of HotCats) expert users have requested it. We should find out what the real use cases are.

Feature implementations

It is considered desirable to automatically "fix" filenames; that is, when there is a file naming conflict, to immediately rename the file to something like "conflict title 2".

There are some issues with that:

  • Discovering a title which is not in conflict is an O(n) operation from the client side. What if there are 12 or more such files? We will be waiting for 12 API calls.
  • Adding random letters or numbers to a title is not helpful to people using the repository
  • What if the user really did want to replace a file? We have to defer to a more convoluted interface later...

Had a chat with RobLa on this and we came up with another idea: when a conflict is discovered, offer them semantically meaningful options, derived from other metadata. For instance, a message like:


There already is a media file with the title 'Nicolas Sarkozy' in Wikimedia Commons. { Preview } If your file has *exactly* the same content except with better quality, you should replace it. { Replace it }

Otherwise, please make your title meaningfully unique:

  • Nicolas Sarkozy at 2010-04-22 in Toulouse, France (Data derived from EXIF)
  • Nicolas Sarkozy in Toulouse, France
  • Nicolas Sarkozy, 2010-04-22 19:59:00
  • Nicolas Sarkozy viewed from ( FILL IN BLANK )
  • Nicolas Sarkozy wearing ( FILL IN BLANK )
  • Nicolas Sarkozy at ( FILL IN BLANK )
  • Nicolas Sarkozy with ( FILL IN BLANK )
  • Nicolas Sarkozy at 2010-04-22 19:59:00 by UserName"
  • Nicolas Sarkozy ( FILL IN BLANK )

Some suggested titles are more appropriate for people, others for buildings or objects. Advantage here is we will not have to make O(n) API calls to find unique suggestions, even client side. And if we build the feature server side we can make it even better.