Files and licenses concept

to distinguish words from tables, the mw_ prefix is used

= 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 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.
 * mw_page.page_id is used to get info from other tables (like )

= Goal =

Table structure
Licenses have their own table, (say mw_licenses). 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 Example: lc_abbrev		TASL lc_attribution	1 lc_fulltext		0 lc_sharealike		0 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: lc_abbrev		CC-BY-SA-3.0 lc_attribution	1 lc_fulltext		0 lc_sharealike		1 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: 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-{lc_abbrev}-text] ] which contains wikitext.
 * $1: author (mw_file_props.fp_author)
 * $2: attribution (mw_file_props.fp_attribution, if NULL, same as author)
 * $3: title
 * The title of the licenses are stored in [ [MediaWiki:License-{lc_abbrev}-title] ] which is plain-text.

Management


would be a good recommendation for an extension installation. If this concept is built into core though, it'd make a good default.
 * Lists all licenses, allow editing them on pages like [ [Special:LicenseManager/12] ] (by id, like AbuseFilter)
 * Since the actual text is stored in UI messages, they can contain a template if it is desired to allow non-sysops edit them. Since properties like whether or not attribution is required are rarely altered and can only be performed by users with the licensemanager-modify. By core nobody has this right, something like:
 * Changes, creations and removals of licenses are publically logged at Special:Log/licenseman.
 * Removal only possible if not in use. In the event a file previously using it would be reverted to a state where it uses this one again, it would display  or perhaps )

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|license-CC-BY-SA-3.0-title
 * 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_licenses.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 Wikitext could look like:

Author(small textarea), Date (date picker, eventually should contain 14-int timestamp - jQuery datepicker features a way to prevent other symbold from being entered + do serverside check that this is a valid timestamp), License (dropdown + button to add/remove one) and Attribution (small textarea> are kept outside of wikitext in their own respective fields (fetched from and saved to ). For these fields seperate input fields are editable . When saving a null-edit is saved (like when moving or protecting the page) and the properties are stored in the file props table.

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... =
 * What about locations ? Kept how and where ?
 * 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 ?.
 * Camera location could fallback to EXIF data.
 * What about multiple licenses ? How stored in the database ?
 * Perhaps not in  after all, but in a new   to simply allow multiple links between a file-id and license-id.