![[Home]](/static/logo.png){kind=logo}
Besides every engines choosen (more or less WikiMarkupStandard compliant) markup, some may choose to support foreign engines TextFormattingRules.
This is useful if pages are to be moved from one Wiki to another in droves, or if users are enabled switch from one to the other more seamlessly.
This feature description is about support of two or more markup variants at the same time – side by side with an engine’s built-in syntax, all within a single edit buffer. A MarkupMode edit time setting would be something different.
MarkupSwitching (by in-page meta option) is also rather wide-spread (TWiki), but also a different thing.
Since most engines use different volumes of custom markup, it isn’t always feasible to fully support it by emulation. Therefore markup would be mimicked only partially (instead of full support).
Emulation can be easy, if the foreign markup to support just uses different text escapes. Then a simply markup-map regex would be run before the local engines formatting kernel takes over to throw out the page.
For example, if the foreign markup to support uses “**” for bold, but the current engines kernel only knows “__” then the obvious solution was to simply s/\*\*/__/g; before (not exact, but that’s how it works).
Many engines support configuration of the used markup (if the mapping is simply configured in a hash/array). Then extending it was fairly simple.
Some engines have multiple formatting kernels to choose from (ErfurtWiki comes with an older PhpWiki markup rendering beast for example). But this does not really allow for support of two markup rulesets at the same time.
| status | wiki engines |
|---|---|
| Implemented | AaWiki, BeWiki, CeWiki, - |
| Developing | - |
| Intend to Develop | - |
| Considering | - |
| Rejected | - |
Foreign markup can be completely incompatible to the local engine ones, therefore making it impossible to support it fully. For example “__” means bold in many engines, will some use “__” for underlined text (a bad idea, btw).
One can only choose one interpretation in such cases.
Of course mapping multiple different TextFormattingRules to the ones understood by the local engine is time consuming at page delivery time. So this whole approach is limited, and MarkupRewriting/MarkupMode at edit time is sometimes the superior technique.
Allowing pages to use multiple syntaxes within a page increases the chance that any given contributor will not be familiar with a particular bit of markup. If the added transformation rules are specified per-page, the opportunities for confusion increase further.
(there was a lot of discussion over such ideas, mainly surrounding the WikiMarkupStandard)