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