Just my thoughts: in case of a new wiki language: make use of ODF and integrate OpenOffice with MW.
I see somekind of agreement in the reactions, thats a start. :-) Andre Brian schreef: > I thought it was generally agreed upon that the path to fix the parser goes > something like this: > > * Define a new wiki language that is compatible with bison/flex > * Write a converter between the old language and the new (when possible) > * Implement per-revision parsers > * Implement the new parser > * Begin the migration > > On Mon, May 11, 2009 at 1:13 PM, Trevor Parscal <[email protected]>wrote: > > >> On 5/11/09 11:54 AM, Marco Schuster wrote: >> >>> On Mon, May 11, 2009 at 8:50 PM, Daniel Schwen<[email protected]> wrote: >>> >>> >>> >>>> The simple (albeit ugly) solution would to add a parser version field to >>>> the >>>> revision table, drag the old parser along as 'legacy', make the new >>>> >> parser >> >>>> the default (and only) option for all new edits, and spit out a warning >>>> when >>>> you are editing a legacy revision for the first time. The warning you be >>>> made >>>> dependent on the cases that break with the new parser. >>>> Cases that break could be detected by comparing tidied HTML output from >>>> both >>>> parser versions. >>>> >>>> >>> Sounds cool, but it'd require a formalization of MW markup first >>> >> (something >> >>> that should have been done long ago). >>> What about correcting stuff from "old" behavior to new parser via >>> bots/update scripts, even for old revisions? >>> >>> Marco >>> >>> >>> >>> >> During the Berlin conference, a very popular and passionate topic of >> conversation was the need for better testing of MediaWiki. However, if >> we can't define what it's supposed to do, how can we test it. Last I >> heard the parser has yet to pass all of the unit-tests written for it, >> which aren't even very robust. so the concept of the parser's behavior >> being it's own documentation is clearly conflicting with good software >> development practices. This said, any changes to the parser cause a risk >> of breaking old, or even current revisions of articles, which is I've >> noticed to generally be seen as unacceptable. So - this topic is >> probably a justifiably touchy one for those involved in working on this >> software since there's no really elegant solution and lots of complaints. >> >> Seems like there's been some general talk about this idea... >> >> * Link a revision to a version of the parser >> * Allow multiple parser versions to co-exist >> * Provide an upgrade path for revisions to be brought into compatibility >> with a more modern parser >> >> Nothing about this sounds easy, but if we ever want to improve MW markup >> or parser behavior we will need to do something. Is there any support / >> criticism for this direction? I'm very curious what other potential >> directions could be taken which could also result in: >> >> * The parser's behavior being a reflection of a well-documented standard >> * Ability to make changes to MW markup standards over time without >> abandoning old revisions >> >> - Trevor >> _______________________________________________ >> Wikitech-l mailing list >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >> >> > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
