Jesse Martin (Pathoschild) skrev: Yes, thanks, I was only a bit surprised because I expected that also in the above example one would have to "explicitly enforce" transclusion (using a colon) when (and only when) the title wasn't part of the Template:Namespace, like so: {{:../../foo/bar}} That it would work *without* a colon, within the template namespace, wouldn't have surprised me, though. =) Regards, // Rolf Lampa

Thomas Dalton skrev: <...> No. If the rule is that {{: enforces transclusion, and {{/ is a relative (sub) page, why wouldn't I assume that correct syntax for transcluding a sub page, using a relative reference to the sub page, would have this syntax: {{:/Sub title}} I would expect the parser to fill in the rest, namely {{:Namespace:PageName/Sub title}} Yes, that's a "relative" reference to a sub page. I have no problem with that. I'm also convenient with the syntax {{title}} - without a leading colon - for titles in the Template: namespace. And it also seems like a good idea to use a colon to "enforce" transclusion, like so {{:Title}}, for any other namespaces than Template. However, what seems to me to be a bit inconsistent is that you don't need the leading colon for the special case of transcluding sub pages. That part surprised me a bit. Why shouldn't I, based on the other rules, expect to use this syntax for transcluding the sub page : {{:/Subtitle}} ? If the colon means "explicitly enforcing transclusion" it seems intuitive to use it also in this case. What am I missing? However, I can live with this syntax. I only need to know if there are no more syntax variants allowing, or enforcing, transclusion. Again: - Are there more syntax constructs to regard when trying to mimic[1] transclusion /expanding templates? Any syntax is OK, as long as it correctly describes the actual syntax. =) Regards, // Rolf Lampa [1] - Using Delphi.

Thomas Dalton skrev: OK, then the syntax makes a lot more sense. I simply had got it wrong then, somehow. However, thanks for correcting me, it'll make quite a difference to the logic for expanding templates... :) Regards, // Rolf Lampa

Simetrical skrev: Thanks, yes, it seems like I'll have to look into the actual code. I noticed when debugging, and after all the magic words were processed, of which I thought I had covered all, that there were (amazingly enough) still some look-alike template calls in the code but which are "non templates". In other words; it seems like I have not yet found /all/ the (undocumented) magicwords, after all... Regards, // Rolf Lampa

Simetrical skrev: <nowiki> is a bit tricky. Although I have no intent to actually parse the text for human visualization (Mediawiki does that the best) I'm in need of being able to Expand templates as a preparatory stage for analysis of content and also for producing sql for import into a Sphinx indexing db, etc. However, I still need to "disable" some syntax, typically <nowiki>{{</nowiki> etc, used for "disarming" template calls, pipe chars etc. Yes, these must be handled, they modify content quite significantly. I do handle these according to MW logic though. It took me a while to figure out how though, a bit tricky when they're nested, in all kinds of arbitrary order... but I solved this. Yes, I handle the ones which are/can be used for building param values and template names, thus affecting my ExpandTemplate method. Well, also quite a few have significance for content to be indexed. But apart from that the rest is "stripped" and reinserted after expanding. =) Yes, it is. But soon I cover all the essentials for being able to produce text for indexing, and other content analysis of the text. The tool also produces all the "<name>links tables (into sql format) directly from the dump. With all the significant output options for the sql format, like *size* (instead of number of rows) for extended INSERTs, Keys off, IGNORE (duplicates) etc. Also the Utf8-->Ansi conversions can be "shifted" in both "directions", for VarChars and Blobs independently, that is, an integer (+/-, full range) determines how many "steps" to convert the texts... Challenging yes, but interesting. :) Regards, // Rolf Lampa