Interwiki rule by Text_Wiki
bertrand Gugger <[email protected]> Sun, 19 Feb 2006 11:12:21 +0100
| Newsgroups | gmane.comp.php.pear.devel,gmane.mail.eyebrowse.user |
|---|---|
| Message-ID | <[email protected]> |
Hello, Still working out a better integrated Wikilink / Image / Interwiki rules parser, I stumble against the following Interwiki problem. By Mediawiki, Interwiki are done as [[otherwiki:page]] otherwiki adressing a table, Interwiki Map, similar to the render configuration "sites" we have by Interwiki rule. The difficulty is that the [[prefix:something]] has a fairly wider use (roughly): * namespace: prefix is then a part of the page name, * special namespace as Image, Talk, User, Special ... * interwiki or sister projects, * interlangage link: it links to the corresponding page in a different langage, * ... or a combination of them. (next Mediawiki parser will treat in a once Image, Wikilink and Interwiki) Then, obviously, it has to be proceeded by the parsing time and not, as we do currently, by the rendering. Generaly, it seems to me that this is much more natural, I don't understand why the "sites" list belongs to the render configuration. Proof of concept: for the 3 basic renders: you have to duplicate this configuration between Xhtml and Latex, Plain simply ignoring the url translation and outputing the interwiki keyword (?). As any duplication this leads to extra work by configuration and possible inconsistency. I plan to introduce the possibility to have the url transcription done by the parser. In order to keep the BC , means still use the render configuration by existing installations, the existing token's option "site" will still run the same but a new option "url" will be added. Case this one exists, renders will use it, else function as usual. As a note, "site" is anyway necessary for wiki renders (converters), these ones should not use the url translation. This extra token option "url" will be in a first time produced only by the Mediawiki parser, and hopefuly ported to other parsers, prioritarly the Default one (in order the next release to be consistent). The progressively, implementers may want to comute to the new, by parser, configuration. Any thought ? objection ? à+ -- toggg -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php