I believe we need to start thinking about ways to better separate content
and metadata. Making them editable separately, and perhaps making either
type of content filterable, gives us room for expansion in the meta realm
without impacting editability for users who just want the plain text.
Current meta-tags:
* interlanguage links
* __NOTOC__
* __NOEDITSECTION__
* category links (experimental)
Possible future meta-tags:
* <editnote> - shown on top of the edit box during editing, e.g. "Please
describe new events in the present tense"
* <sizelimit> - for auto-archiving or size warnings
* __NOCACHE__
* __NOTITLE__, __NOSUBTITLE__ for navigational pages, Main Page
* [[Edition=Print]] and other name=value tags
* .. anything else that would be useful, but clutter on the article page
I see two possibilities, one of which I call the hackish approach and the
other the clean approach.
== The hackish approach ==
Add a new tag, called <meta>. Content within <meta>..</meta> is shown in a
separate window, like this:
<pre>
_________________________________________
| |
| The PURINA brand of dogfood is very |
| tasty. Critics allege that it is made |
| of harvested souls from children |
| in the third world. |
|_________________________________________|
_________________________________________
| [[de:Fnord]] [[simple:Wormwood]] |
| __NOTOC__ [[Category:Dogfood]] |
| <editnote>Do not edit after dark</editn |
|_________________________________________|
[ SAVE ] [ PREVIEW ]
</pre>
There would be an option to hide meta-information during editing, and one
to use the old (single-window) behavior.
The meta-content would be part of the regular cur_text, it would be simply
concatenated with it / split away from it on demand.
Advantages:
* Relatively easy to implement
* single diffs for edits that change meta content and article content
Disadvantages:
* regular editing can still cause edit conflicts with meta-editing
* no easy filtering of meta-editing from RC, diffs
== The clean approach ==
It would of course be cleaner to separate meta-content in the database. If
we desire to do this, we should do it as part of the pending database
redesign. In this case we would have a text blob and a meta blob which
could be edited separately without conflicts. Any edit of a text or meta
blob would result in an entry in the recent changes log.
The most problematic effect of this change would probably be on the page
history. Again, the most logical approach would be to list a change to
either meta or article-content in the history, but perhaps in separate
color.
Disadavantage:
* requires table redesign, might affect quite a few pages
* more difficult but not impossible to maintain single window behavior
* complicates diffs, esp. summary diffs
Advantages:
* makes it easy to filter meta-edits from RC, history
* meta-edits cannot cause edit conflicts with regular ones
* storing and retrieving the different types of data is a lot easier and
less error-prone
== Thoughts? ==
I think before we go any further into the meta area, we need to clean up
the separation, otherwise we'll end up confusing newbies. I'd appreciate
feedback on how to do this.
Regards,
Erik