I believe we have to separate the internal from the visual representation here.
Wiki is about ease of use. Two edit windows instead of one will do nicely. Things with drop-down, list and check boxes scare newbies away easily.
IMHO, we should leave the meta information in the article text for now, but display them in two different edit boxes, and paste them together again upon saving.
Later, we can change the internal representation in the database, while keeping the "easy" display.
Magnus
Erik Moeller wrote:
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 _______________________________________________ Wikitech-l mailing list Wikitech-l@Wikipedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l