Files and licenses concept

= Current situation / Introduction = Every page has an entry in the  table, primarily uniquely identified by. Every file has an entry in the  table, identified by.

Every revision of every page has an entry in the  table. A revision is made when the page is created, edited, renamed, or protected.

Every text version of every page has an entry in the  table. If a revision didn't change the text, it keeps referring to the same  row.

Licenses allowed to be chosen during upload are defined at MediaWiki:Licenses. That page is kept as a list –  the last piped part describes the license, everything before that is wrapped between 🇦🇩 on the File-page under a.

Information about the file is stored in the Information-template.

Viewing a file:
 * Page namespace/title is looked up in, and.
 * Information from other tables is retrieved by the page ID

= Proposed situation = Every page has an entry in the  table, primarily uniquely identified by.

Every file has an entry in the  table, identified by. Special properties about this file are stored in.

Every revision of every page has an entry in the  table. A revision is made when the page is created, edited, renamed, protected or when file props changed. Every revision contains a reference to a file properties version, which may be NULL.

Every text version of every page has an entry in the  table. If a revision didn't change the text, it keeps referring to the same  row.

For every file-properties version of a file there are one or more entries in the  table. If a revision didn't change the properties, it keeps referring to the same  row.

Licenses valid on the wiki are defined in the  table, which is managed from Special:LicenseManager. Since there could potentially be many licenses, the ones choosable from the upload form are are defined at MediaWiki:Licenses.

Information about the file (such as author and license) is stored in the -table and displayed on the File-page through a fixed layout. Description, source and additional wikitext (like User-templates and categories) are stored in Wikitext, only author and license are stored separately.

= How to get there =

Purpose
The purpose of the proposed changes is that it should be easy to obtain the copyright information for a file (bug 25624). The minimum copyright information to obtain is the author and the license. Why this is such a good idea is summarized by the following:
 * Getting information from the API for re-use (ie. WordPress plugin to search images and attribute names automatically in the article)
 * Standardizing file-pages centrally (either by core or by mediwiki-message but not per-page wikitext templates)
 * perhaps for search engines to index files properly by using xmlns:cc-attributes or tags that currently are based on the general license for the wiki text
 * Special File-search with ability to filter by licenses (just like ns0=&ns1&, lic1&lic2; Individual wikis could edit messages (1/2) and put links to search through certain sets of of licenses)
 * Automatically attributing authors (in case of CC-BY-*) in articles and perhaps mention the license (in case of CC-SA-*).
 * Name author in search (See Flickr)
 * what not ?

The following (sub)requirements can be identified:
 * 1) Author and licensing information should be stored outside the wikitext. (todo: explain why storing directly outside the wikitext is better than storing inside the wikitext and extracting later)
 * 2) A list of files by copyright holder should be obtainable
 * 3) Copyright information should be provided by the user at upload
 * 4) Copyright information should be editable
 * 5) Copyright information should be versioned
 * 6) Administrators should be able to define a set of canonical licenses
 * 7) For each license basic information should be defined (name, full title, url to legal code/deed)
 * 8) The display of a license should be localizable

Table structure
Licenses have their own table, (say ). With columns like: lic_id		PRI UNIQ AI, lic_name		VARBINARY 255, lic_url	VARBINARY 255 lic_count	INT When used on the File-page, the following parameters are passed: Example: # Database-entry lic_name		TASL lic_url	http://tasl.org/licensedeed.html
 * The text of the licenses are stored in [[ MediaWiki:License-NAME-text] ] which contains wikitext (where NAME is ).
 * $1: author
 * $2: attribution (, if NULL same as author)
 * $3: title
 * The title of the licenses are stored in [ [MediaWiki:License-ABBREV-title] ] which is plain-text.

# Message MediaWiki:License-TASL-text This file by $1 is licensed under $3. Please attribute the author as: $2 MediaWiki:License-TASL-title The Awesome Something License Example: # Database-entry lic_name		CC-BY-SA-3.0 lic_url	http://creativecommons.org/licenses/by-sa/3.0/legalcode

# Message MediaWiki:License-CC-BY-SA-3.0-text MediaWiki:License-CC-BY-SA-3.0-title Creative Commons Attribution Share-Alike 3.0 License //reason for title being separated from database is to allow easier translation, example for Dutch: MediaWiki:License-CC-BY-SA-3.0-title/nl Creative Commons Naamsvermelding Gelijk-Delen 3.0 licentie

License management



 * Lists all licenses (may be viewed by anyone ([*]). Editing is done on pages like [ [Special:LicenseManager/12] ] (by id, like AbuseFilter)
 * The actual texts are stored in MediaWiki:-messages, so they could contain a template to allow editing by non-sysops. Since properties like  are rarely altered and prone to abuse, editing is limited to users with the licensemanager-modify right.
 * Changes, creations and removals of licenses are publically logged at Special:Log/licensemanager.
 * Removal only possible if not in use. In the event a file previously using the license would be reverted to a state where it uses this one again, it would display  and categorize internally into a category like Category:Files with previously deleted licenses

Drop-down menu
During upload a license must be chosen from the drop-down menu. The drop-down menu is populated by MediaWiki:Uploader-licenses. The list would render by fetching the keys from MediaWiki-meessages (like MediaWiki:Sidebar does) and output them as as  's, optionally a different description could be given by piping it:
 * ABBREV|(optional)message key or plain text, default: License-ABBREV-title


 * GFDL|GNU Free Documentation License (Version 1.2 or later)
 * CC-BY-SA-3.0|message-key
 * CC-BY-3.0

Table structure
Meta data about the file itself is still kept in the  table. Page content information is still kept in  and.

Information about the file as a work is kept as a property either in the new.

The  is similar to the   table in that it is kept per revision and only updated when needed.

A reference to the current file props is kept in the appropriate  rows, just like it keeps a reference to. When either doesn't change the reference is kept and so duplicate sets will be made in mw_file_props. mw_file_props contains: fp_id		INT (mw_revision.rev_fileprops_id is a key to this column) fp_key		VARBINARY(255) fp_value_int	INT fp_value_text	VARBINARY(255)

EXAMPLE

This file has three authors: Krinkle, Catrope (attributed as Roan) and John Doe (not a wiki user). And is dual licensed.

Management
An example of what the Wikitext of a File-page could/would look like:

The following elements: jQuery datepicker features a way to prevent other characters from being entered also do serverside check that this is a valid timestamp) .. are kept outside of wikitext in their own respective fields (fetched from and saved to ). These seperate input fields could be editable in two ways: When saving properties a revision is saved (like when moving or protecting the page) with the same   but with a new reference in   to the added row in  . Like wise when saving altered wikitext a revision is saved with the same   but with a new reference in   to the added row in.
 * Author (small textarea)
 * Date (date picker, eventually should contain 14-int timestamp
 * License (dropdown + button to add/remove license (multiple licenses are allowed)
 * Attribution (small textarea)
 * Either on [ [Special:FileProperties/File:Example.jpg] ]
 * Or in additional form elements above or below the textbox on the action=edit page

Idea: A user setting in the preferences decides whether the user sees his own language's description (if available - like {&#123;LangSwitch }} ) or all descriptions.

Display
When viewing a file-page the page is built like: [ [MediaWiki:Fileinformation-template] ] ($1: description (tag-hook), $2: source (tag-hook), $3: author (file props), $4: license-titles (mw_file_props or mw_licenselinks), $5: additional wikitext (all other page text (such as problem tags or user templates) that wasn't filtered away(for example, category and interwiki links are filtered from output))
 * Automated page generated like this.
 * Layout is fixed (perhaps allow editing the layout in a MediaWiki-message, or dont and instead provide sufficient CSS-hooks).
 * Automated page generated like this.
 * Layout is fixed (perhaps allow editing the layout in a MediaWiki-message, or dont and instead provide sufficient CSS-hooks).
 * Automated page generated like this.
 * Layout is fixed (perhaps allow editing the layout in a MediaWiki-message, or dont and instead provide sufficient CSS-hooks).
 * Layout is fixed (perhaps allow editing the layout in a MediaWiki-message, or dont and instead provide sufficient CSS-hooks).

__EMBEDMETADATA__ $1 ...


 * $3


 * $4


 * $2

...

$5

= Hm... = Could go into mw_file_props as well.. Location should be stored as coordinates but a way to convert it to text (ie. get "Amsterdam, The Neterlands" from "52° 22' 56.3" N, 4° 54' 39.2" E") when viewing the page needs to be found. The edit-page could feature a map with a pin (optionally two pins, one for object and for camera location) - something with OSM ? See also Flickr's thing when uploading.
 * What about locations ? Kept how and where ?

Camera location could fallback to EXIF data.

Some kind of detection is required to fallback to the old way (ie. don't render the new file-page layout, but as a normal page). The easiest way to detect if a page has been converted from Information to the new system is to check if a filepage has NULL in  (ie. has no entry in  ), then it is an old-style file. In that case, we don't generate the File-page layout, but just parse the wikitext the good ol' way and display it on the page.
 * Transition