Files and licenses concept

= Current situation / Introduction = Every page has an entry in the  table, primarily uniquely identified by. Special properties about this page are stored in  per page. 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. Special properties about this page are stored in  per page.

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, 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.

Every file-properties version of a file has an entry 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. Only description, source and additional wikitext (like User-templates and categories) are stored in Wikitext.

= How to get there =

Table structure
Licenses have their own table, (say ). With columns like: lic_id		PRI UNIQ AI, lic_name	VARCHAR 255, lic_url	VARCHAR 255 lic_usage	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 no duplicate rows will be made. mw_file_props contains: fp_id		PRI UNIQ AI, (mw_revision.rev_props_id is a key to this column) fp_license	INT (key to mw_license.lc_id) fp_timestamp	INT(14) fp_author	mediumblob (comma separated plain text list of author(s)) fp_attribution	mediumblob (may be empty or contain wikitext for attribution)
 * < Why keep different versions of file properties ?
 * > Since they contain text and can be edited by many users keeping it all in the Log would get messy (if it fits at all) and doesn't allow rollbacking. By keeping it seperate a change could easily be reverted to the previous revision just like is done for  in   (null-edit, only setting   back to the previous one). And, when viewing a previous revision of a page the proper info from then is displayed.

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.

Perhaps the column  is not a good idea, but a new   to have (multiple) links between a file-id and license-id.
 * What about multiple licenses ? How stored in the database ?

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