Caution: Latin American rant ahead.

With my Latin American Spanish keyboard (xkb code "la") I can type in:

• English: abcdefghijklmnopqrstuvwxyz
• Spanish, Galician, Basque, Quechua: áéíóú ñ ü
• Catalan/Valencian and Occitan: l·l ç ïü àèìòù áéíóú
• French: àèù âêîôû ëïÿü ç
• Italian: àèìòù âêîôû é
• Dutch: ëïöü
• German: ß äöü
• Swedish: å äöü é ç
• Danish and Norwegian: æ ø å
• Icelandic: áéíóúý ð þ æ ö
• Finnish: åäö (apparently, the untypable žš are only used in loan words)

But not in:

• Portuguese: I can't type ã or õ (no dead_tilde)
• Guaraní: I can't type ãẽĩõũỹg̃ (no dead_tilde).

It turns out that for some people it's more important to have 3 (yes THREE) asciitilde (~) in the Latin American Spanish keyboard, than to allow people to write in the language spoken by 51% of South American people, or the second official language in Paraguay (spoken by 94% of the population).

The same thing happens with the Traditional Spanish keyboard (code "es"), which was initially thought only for Spain, but is now widely sold all over Latin America. It includes 2 asciitilde, but no dead_tilde.

I think this is outrageous and I'm very very pissed about this. As can be seen in the posts I've made to the bugs in Debian and in FreeDesktop.

However, it looks like we Latin Americans are overwhelmed by the amount of Spanish people in Free Software (particularly in Debian) who don't care that Brazil is the biggest economy in the region nor that other native american languages can't be written without a dead_tilde.

For the record, there are some other European languages, that can't be written with the Latin American keyboard, such as:

• Polish: I can't type ąę ż, only ł ńśź
• Czech: I can't type čď ěňřšťž, only áéíóúý
• Romanian: I can't type ă țș, only âî

But in this case, it makes much more sense to not be able to write those than not being able to write Portuguese or Guaraní, and it's not like there are 3 macrons and no dead_macrons, there are no macrons at all (same for all others).

After reading Christian's post about the new ISO 639-3, I thought about the "what is the country in the world which as the highest number of languages listed in ISO 639-3" question, and thought, "It must be India or China", and sure enough they both have a high language count (428 and 236 respectively).

However, after clicking around a while, I found out that Nigeria has 510 languages. I thought I had found the highest one for quite a while, until I got to Indonesia, which has 742 languages, and I thought "it's not fair, that's much more than just a country, it's a huge group of islands". Not having learned my lesson, I was quite astonished when I finally found out that the country with the highest number of languages is Papua New Guinea, a neighboring group of islands (although not so big as Indonesia), with 830 languages!

In Europe, the coutry with the highest number is Turkey (36), followed by Italy (33) and France (32). It looks like Europe has gone a long way after that stupid Babel incident :).

In America, I thought Argentina would be quite up in the list, since we do have a lot of native groups, but it turns out we only have 27 languages and we are on the 9th place. The country with the most languages is Mexico (298), then USA (238), then Brazil (235).

And, after all that clicking around the site, I found a very interesting map, that has one red dot per language in the primary location of each living language. It's quite amazing to see the big red New Guinea island. I wonder what happened there that led to the creation of that many languages.

In a sudden rush of stupidity, the Argentinian government decided that we should change our timezone to include DST.

For those that don't know, Argentina lies almost completely in the GMT-4 zone. 20 years ago we used to have DST, switching between GMT-4 and GMT-3. But since 1990 we've been using GMT-3 as the permanent timezone for our country. Thus, noon happens at 13:00 (or even later in more western parts of the country).

Now, since we are in energetic crisis, our government decided that we should go back to DST, but instead of GMT-4 and GMT-3, we are going to be GMT-3 and GMT-2. This means that during the summer noon will happen at 14:00 or later.

Not only this, but they decided to do this on December 21st, passed the law on December 26th, and published it on December 28th. And the day of the switch is December 30th!.

Thanks to the quick work of Clint Adams, a patch was provided, applied and uploaded to unstable today, and it's already available. After the package was uploaded, I patched Etch's version so that we could upgrade all our servers.

So, in case you need to take Argentina's stupidity into account, you can currently download tzdata_2007j-3 from unstable, or download tzdata_2007j-1etch2 from:

deb http://volatile.debian.org/debian-volatile stable/volatile main

Ever since I stopped doing webpages, I've been missing having my own Rhino (the one I used in the past was not mine), but since I wasn't doing any JavaScript, it didn't make sense to spend U$S 50 on a book I wouldn't use.

Now, with the interactive web inteface for Debbugs being accepted as a Google Summer of Code project, I finally decided to buy one for me. I ordered it yesterday from Amazon.

I hope it gets here soon.

On my last post, I stated that there were a number of RC bugs affecting etch, which was not completely accurate: I was counting only those affecting both etch and sid, this is to say those packages that are in etch and that still haven't been fixed on sid.

It was pointed out to me that a number of packages (around 70 today) are waiting for perl to go into testing, so that they can go in too, and many of those fix RC bugs. In the end, a lot of RC bugs were not being marked as fixed in etch because of perl failing to build in hppa, mips and mipsel.

After learning this, I decided that this perl bug needed to be fixed: I gathered a small team, including my guru friends, Damián Viano and Martín Ferrari, and between the three of us, we worked on fixing this nasty bug for three days.

After a lot of time spent compiling an recompiling perl in an hppa box, we finally found out that the problem was due to a particular optimization flag (-fdelayed-branch) in gcc-4.1. Compiling the conflictive source file without that flag makes the bug go away.

So, we submitted a patch and are now waiting happily for Perl's maintainer Brendan O'Dea to make the fixed upload. Hopefully, the number of RC bugs concerning etch will go down quite a lot during the next week, as the affected packages are able to migrate.