Problems with the use of GRAMMAR
In the translatable pages of translatewiki.net, we have quite many references to translatewiki.net, having varying syntactical contexts and, at least when translated, grammatically declensed forms.
Trying to get them using {{GRAMMAR: some code | {{SITENAME}} }}
is completely futile at the moment, all I get out if it is translatewiki.net
, whatever some code
is.
This applies both to section preview during translation, and the translated page itself.
When inserting GRAMMAR syntax in interface messages:
- message preview does not show the desired results, but
- messages shown in the interface itself do.
(At least, a sample edit of MediaWiki:Summary/ksh did)
Tests outside translatewiki.net lead me to this diagnoses:
- Pages under "page translation" are rendered using the wiki language and its GRAMMAR, regardless of the language of the page.
- Previewed pages are rendered using the wiki language and its GRAMMAR, regardless of the language of the page.
- Interface messages (but not pages in the "MediaWiki" namespace) are rendered using the user language or uselang= language and its GRAMMAR, regardless of the language of the message.
- Also interface message taken from fallback languages are rendered using the user language or uselang= language and its GRAMMAR, regardless of the fallback language.
As one can easily see, all this is unwanted behavior, except in the case of interface messages coming from the user language or the uselang= language.
Well, message previews are meaningless anyway, since they don't reflect the reality and I would just disable the previews altogether (rendering the text as-is) if it was easy to do so.
Now what comes to translated pages, they should indeed be rendered with the target language of the translation. If this is not the case, it is a bug that I need to investigate.
What comes to the third point (disregarding the language of the message), that is a issue in MediaWiki itself, and more specifically a very hard one to fix.
Tested and it works fine with translatable pages.
As to the message preview, there is a special case of preview for specific *.js and *.css pages already. Did you check it for hints hat could be useful for us at twn?
The third point is indeed hard to tackle. I've been at closely related issues for various reasons once in a while, and I believe fixing them all together in one go is easier than trying to solve them individually. My current idea is to convert every rendered string to an ordered list of tupels for internal processing, with each tupel at least having a locale (i.e. language, variant(s), script), directionality, joining behavior, and content. That would also require attaching those properties to wiki pages proper, offering an opportunity to do away with "title/xzz" hacks if a wiki chooses to do so.