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 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: lc_id		PRI UNIQ AI, lc_abbrev	VARCHAR 255, lc_attribution	tinyint(1) unsigned, lc_fulltext	tinyint(1) unsigned, lc_sharealike	tinyint(1) unsigned When used on the File-page, the following parameters are passed: Example: # Database-entry lc_abbrev		TASL lc_attribution	1 lc_fulltext		0 lc_sharealike		0 # 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 lc_abbrev		CC-BY-SA-3.0 lc_attribution	1 lc_fulltext		0 lc_sharealike		1 # 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
 * The text of the licenses are stored in [[ MediaWiki:License-ABBREV-text] ] which contains wikitext (where ABBREV 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.

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 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 titles from [ [MediaWiki:License-{lc_abbrev}-title] ] (kinda like MediaWiki:Sidebar does) 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-SA-2.0

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

Information about the file as a whole is kept as a property either in the existing  or in a new   (will refer to this as ' ' for now).

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


 * Reason for re-using : No new table
 * Reason for creatingh new table: Doesn't break  becuase it would become revisionised.

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 are editable on . When saving properties a revision is saved (like when moving or protecting the page) with the same   but with a new reference 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)

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 (file props or licenselinks), $5: additional wikitext (all other page text that wasn't filtered away)
 * 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 when viewing the page needs to be found. The editor could feature a map with a pin (optionally two pins, one for object and for camera location) - something with OSM ?.
 * What about locations ? Kept how and where ?

Camera location could fallback to EXIF data.

Perhaps not in  after all, but in a new   to simply allow 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 file-page layout, but as a normal page). If a filepage has NULL in  (ie. has no entry in   it is an old-style file. In that case, don't generate the File-page layout, but just parse the wikitext and display it on the page.
 * Transition