Last modified: 2009-09-18 09:02:39 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 1553 - Navigation headings should not be lower-cased in German
Navigation headings should not be lower-cased in German
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Internationalization (Other open bugs)
unspecified
All All
: Normal minor with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 6691 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-17 17:14 UTC by Jens Leinenbach
Modified: 2009-09-18 09:02 UTC (History)
8 users (show)

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


Attachments
Screen shot of English Wikipedia with current lowercase headings/links (623.86 KB, image/png)
2009-01-09 18:30 UTC, Brion Vibber
Details
Screen shot of English Wikipedia without text-transform on MonoBook skin (623.91 KB, image/png)
2009-01-09 18:31 UTC, Brion Vibber
Details
Proposed patch v1 (9.97 KB, patch)
2009-01-11 01:11 UTC, rememberthedot
Details
Proposed patch v2 (8.05 KB, patch)
2009-01-31 20:20 UTC, rememberthedot
Details
Proposed patch v3 (7.62 KB, patch)
2009-02-01 02:31 UTC, rememberthedot
Details

Description Jens Leinenbach 2005-02-17 17:14:23 UTC
It is not a good idea to lowercase the headings of the navigation boxes since
this is not compatible with other languages e.g. with the German language.

To solve this problem, just comment out every:
/* text-transform: lowercase; */

within your main.css file of your monobook stylesheet directory.
Comment 1 Antoine "hashar" Musso (WMF) 2005-07-09 16:19:38 UTC
Commited to cvs
Comment 2 TMg 2008-03-28 13:17:07 UTC
*** Bug 6691 has been marked as a duplicate of this bug. ***
Comment 3 TMg 2008-03-28 13:23:17 UTC
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.
Comment 4 Robert Leverington 2008-03-28 13:29:29 UTC
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.
Comment 5 TMg 2008-03-28 17:28:23 UTC
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;
}
Comment 6 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-03-28 17:31:20 UTC
I would be inclined to just go ahead and remove this from the Monobook skin, yeah.  Any objections?
Comment 7 Brion Vibber 2008-03-28 20:01:29 UTC
I object. It's a stylistic effect used by that particular skin, not an inherent value of the UI strings.
Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-03-28 20:05:03 UTC
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?
Comment 9 TMg 2008-03-31 13:41:12 UTC
@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.
Comment 10 rememberthedot 2008-12-08 06:12:57 UTC
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.
Comment 11 Danny B. 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 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).
Comment 12 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-12-08 14:15:33 UTC
(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?
Comment 13 rememberthedot 2008-12-08 19:12:36 UTC
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.
Comment 14 rememberthedot 2008-12-08 19:51:15 UTC
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...
Comment 15 rememberthedot 2008-12-08 20:14:47 UTC
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.
Comment 16 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-12-08 23:02:42 UTC
(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.
Comment 17 Danny B. 2008-12-09 13:18:37 UTC
(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...
Comment 18 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-12-09 14:25:46 UTC
(In reply to comment #17)
> So why won't we do it?

For my part, comment #7.
Comment 19 TMg 2008-12-09 16:59:16 UTC
As I said in comment #5, changing case is NOT just a stylistic effect. It changes the MEANING of the words in many languages!
Comment 20 Melancholie 2008-12-10 04:38:43 UTC
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.
Comment 21 Melancholie 2008-12-10 05:16:35 UTC
Note: Do not @import [[MediaWiki:Monobook.css/de]] in [[MediaWiki:Navigation/de]] (that would break other skins for example)
Comment 22 Melancholie 2008-12-10 06:21:11 UTC
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)
Comment 23 Melancholie 2008-12-10 06:26:25 UTC
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]]?
Comment 24 Melancholie 2008-12-10 10:16:26 UTC
Forget my last posts, changes have been reverted altogether, broadly.
http://translatewiki.net/w/i.php?title=User_talk%3AMelancholie&diff=894502&oldid=379444
Comment 25 TMg 2008-12-10 16:40:57 UTC
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.
Comment 26 Melancholie 2009-01-09 04:54:18 UTC
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.
Comment 27 rememberthedot 2009-01-09 07:01:56 UTC
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.
Comment 28 Melancholie 2009-01-09 07:43:18 UTC
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.
Comment 29 rememberthedot 2009-01-09 07:49:46 UTC
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.
Comment 30 Melancholie 2009-01-09 07:53:47 UTC
Ä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.
Comment 31 rememberthedot 2009-01-09 09:07:04 UTC
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.
Comment 32 Brion Vibber 2009-01-09 18:30:16 UTC
Created attachment 5656 [details]
Screen shot of English Wikipedia with current lowercase headings/links

For comparison purposes...
Comment 33 Brion Vibber 2009-01-09 18:31:38 UTC
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.
Comment 34 Brion Vibber 2009-01-09 18:35:06 UTC
Wouldn't hurt to float just removing the text-transforms by default.
Comment 35 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-01-09 18:35:59 UTC
Float where?
Comment 36 Brion Vibber 2009-01-09 18:37:52 UTC
In the community! Tell your friends, tell your mom, tell your blog, whoever. :)
Comment 37 Melancholie 2009-01-10 03:18:18 UTC
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.
Comment 38 Melancholie 2009-01-10 03:22:12 UTC
"Wiktionary:Hauptseite" had been a bad example (no adjectives ;-) [[wikt:de:example]] is a better one, showing at least "bearbeiten" (if logged out).
Comment 39 Melancholie 2009-01-10 03:26:29 UTC
> adjectives->verbs (me fool ;-)
sorry for spamming, unfortunately it's no wiki
Comment 40 rememberthedot 2009-01-10 03:44:02 UTC
[[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.
Comment 41 Melancholie 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?

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 42 rememberthedot 2009-01-10 08:38:52 UTC
> --- 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.
Comment 43 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-01-11 00:43:57 UTC
(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.
Comment 44 rememberthedot 2009-01-11 01:11:08 UTC
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.
Comment 45 rememberthedot 2009-01-11 01:28:57 UTC
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?
Comment 46 rememberthedot 2009-01-11 01:31:04 UTC
And by "no matter the language" I meant "no matter the content language if the user language is German".
Comment 47 rememberthedot 2009-01-31 20:20:01 UTC
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.
Comment 48 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-02-01 00:42:57 UTC
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.
Comment 49 rememberthedot 2009-02-01 02:31:54 UTC
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.
Comment 50 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-02-01 02:40:01 UTC
(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.
Comment 51 rememberthedot 2009-02-17 18:24:11 UTC
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?
Comment 52 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-02-17 21:23:07 UTC
I asked Brion on IRC, he says he's now sent you a reply asking for account details.
Comment 53 rememberthedot 2009-03-03 19:16:04 UTC
After four e-mails to Brion and one e-mail to Tim, I still have not been given commit access. What do you suggest?
Comment 54 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-03-03 22:29:48 UTC
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.
Comment 55 Brion Vibber 2009-03-05 01:13:01 UTC
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.
Comment 56 rememberthedot 2009-04-09 05:28:21 UTC
Patch committed in r49331.

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


Navigation
Links