Community
Participate
Working Groups
Some structures allowed by MediaWiki are not supported by the TemplateProcessor class of WikiText. == Support for multiple line templates == In MediaWiki it is allowed to split the template over multiple lines. Template name: test Template markup: _{{{1}}}_ === Example 1: === one {{test| xxx}} two Is expected to be expanded as: one _ xxx_ two === Example 2: === {{ test|xx zz}} Is expected to be expanded as: one _xx zz_ two == Restrictions on detection of parameters name == It is possible to define parameters name as {{Template|param1=test}}. WikiText uses the presence of character “=” to trigger a parameter name. This do not work in all cases. === Example 3: === one {{test|xxx [http://site.com/?keys=foo|bar link] zzz}} two Is expected to be expanded as: one _xxx [http://site.com/?keys=foo|bar link] zzz_ two == Support for included templates == It is possible to include templates in templates. This is not addressed in the current WikiText implementation. Additional template definition: Template name: bar Template markup: +exp+ === Example 4: === one {{test|and {{bar}} include}} two Is expected to be expanded as: one _and +exp+ include_ two
I will provide a test suite and a implementation proposal in Gerrit.
I just pushed a first implementation into gerrit [1] as base for discussion. [1] https://git.eclipse.org/r/7426 The test-cases described in this bug (an others) are contributed in TemplateProcessorTest. == Support for multiple line templates & support for included templates == I did not come clear with regex. I am not sure if it is possible to match stuff like {{xxx{{yyyy}}xxx}} with all possible combinations {{xxx{{yyy{{zzz}}yyy}}xxx{{www}}xxx}} So I added tow classes: PositionFinder, SubstringFinder See the Unit Test classes PositionFinderTest, SubstringFinderTest to see what they are responsible for. As pointed in this question [2], an other possibility would be to use a library like JParsec [2] http://stackoverflow.com/a/10774702/91497 == Restrictions on detection of parameters name == For the moment I check if the name matches “[a-zA-Z0-9_ :]+”: to decide if it is a parameter name or not. See: possibleName.matches("[a-zA-Z0-9_ :]+")) An other approach would be to exclude the pipe symbol “|” between other pattern (I can think of "{" and "}" or "[" and "]". There is maybe more to exclude).
> An other approach would be to exclude the pipe symbol “|” between other pattern > (I can think of "{" and "}" or "[" and "]". There is maybe more to exclude). I ment “=” (because that is the trigger char to look for to decide to go with "<name>=<value>" instead of just "<value>").
Support for multiple line templates (see Example 1 and Example 2 in comment #0) are also requested in Bug 337537: [mediawiki] Can't handle multi-line templates
Jeremie, do you have a concrete use case driving this change?
I have developed these modifications for the conversion of the Scout Tutorials into Eclipse Help format: * http://wiki.eclipse.org/Scout/Tutorial/3.8/HelloWorld * http://wiki.eclipse.org/Scout/Tutorial/3.8/Deploy_to_Tomcat * http://wiki.eclipse.org/Scout/Tutorial/3.8/Minicrm I do not use the ant task to achieve this because I have downloaded the MediaWiki pages locally (for other reasons). After this I wanted to consume the downloaded pages. So I start to code a small tool that is built on top of WikiText (it is not so clean, because I also used internal classes of Wikitext). To fix the stuff that was not working for me, I have hacked the proposed changes into my tool (MediaWikiLanguageExt and TemplateProcessorExt). My motivation for to open the bug was: * If you hack an open-source library, try to fix it (instead) * Stay near to the MediaWiki engine. I am aware that my patch does not exactly fit into the Wikitext codebase, but it does the job. I pushed it as a base to start a discussion. As you can see some of my modifications (like support for multiline templates) are also required by others.
Closed as part of backlog clean-up. Please re-open if you'd like to see this revisited, perhaps with a contribution.
I reopened this bug. This is a real productive problem. I know that my proposed solution doesn’t fit into the code base (regular expression are used everywhere, and my SubstringFinder insn’t based on top of RegEx). On the other side, according to this stackoverflow question [1], it is not possible to detect nested structures with regular expressions. [1] http://stackoverflow.com/questions/546433/regular-expression-to-match-outer-brackets
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
