Page MenuHomePhabricator

Wiki markup used in "tpt-languages-separator" translation is not interpreted by parser
Closed, DuplicatePublic0 Estimated Story Points


Reported at

Shots of$wgAllowExternalImages

Interface languageContent languageResult

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 28 2019, 7:26 PM

Going to$wgAllowExternalImages?uselang=qqx to get the ID of the strings and then going to you can see that the wiki markup is literally '''·'''.

Not sure if tpt-languages-separator is supposed to allow including wiki markup when being parsed...

Upstream is currently different, see

For the records, I've already had a not very helpful related conversation about the reasons for this in T226312.

Aklapper renamed this task from Language display issue in French ('''s rendering?) to Wiki markup used in "tpt-languages-separator" translation is not interpreted by parser.Jun 28 2019, 7:52 PM
Wladek92 added a comment.EditedJun 28 2019, 9:05 PM

I noticed also that if I select english in the very top banner of the page (near username). And then in the box Other languages I select French then the top banner updates AUTOMATICALLY and switches to français . waow !!!!

Going farther: I select ENglish in the top banner, and Oherlanguages = russian then the top banner switches to Français .... waow !!!

Similar behaviour with page :

BUT other pages are OK when they do not display the 4 squares of translation progression =>

Wladek92 added a comment.EditedJun 29 2019, 8:30 AM

Sounds better replacing
<languages/> by {{Languages}}
but I m a bit lost of what to use exactly.

This looks like some kind of experiment by @Verdy_p: where a broken value got deployed to the sites.

This looks like needless customization to me and I suggest just going back to the default value.

Verdy_p added a comment.EditedJul 1 2019, 9:54 AM

No it was made to be consistent with other lists in many places of the interface.

The fact that bold was not correctly displayed is unexpected,

When I saw it was not rendered correctly, I had already reverted it.

This is actually a bug in the code using that resource, which does not treat it as wikitext (like almost all other resource) but as plain-text only.

So it was NOT an "experimentation", that value was really correct and intended to be the best value. It was just incorrectly used by the wiki.

Also the "big bullet" is actually much too bold in horizontal lists, it obscures the text.
These big bullets are only suitable for vertical lists. The "default" value is then bad. Note that the vertical line used in some other lists of the interface (notably in categories) is also bad (the vertical line is confused with actual letters of some scripts).
The middle dot is correct ONLY if it is surrounded by spaces and distinguished for some other dors used in some scripts. Note that the middle dot may now be used in French in the middle of words (notably for the "inclusive orthography" noting masculine + feminine), making it a bit bolder (but still not the ugly very bold "bullet") and surrounded by spaces avoids all confusions and still has a good interpretation as a punctuation separator.

Also I don't see any interest of using the very bold "standard bullet": there's also a thick separator introduced by the 4/4 colored icon.

Finally another reason is that the 4/4 icon is also very ugly: it should be dropped in case of completion of the translation (i.e. the green 4 squares), making it visible only for uncomplete ones, just to signal to users that the link goes to an uncomplete page.
We would then cleaner lists once translations are completed, only separated by tiny bold middle dots, and not with the bold bullet. The icons and the "big bullet" are both undesirable for standard navigation