Talk:Page metadata

The first sentence below the Table of Contents made no sense
"For each type of meta information, a new DB table of cur and old is required. "

Oh. Now that I see it in typewriter font here in the talk page editor, I see I misread what I thought said "... our and old is required."

It is: "... cur(rent) and old is required." it makes perfect sense. Wb7 23:18, 1 April 2010 (UTC)

Support
We have something very similar on our roadmap as well, see bug 53508. The storage for this is being prototyped and discussed at User:GWicke/Notes/Storage. -- Gabriel Wicke (GWicke) (talk) 01:44, 12 October 2013 (UTC)

Some notes

 * Interwiki links, most templates, and many "external links" are content, not metadata.
 * IMHO Things like protection, construction, copyvio, etc... messages should be part of a series of extensions that display these notices (and do it in cleaner ways). Some of this data is already available to extensions (eg: the protection status). The method of declaring the rest is up for debate.
 * I had an idea for category metadata (easily expanded to interlan interlanguage links not in Wikidata, editable description, etc...) which was well received when I posted it in either IRC or a bug report – can't remember which – but I never got to writing an RFC for:
 * UI editable category metadata should be stored using ContentHandler in a in a Content type's data separate from the wikitext, etc...
 * should continue existing for use by templates (though we may want to introduce a which we would encourage templates to use).
 * The combined category data output by the Content type (wikitext categories + metadata categories) should include a bit of extra metdata on where each category was sourced from (or maybe simply an "editable" boolean).
 * We'll have an editinig UI and api for editing categories.
 * This editing UI will use that extra metadata to display all categories with non-editable ones greyed out to show the user what can and can't be modified through the UI.
 * Random thought I had now. We'll probably add a PHP interface for the Content type (or actually 2 of them; One for category fetching and the other for modification) for the get ("get category", "remove category", "add/set category") operations that the API would use on the Content instance to modify the data before storing. Then we can abstractly implement that on any Content type (we can even have things like JS/CSS/Lua with categories that don't need to written into the text). And use instanceof checks to see if a content type supports categorization and allows categories to be modified abstractly.
 * Daniel Friesen (Dantman) (talk) 07:18, 12 October 2013 (UTC)