Wikimedia Bugzilla is closed!

Commited to cvs

*** Bug 6691 has been marked as a duplicate of this bug. ***

I don't know why, but this bug is still present in all Wikimedia projects (for example http://commons.wikimedia.org/skins-1.5/monobook/main.css). There are 4 instances of "text-transform: lowercase;" which is simply wrong from my point of view. It's not a task of the "main" stylesheet to decide if a specific text should be in lower case. The main.css should be independent from the language.

This is done for stylistic effect, to remove it would adversely affect many thousands of installations. To avoid this case change simply add

.portlet h5 {
text-transform:none;
}

to your wikis MediaWiki:Monobook.css -- it may be possible to alter this for certain lanaguages in core via the default per-language style sheets which I think works, but it would be irresponsible to change this for all wikis.

Changing text to lower case is more than a "stylistic effect" in many languages. For example, in the German language many words are _wrong_ in lower case.

Adding something to Monobook.css is a short-sighted workaround. This adds unnecessary byte-wasting code for the only reason to override other unnecessary byte-wasting code. Please remove it. Nothing will break except for a few letters that will go upper case. If any installation requires the lowering stuff, _they_ have to add this to their Monobook.css:

#p-personal ul, #p-cactions li a, .portlet h5, .portlet h6 {
text-transform: lowercase;
}

I would be inclined to just go ahead and remove this from the Monobook skin, yeah.  Any objections?

I object. It's a stylistic effect used by that particular skin, not an inherent value of the UI strings.

So is the best solution to override it in MediaWiki:Monobook.css on a case-by-case basis for those languages known to care about case distinctions like that?  Or is there a better one you have in mind?

@Brion: As I said, changing text to lower case is _more_ than a plain stylistic effect. The _result_ looks the same as if the strings in the messages files were in lower case. As I said, this is wrong in some languages. The Monobook skin should be independent from the language.

Couldn't we wrap [[MediaWiki:Navigation/de]] in <span style="text-transform:none">? That way uselang=de would work in wikis of any language, and uselang=en would still work properly on German wikis.

Partial solution may be adding of something like

html[lang="de"] #p-navigation h5
  {
  text-transform: none;
  }

or even

html[lang="de"] #column-one h5
  {
  text-transform: none;
  }

    (I was too lazy to look for proper selectors, so take it with some tolerance ;-))

to /skins/monobook/main.css

However, IE at least till version 6 (I can't test in newer one ATM) does not support it - that's why it's just partial solution. But I guess better than nothing at least for the beginning.

(In reply to comment #10)
> Couldn't we wrap [[MediaWiki:Navigation/de]] in <span
> style="text-transform:none">? That way uselang=de would work in wikis of any
> language, and uselang=en would still work properly on German wikis.

That should work. At least on Testwiki it does (I've tried it on /cs version). Probably the best would be to have it in site default (thus in SVN). However it's not guaranteed it will work forever, since unfortunately one group of developers constantly cuts out HTML support in MediaWiki messages which lowers down its usability... :-/

----

This problem isn't only on German sites (but it's most obvious there) - any other site which would like to put some proper name in sidebar's headlines, would have to override styles as well. I was trying to solve that in bug 6691 and later on in maillist about 2,5 years ago <http://lists.wikimedia.org/pipermail/mediawiki-l/2006-July/013749.html>, however, unsuccessfully :-/ (well, yes - that communication wasn't my best one ;-) but I guess I've brought enough reasons there).

(In reply to comment #10)
> Couldn't we wrap [[MediaWiki:Navigation/de]] in <span
> style="text-transform:none">? That way uselang=de would work in wikis of any
> language, and uselang=en would still work properly on German wikis.

That seems entirely reasonable (maybe using a class instead of inline style, but probably doesn't really matter, since the class would be essentially presentational anyway).  Anyone want to do it?

Implemented in Betawiki.

> --- Comment #11 from Danny B. <danny.b@email.cz>  2008-12-08 11:45:09 UTC ---
> Partial solution may be adding of something like
>
> html[lang="de"] #p-navigation h5
>  {
>  text-transform: none;
>  }
>
> or even
>
> html[lang="de"] #column-one h5
>  {
>  text-transform: none;
>  }

I tried something very similar using :lang, but it only worked if the wiki's language was German. So, it would have worked on the German Wikipedia, but not on the Wikimedia Commons. I was hoping to do something like:

html.uselang-de #p-navigation h5

but MediaWiki does not expose the "uselang" parameter in CSS, so the best thing that I could personally do was add wrappers to the messages via Betawiki.

Never mind, all of the nstab- messages don't support HTML, so this fix doesn't work for them. Knowing that, I think it'd be best to expose the uselang information via CSS, at least for the Monobook skin. Unfortunately, I don't know how to make MediaWiki do that...

For the record, after creating a minor mess at Betawiki I discovered that [[MediaWiki:Navigation]] is the _only_ message that both has this problem and allows HTML in its message.

(In reply to comment #13)
> I tried something very similar using :lang, but it only worked if the wiki's
> language was German. So, it would have worked on the German Wikipedia, but not
> on the Wikimedia Commons. I was hoping to do something like:
> 
> html.uselang-de #p-navigation h5
> 
> but MediaWiki does not expose the "uselang" parameter in CSS, so the best thing
> that I could personally do was add wrappers to the messages via Betawiki.

Keep in mind that it's possible to have a mix of interface languages displayed on a page.  Some messages might be untranslated and fall back to the specified fallback language, and some messages might be forced to the content language on some wikis.  Deciding whether to lowercase on a per-message basis is likely the best idea, if it's feasible.

Personally, I think the best solution might be to get rid of the text-transform rule for all languages.  It's not worth the trouble it causes.

(In reply to comment #16)
> Personally, I think the best solution might be to get rid of the text-transform
> rule for all languages.  It's not worth the trouble it causes.

So why won't we do it? This issue has been around for almost 4 years periodically returning like a boomerang. Many reasons have been given, many examples have been shown in favor of removal while for keeping there is the one and only argument still being repeated round and round: "it's part of the design". Well, yes, it is. And we have good designs and bad designs as well... ;-) Time has shown that this part of the design wasn't the best approach. And if design lowers accessibility or usability it should be changed. Time for change is now...

(In reply to comment #17)
> So why won't we do it?

For my part, comment #7.

As I said in comment #5, changing case is NOT just a stylistic effect. It changes the MEANING of the words in many languages!

I have temporarily fixed this bug with a workaround at betawiki:
http://translatewiki.net/w/i.php?title=MediaWiki:Navigation/de&diff=894296&oldid=892581

The additional code doesn't weigh much, as the very same code now can be removed from [[de:MediaWiki:Monobook.css]] for example.

Note that I do *not* CLOSE this bug, because the actual reason for this bug is that [[MediaWiki:Monobook.css/de]] does not at all get used!

Someone has to find a way to include [[MediaWiki:Monobook.css/de]] into the generated CSS file by software, as currently only the [[MediaWiki:Monobook.css]] file content seems to be send to clients.

Note: Do not @import [[MediaWiki:Monobook.css/de]] in [[MediaWiki:Navigation/de]] (that would break other skins for example)

Fixed that issue with that workaround also for:

* de-formal
* gsw
* bar
* pfl
* nds
* lb
* ksh
* pdc
* pdt

ang (and probably others) has a text-tranform:none declaration in [[ang:MediaWiki:Monobook.css]], but I skipped that (as only German languages are generally capitalised)

Silly question: Why is .portlet h6 defined, actually?
There are no H6 portlet headings!?
Or do some extensions use h6 portlet headings?

If MediaWiki really doesn't have H6 portlet headings by default (what I think), shouldn't
".portlet h6 {...}" be removed from
http://upload.wikimedia.org/skins/monobook/main.css
and 
[[MediaWiki:Monobook.css/de]]?

Forget my last posts, changes have been reverted altogether, broadly.
http://translatewiki.net/w/i.php?title=User_talk%3AMelancholie&diff=894502&oldid=379444

From my point of view:

Fact: A skin MUST be independent from the language.

Fact: Changing text to lower case is NOT independent from the language.

Conclusion: Remove every occurence of "text-transform: lowercase;" from main.css.

Optional: Change the case of the text in [[MediaWiki:Navigation]], [[MediaWiki:Viewsource]] and so on or add "text-transform: lowercase;" to [[MediaWiki:Monobook.css/en]] or do something else, as long as it does not affect all languages.

Just to drop a note [to be aware of]:
As Meta and Commons are *the* major multilingual community wikis, the CSS workaround from above has been placed into [[meta:MediaWiki:Navigation/de]] and [[commons:MediaWiki:Navigation/de]]. Works fine.

Not fine, now Meta is using invalid XHTML: http://validator.w3.org/check?uri=http%3A%2F%2Fmeta.wikimedia.org%2Fwiki%2FMain_Page%3Fuselang%3Dde&charset=%28detect+automatically%29&doctype=Inline&group=0

I've reverted the addition to [[commons:MediaWiki:Navigation/de]] and requested that it be removed from [[meta:MediaWiki:Navigation/de]] as well. We need to fix this problem properly in MediaWiki itself, not by invalidating our code with hacks.

Note that this is only a ridiculous 'nested elements ' error, only shown if a user has specified 'de' as his/her UI language. Is it really necessary to revert this? CSS invalidities do not break anything, in contrast to JS invalidities.

It's not a CSS invalidity, it's an XHTML invalidity, and I'm poring over the MediaWiki source code right now trying to figure out where MediaWiki:Navigation is actually called.

Äh, XHTML of course. But my opinion is that visible issues are more important than invisible/un-severe ones. A (soon) proper solution would be the best though.

XHTML errors can cause tools that parse sites like XML to blow up. We don't want invisible problems suddenly flaring up in odd places.

Created attachment 5656 [details]
Screen shot of English Wikipedia with current lowercase headings/links

For comparison purposes...

Created attachment 5657 [details]
Screen shot of English Wikipedia without text-transform on MonoBook skin

For comparison purposes; English Wikipedia with the text-transforms disabled in the MonoBook skin. It doesn't look much different, and probably wouldn't garner too many complaints. Most people probably wouldn't notice.

Wouldn't hurt to float just removing the text-transforms by default.

Float where?

In the community! Tell your friends, tell your mom, tell your blog, whoever. :)

Note that those words that will be shown capitalized can easily be lowercased again by editing [[MediaWiki:Edit]], [[MediaWiki:Navigation]] etc. See [[wikt:de:Wiktionary:Hauptseite]] for example, where all adjectives on top (tabs) are lowercased. Removing 'text-transform:lowercase' and *correcting* the system messages (if desired) seems reasonable.

"Wiktionary:Hauptseite" had been a bad example (no adjectives ;-) [[wikt:de:example]] is a better one, showing at least "bearbeiten" (if logged out).

> adjectives->verbs (me fool ;-)
sorry for spamming, unfortunately it's no wiki

[[MediaWiki:Edit]], [[MediaWiki:Navigation]] etc. affect all skins, so making them lowercase would make the text lowercase even on skins where uppercase text is more appropriate. CSS is the right tool for the job here. I would really like to see a "uselang-de" class (or even a MediaWiki:Monobook.css/de message) that could be used to turn off the transformations if the page is using the German interface.

There is a [[MediaWiki:Monobook.css/de]], but it doesn't get used (as only [[MediaWiki:Monobook.css]] is used); but maybe .../de could be imported surplus?

See comment #20:
> Someone has to find a way to include [[MediaWiki:Monobook.css/de]] into the
> generated CSS file by software, as currently only the
> [[MediaWiki:Monobook.css]] file content seems to be send to clients.

> --- Comment #41 from Melancholie <Wiki.Melancholie@web.de>  2009-01-10 04:02:11 UTC ---
> There is a [[MediaWiki:Monobook.css/de]], but it doesn't get used (as only
> [[MediaWiki:Monobook.css]] is used); but maybe .../de could be imported
> surplus?

Not a bad idea, but I don't think that would completely solve the problem...think of what would happen if you wanted to see the English-language interface on a German-language wiki. Monobook would have text-transform:lowercase, then MediaWiki:Monobook.css/de would override it with text-transform:none, and finally MediaWiki:Monobook.css/en wouldn't do anything because it assumes that Monobook's text-transform:lowercase is still in force. Thus, the user interface elements would still be capitalized even in English where decapitalizing them is desirable.

In other words, we would have to add text-transform:lowercase to every single language-specific Monobook.css in order to properly allow multiple user interface languages on a German-language wiki.

(In reply to comment #40)
> I would really
> like to see a "uselang-de" class (or even a MediaWiki:Monobook.css/de message)
> that could be used to turn off the transformations if the page is using the
> German interface.

Keep in mind that the interface language is not necessarily used for *all* interface messages.  Look at the navbar on dewiki in English, or the enwiki one with German:

http://de.wikipedia.org/wiki/Wikipedia:Hauptseite?uselang=en
http://en.wikipedia.org/wiki/Wikipedia:Main_Page?uselang=de

They're a mix of English and German messages in each case.  You're going to get wrong results by trying to key off interface message: it has to be done on a message-by-message basis to be actually correct.

Created attachment 5661 [details]
Proposed patch v1

Ah, I see now. You have a good point. Here is a patch I made a few days ago, but was reluctant to post because I wasn't sure it was the best solution. This patch loosens HTML restrictions on the affected German messages and wraps them in <span style="text-transform:none"> to override Monobook's automatic decapitalization.

Incidentally, having msgHtml return unescaped text and wfMsgHtml return escaped text is quite confusing.

Never mind, forget the patch. I just realized that it breaks the Modern skin and there's no way around that.

Perhaps the best thing to do would be to offer a userLang-de class, and just accept that that will turn off decapitalization on all messages no matter the language. That wouldn't be so bad, would it?

And by "no matter the language" I meant "no matter the content language if the user language is German".

Created attachment 5757 [details]
Proposed patch v2

This is a much nicer patch that adds lang="de" to the affected interface messages, with matching CSS rules to turn off the text-transform. It also cuts a line of redundancy out of Skin.php and patches a security vulnerability where a malicious user could insert arbitrary HTML into [[MediaWiki:Navigation]].

lang="de" is applied no matter whether or not a German message is actually available. This is a bit hacky, but it will prevent ugly mixtures of text-transform:lowercase and text-transform:none.

1) The proposed patch will fail in IE6, which does not support the [attr=val] selector.  If use of advanced selectors were possible, incidentally, :lang() would almost certainly be superior, or at least [lang^=de-] to avoid some of the repetition.

2) I'm not sure it's a good idea to assume that Language::getCode() is valid to put in an HTML lang= attribute.  The latter requires that only RFC1766 codes may be used: does getCode() only output those, or does it also output invalid codes in some cases?

3) You should probably ask Tim or Brion for commit access, if you haven't already.

Created attachment 5764 [details]
Proposed patch v3

:lang() would be best, but it doesn't work on IE7. [lang|=de] seems most reasonable option to me, the other methods are hackish. IE6 users that can't be bothered to upgrade will just have to suffer with the status quo of no capitalization.

Don't we already use getCode() for <html lang="xx" xml:lang="xx">? If I understand the specifications correctly, MediaWiki's non-deprecated language codes are standards-compliant, even the more unusual ones. http://www.w3.org/TR/html4/struct/dirlang.html#h-8.1.1 even includes the example "en-cockney" as a valid language code.

I haven't asked for commit access; I figured that if the developers thought I should have access, they'd offer it ;-). It would be useful for trivial changes, but even if I had commit access, I'd still have to run stuff like this patch by the other developers to catch problems like the one you mentioned. And I'm still a bit unsure if accessing $wgLang directly is the best idea - maybe the call to getLang() would be more elegant if it were integrated into OutputPage or something.

(In reply to comment #49)
> I haven't asked for commit access; I figured that if the developers thought I
> should have access, they'd offer it ;-).

To the extent that that's how things work, that's what just happened, seeing as I *am* a developer.  You've gotten enough patches accepted that I think you'll be given commit access if you ask.  So ask and make things easier on all of us.

> It would be useful for trivial
> changes, but even if I had commit access, I'd still have to run stuff like this
> patch by the other developers to catch problems like the one you mentioned.

All changes are reviewed.  Developers can comment on mediawiki.org after commit, and if there are problems it will be reverted before going live.  You can still submit stuff for review on Bugzilla if you like, even if you have commit access.

I e-mailed Brion two weeks ago and Tim a week ago asking for commit access. Neither has replied. Would you be willing to commit the patch?

I asked Brion on IRC, he says he's now sent you a reply asking for account details.

After four e-mails to Brion and one e-mail to Tim, I still have not been given commit access. What do you suggest?

He says it's on his list and he'll get to it.  You'll have to wait a while longer, I guess, or else be more aggressive in pestering people on IRC.

Please don't use Bugzilla as a chat forum. :) Commit setups are reached in batches. Patches can be applied by any developer at any time.

Patch committed in r49331.