Last modified: 2011-03-18 18:02:54 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.
(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?
(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).
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.
(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.
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.
You can use <code> and limited CSS with <span> in wiki text. You can also use to get a non-breaking space.
(In reply to comment #6) > You can use <code> and limited CSS with <span> in wiki text. You can also use > 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.
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.
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.
(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.
(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)
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.)
*** This bug has been marked as a duplicate of bug 2453 ***
(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 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.
