Last modified: 2011-12-14 17:37:35 UTC
Created attachment 8403 [details] Screenshot of private wiki (useskin=Modern, uselang=ksh) section of Special:Preferences looking pretty garbled. Suggested solution: Give up trying to have a tabular layout which is not working anyways, and does serve a decent i18n. Rather make the page layout linewise where each topic is in a single table cell as wide as the screen/window, or wrap each topic in a paragraph on its own. If there are consecutive very similar rows, they line up in the same fashion anyways.
Created attachment 8405 [details] Complete screenshot of modern/ksh
I tried it on translatewiki.net, but I don't see the problem (other than the <i lang="en"></i> tags showing up raw on the page, which is a seperate bug). What version of MediaWiki are you running ?
Svn, maybe less three days or so. Your screen shot is much wider than the one I was using. Could you try to shrink it to, say, the half - making the two checkbox legends line wrap two, rewspectively three times, as it is in my screenshot? I suspect also different font handling between the two screenshots. I made mine on debian Linux with Iceweasel 3.0.6 (a firefox clone) (The <i lang="en"></i> tags showing is indeed a separate isuue. It is one of the numerous cases described in http://www.mediawiki.org/wiki/I18n#Expect_untranslated_words that we can only gradually squeeze out with improved i18n handling)
How exactly is this garbled? The only thing overly wrong with it that I see with a cursory look is the <i lang="en">blah</i> which you said was a separate issue. (Shouldn't we have a system where people don't add html to messages not supporting html?)
(In reply to comment #4) > (Shouldn't we have a system where people don't add html to messages not > supporting html?) Usually it should be the other way round. See for example bug 14107. We have places where markup does not work per rules or technical constraints outside our scope. There we should indeed filter it intelligently, and in most instances, we already do. Otherwise, needed markup, such as language tagging, setting directionality, and similar, must be working. The goal cannot be to keep people from making correct localizations, but to gradually get rid of obsolete and in part broken message string handling code.
