Last modified: 2011-03-18 18:02:54 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 8521 - Show HTML support status in MediaWiki messages
Show HTML support status in MediaWiki messages
Status: RESOLVED DUPLICATE of bug 2453
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-07 18:18 UTC by Danny B.
Modified: 2011-03-18 18:02 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Danny B. 2007-01-07 18:18:34 UTC
It happens many times, that somebody is trying to edit any message and improve
it with HTML code, but nither preview nor saved page shows the result as a
plaintext unlike the usage of such message does.

Therefore some notice in the style of "This message (does not) support(s) HTML
coding" somewhere before edit window would be very handy to prevent accidents.

On the other hand I don't quite understand, why messages shouldn't support HTML
coding - it lowers down usability a lot.
Comment 1 Rob Church 2007-01-07 18:21:13 UTC
(In reply to comment #0)
> Therefore some notice in the style of "This message (does not) support(s) HTML
> coding" somewhere before edit window would be very handy to prevent accidents.

This information is not currently available in any easy-to-check fashion.

> On the other hand I don't quite understand, why messages shouldn't support HTML
> coding - it lowers down usability a lot.

So we should abandon wiki text for articles?
Comment 2 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-01-07 19:39:47 UTC
(In reply to comment #1)
> This information is not currently available in any easy-to-check fashion.

. . . because the decision is currently made by the caller, not the message.

> > On the other hand I don't quite understand, why messages shouldn't support HTML
> > coding - it lowers down usability a lot.
> 
> So we should abandon wiki text for articles?

I think he was saying "*not* allowing HTML lowers usability".  I don't know
offhand why some messages don't allow HTML (many don't allow wikitext because
that takes too much time to parse, of course).
Comment 3 Rob Church 2007-01-07 19:55:49 UTC
Please give an example of a message where HTML is not accepted, but where it
would be useful. Long explanatory messages should use wiki text, which all users
are able to use. Labels, captions and the like should use plain text, because
the appropriate place to format them is in CSS. Outputting things without
escaping them is often frowned-upon.

In general, allowing arbitrary HTML in messages is not a particularly brilliant
idea; a user may be a sysop, but may not be able to write valid XHTML, which
really doesn't help when Tidy is not enabled on message parses.

Note that I am not necessarily opposed to the original resolution, nor am I
particularly opposed to using HTML where it is appropriate.
Comment 4 Danny B. 2007-01-08 00:37:42 UTC
(In reply to comment #3)
> Please give an example of a message where HTML is not accepted, but where it
> would be useful. Long explanatory messages should use wiki text, which all users
> are able to use. Labels, captions and the like should use plain text, because
> the appropriate place to format them is in CSS. Outputting things without
> escaping them is often frowned-upon.
All messages which not accept XHTML and are NOT wrapped in any element which
could be simply and crossbrowser accessed via CSS or JS can be used as an example.
So until all the messages are properly wrapped and easy accesible (= precisely
used class and id attributes), allowing of XHTML is pretty necessary. And even
after all of them will be wrapped, there is still lot of needs:
We should not forget about additional informational attributes which does not
have any equivalent in wiki markup such as title, which is very important.
Also changing of language can appear in the text (especially when using original
english terms in non-english messages) and is supposed to be properly marked
which can be done via (xml:)lang attribute.

> In general, allowing arbitrary HTML in messages is not a particularly brilliant
> idea; a user may be a sysop, but may not be able to write valid XHTML, which
> really doesn't help when Tidy is not enabled on message parses.
I don't fully agree with this statement. Most probably the sysop who doesn't
know basics of XHTML will not even touch messages or at least will use plaintext
instead. Sure the default message should be as much plaintext as possible, but
on the other hand the software should not disallow improving of it, which
actually happens when XHTML can't be used.

> Note that I am not necessarily opposed to the original resolution, nor am I
> particularly opposed to using HTML where it is appropriate.
I think I showed some reasons for allowing XHTML in messages in general and
together with the fact that the defaults should be the simpliest possible of
course (which could be set as a guideline for creating/localizating of messages)
I think this can be taken as a compromise between both sides of backers and
opponents of XHTML.
Comment 5 Danny B. 2007-01-17 16:57:39 UTC
Found another examples speaking for allowing of using of XHTML:

The text is supposed to be properly semantically marked, so for example there
should be <code> tag around any piece of code in text as well as <abbr> <var>
<q> or so.

Another thing is markup of part of the text to be emphasized certain way than
only bold/italic (eg. different color etc.). Impossible with wikisyntax.

Another example - non breaking space - if being inserted as UTF character, it's
converted to regular space, so without XHTML support there's no chance to get it in.
Comment 6 Rob Church 2007-01-17 17:00:00 UTC
You can use <code> and limited CSS with <span> in wiki text. You can also use
&nbsp; to get a non-breaking space.
Comment 7 Danny B. 2007-01-17 17:20:51 UTC
(In reply to comment #6)
> You can use <code> and limited CSS with <span> in wiki text. You can also use
> &nbsp; to get a non-breaking space.


Apparently can not use <code>. Check
http://cs.wikipedia.org/wiki/MediaWiki:Expand_templates_title in
http://cs.wikipedia.org/wiki/Speci%C3%A1ln%C3%AD:ExpandTemplates 

This page used to be OK until somebody turned off the XHTML support in some of
those messages.

And I had the whole bunch of similar issues. <span> also did not work - check
http://cs.wikipedia.org/w/index.php?title=MediaWiki:Rc-change-size&oldid=1096961
the entire message (except for substitution of wiki and $1) appeared as plaintext.
Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-01-25 23:51:20 UTC
HTML is enabled wherever wikitext is.  If <code> and <span> are disabled, so is all wikisyntax.  
So I don't understand your point about XHTML support.
Comment 9 Brion Vibber 2007-01-26 00:15:15 UTC
Messages come in roughly four varieties:

* plaintext
* raw, unfiltered HTML
* wikitext
* _other things_ (special lists like the sidebar, page titles, etc)

Something like <a href> will make a link in HTML, but not in wikitext, where you
use a different construct.
Comment 10 Rob Church 2007-01-26 09:55:03 UTC
(In reply to comment #9)
> * plaintext

In general, used for small things, e.g. labels on forms, button captions,
interface link labels, etc.

> * raw, unfiltered HTML

In general, we should probably cut these messages down to an absolute bare
minimum, deciding on either plain text or wiki text as appropriate.

> * wikitext

Used for large blocks of text, e.g. explanatory stuff, or where formatting may
be otherwise desirable.
Comment 11 Danny B. 2007-01-28 21:36:28 UTC
(In reply to comment #8)
> HTML is enabled wherever wikitext is.  If <code> and <span> are disabled, so
is all wikisyntax.  

That's not true (or there's a bug :-)).
http://cs.wikipedia.org/w/index.php?title=MediaWiki:Rc-change-size&oldid=1096961
wikitext properly expanded, but HTML treated as plaintext. Not even simple &
nbsp; (when I tried $1& nbsp;B) was converted.


(In reply to comment #10)
> (In reply to comment #9)
> > * raw, unfiltered HTML
> 
> In general, we should probably cut these messages down to an absolute bare
> minimum, deciding on either plain text or wiki text as appropriate.

I absolutely disagree - I've shown a bunch of examples in comment #4 or comment
#5, why XHTML _IS_ necessary, but unforunately haven't seen any, why it should
be disallowed.

Please, don't think in English only. Keep in mind, that different languages have
different rules of text formatting or other stuff.

As I've said in comment #4: For sure, the default messages should be the
simpliest possible (which could be set as a guideline for creating/localizating
of messages), but on the other hand there is no sensible reason to cut down the
functionality especially when there's no other way, how to get such feature in.

Allowing of XHTML in messages doesn't mean "use it! you must!" - it means "use
it, if you need it for something you can't do with wiki markup". By allowing of
XHTML we're not pushing anybody to use it, but just simply adding more useful
value to the software.


PS: (gaps in entities after & are here because I don't know how they would be
rendered/converted here, so to be sure they'll remain visible)
Comment 12 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-01-28 23:31:58 UTC
Hmm, my bad.  There's an 'escape' option for wfMsgExt.  I don't know why we would ever want to 
allow wikitext but not safe HTML.  (Entities will be escaped here, BTW.)
Comment 13 Niklas Laxström 2009-02-28 18:43:06 UTC

*** This bug has been marked as a duplicate of bug 2453 ***
Comment 14 Purodha Blissenbach 2011-03-18 18:02:54 UTC
(In reply to comment #3)
> Please give an example of a message where HTML is not accepted, but where it
> would be useful.

1) Almost all messages can use &entities; without causing trouble.
   It is convenient for coders and translators, and they could almost always
   easily and safely be converted to their UTF-8 equivalents during
   automated message processing, and even be rewritten into message source files.
   Only &nbsp; should be kept so as to be visible for those working with
   the messages.

2) Some HTML elements need to be supported for i18n in all messages that
   are rendered as HTML (outside angle brackets)

   I am aware of those cases (there may be many more):

   <i lang="en"> untranslated or untranslateable technical term or name </i>
   <span lang="en"> untranslated or untranslateable technical term or name </span>
   <code lang="en"> untranslated or untranslateable parameter or file name </code>
   <span title=" explanation or expansion "> abbreviation or short term </span>

   Of course, one could as well use <arg> <var> <abbr> or <tt> where there is fit.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links