On 26.03.2012 22:02, Brion Vibber wrote:
I'm generally in favor of this plan. I haven't
looked over the specific
code experiments yet but the plan sounds solid.
YAY!
* over time we'll want to do things like migrate
File: pages from 'plain
wikitext that happens to have an associated file' to 'structured data about
a file'. This will be magnificent.
I hope to get the WMNL guys excited about this idea, this would really rock for
GLAM applications.
* I wouldn't overmuch emphasize things like
"oh you could have pages in
markdown or tex!", though it does sound neat and all. :)
Yes. For the records, i do *not* want to move Wikipedia format to another
syntax. (Well, I wish it *used* another syntax, but that's a completely separate
discussion).
* we need to make sure that import/export round-trips
things consistently,
including for "non-wikitext" stuff. Either that means making import/export
content-aware, or shipping the serialized form through the export XML?
I intend the importer/exporter to use the serialized form, and to be aware only
of the additional revision attributes specifying the content model and
serialization format.
How a wiki should react when importing content for an unknown handler is an open
issue, though. Fail? Import a blank page? Import as wikitext?...
But we don't need to solve that here and now.
As for timing; Daniel's hoping for something in
the neighborhood of an
August deployment. I think if we keep things minimal that should be
feasible; it's somewhat similar to the migration of Image stuff with
MediaHandler classes.
This is because of Wikidata's tight timeline. We'll be working hard on getting
this ready soon.
I'm a bit uncertain about the idea of
'multipart' pages, though attached
data YES YES in some clean way is needed.
That bit is mostly idle musing - "multipart" and "attachments" are
*not* needed
for Wikidata, though they open up several neat use cases.
Thanks for the feedback Brion!
-- daniel