Many languages are spoken in more than one country, and many countries have more than one language. When you forget this you do stuff like language selection menus that use flags to represent languages. This is problematic for several reasons, starting with having to ask yourself what flag you are going to use to represent English, and how to deal with the angry letters you’ll receive when you use the national flag to represent a regional language. So, using flags to represent languages is definitely discouraged.

This said, have a look at this small piece of the KDE l10n stats page:

The funny thing is that the flag you see next to “Galician” is the flag of Greenland. And Galician is not spoken at all in Greenland! So, what happened? Why did they use so wrong a flag?

The problem is that the ISO 639-1 code for the Galician language is “gl”, which is the same as the ISO 3166-1 code for Greenland. So, when choosing the flag for Galician they confused the language code with the country code and selected the flag for “gl”: that is, for Greenland.

(I’m surprised that they used the Ukrainian flag (“ua”) for the Ukrainian language (“uk”), and not the Union Flag. Perhaps that would have been too obvious an error :) – although I have been told by email that the ISO 3166-1 code for the UK is “GB”, not “UK”)

So, my takeaway message is: don’t use flags to represent languages and if you do, make sure you use a flag of a place where the language is actually spoken!

Addendum: I have just seen that Basque is accompanied by the flag of the European Union! That’s because the language’s code is “eu”. Ah, and there are three variants of the Chinese language (Hong-Kong, Simplified and Traditional), all with the flag of the People’s Republic of China. Someone is bound to receive angry email – Taiwan is a political hot potato. I have sent email to the maintainer of the page.

So I installed Eclipse to do some web development in Java, and this dialog box appeared:

I didn’t know what it was, and that was already reported twice (one, two), so I just clicked on “Ok”, and Eclipse worked correctly.

But the next time I started Eclipse, the same box appeared:

This time I pressed “Cancel” to see what happened. Eclipse did not load. So I ran Eclipse again and… well, I’ll spare you the dialog box.

Needless to say, I was less than impressed.

Now I’m hoping it will eventually get bored of always saying the same thing when starting Eclipse, and graduate to small talk:

If not, it could at least take advantage of the fact that it’s being run on a Debian developer’s computer and show this:

In Mozilla, Opera and Konqueror (and I suspect that in Safari too), this site uses pure CSS pop-up menus for its navigation bar. And they work very well, too (except that I had to use position: relative instead of position: absolute for the menus as Opera positioned them in strange places. A pity, I liked it better with absolute…).

These menus are implemented in the following way: first, the menu is defined in the HTML part using only the tags <ul> and <li:

<ul id="menu">
  <li>Links
    <ul>
      <li>Option 1</li>
      <li>Option 2</li>
      <li>Option 3</li>
    </ul>
  </li>
  <li>Whatever
    <ul>
      <li>Option 1</li>
      <li>Option 2</li>
    </ul>
  </li>
</ul>

Then, some CSS trickery is performed to have the <ul> blocks below a <li> tag invisible, with display: none; when the <li> has the mouse pointer on top, the <ul> changes to display: block:

#menu li ul {
  display: none;
  // other declarations to have nice squares instead of bulleted lists
}

	
#menu li:hover > ul {
  display: block
}

And that’s it. I read about it in this page by Eric Meyer. And it works, indeed. And the contents of the menus are visible to people with text-mode browsers, too!

The only thing is, the inventors of the :hover CSS pseudoclass, Microsoft, only support a:hover in their terribly outdated browser; other things such as li:hover or img:hover are not supported. That means that the really nice trick above does not work.

And that’s where I enter, with some ideas from Quirks Mode (where I learned almost everything I know about the W3C DOM, and I have very much to learn yet) and this page by Peter Nederlof, where the author describes a method to “fix” IE to “accept” :hover for everything. Basically, the trick involves rewriting stylesheets on the fly to change the :hover pseudoclass into a real class, and adding some Javascript to have all elements change their class when the mouse pointer hovers on them.

I didn’t need such a generic solution, so I just picked the ideas and made my own scriptset. First, a custom stylesheet to be loaded by Internet Explorer only (done via IE’s conditional comments) and a script for changing classes of elements that are under the pointer. The stylesheet is similar to the original one, but instead of using the :hover pseudoclass, it uses the .fhover class; thanks to the script, when the mouse pointer moves on top of a <li> element inside the menu, its class is changed to fhover, and then back to “none” when the mouse pointer moves off the element. The effect is the desired one.

I also take advantage of the fact that IE does not support the CSS “>” selector, to make some styles invisible to IE.

Now it works, more or less. Submenus are not shown correctly, but I’ll eventually get around to fixing them: at least, they work now!

If someone has any ideas to fix them and make them look like they do in Mozilla, Opera or Konqueror, I’d be very happy if you posted them as comments or e-mailed me (my address is not hard to find via Google. Look at the page’s footer for my name).