Features / TODO

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.

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 }

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.