Page MenuHomePhabricator

Garbage in Special:Preferences
Closed, ResolvedPublic

Description

Screenshot: Detail of Special:Preferences under Sector skin.

In the Vector skin in Special:Preferences,
there are (a) pieces of html rendered verbatim instead of executed,
and (b) lines of mixed text elements that do not make sense.

See attached screen shot:

  • top line (a)
  • two lines at bottom (a) and (b)

The text:
Beshtätejung Ding E-Mail Adress wood aam <strong>26. Määz 2006</strong> övver e-mail: öm <strong>15:33</strong> Uhr bestätich.

should be:
Beshtätejung övver e-mail:
Ding E-Mail Adress wood aam 26. Määz 2006 öm 15:33 Uhr bestätich.


Version: 1.16.x
Severity: enhancement

Attached:

Vector-preferences-garbled.png (175×639 px, 2 KB)

Details

Reference
bz19820

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:42 PM
bzimport set Reference to bz19820.

(a) Has nothing to do with Vector, happens with all skins.
(b) I said long ago that >|< alignment sucks in Special:Preferences, I'd prefer left-left, and have overridden this in my personal styles.
(c) There is more than one issue in this bug.
(d) a) is because Xml-functions are used. They do not allow any kind of mark-up, and this is known and no fix is currently being implemented.

Andrew, is this a regression in html support or just some custom message formatting that wouldn't work?

(In reply to comment #3)

(a) is an alignment problem, which I do not know to fix with custom CSS (besides the fact that my personal fix woun't help others)
It is also an instance of the fact that translated messages are usually longer than you think.

(b) is yet another issue of the fact that proper language tagging inside some translations is needed - outlined in http://www.mediawiki.org/wiki/Internationalisation#Expect_untranslated_words - and the XML function does not currently allow it, as Niklas pointed ot. If this is seen as good way to do it, I am willing to e.g. add a "let markup pass" parameter to those functions that need it, but I am far from convinced that, making message treatment more complicated was desirable.

Resolved in r53800 (was regression in r53173).