OpenOffice Spanish keyboard shortcut oddity

Preparing for the upcoming Wikimania in Buenos Aires, I’ve been attempting to practice my Español in part by switching my computer’s user interface into Spanish.

OpenOffice 3.1 was released today, so of course I went and grabbed the Spanish-language Mac download and fired it up. ¡Bueno! Except…. while editing a document, cmd+A brought up an “open” dialog instead of selecting all. Um?

Ok, “A” for “Abrir”, sounds good right? Except for the part where the entire rest of the operating system maintains the same keyboard shortcuts regardless of my language setting, and I would go completely mad if common shortcut keys randomly gave me different features in just one application.

A little googling turned up complaints about this sort of behavior going back years, but not a lot of good solutions. After some poking around, I did finally discover the configuration dialog for the keyboard shortcuts — under Tools/Customize… (Herramientas/Personalizar…) instead of, say, oh, in the preferences dialog.

I was able to — component by component — export the English keyboard settings to a file (saved conveniently with a “.*” extension) and — component by component — load my “customized” settings back up after relaunching in Spanish.

It seems to work now — cmd+A selects all, cmd+O brings up an open dialog — but it was a bit of a pain getting there. Let’s hope they don’t spontaneously revert…

Update: I’ve added a note on this to a bug on OOo’s bug tracker. Trying to track down some Spanish-speaking Windows users to check the standard platform behavior of Windows apps localized in Spanish… is Ctrl+A for Open and Ctrl+G for Save normal there?

Epic sort fail

Was transferring some screen shots from my iPhone with Mac OS X’s “Image Capture” app when I discovered that the sort-by-date seems to have some problems:

epic-sort-fail

Yes, it’s sorting by ASCII string value of the formatted date. 3/4 comes after 3/22, and 3/22/08 comes after 3/20/09. How’d Steve Jobs let this one out the door? I can only assume nobody had a memory card or camera with old photos on it when they tested…

en.planet.wikimedia.org borkage resolved

Was out sick for a couple days, catching up now before the FOSDEM rush. :D

Got a report that en.planet.wikimedia.org hadn’t been updating since January 30; turned out to be a UTF-8 BOM problem — one of the maintainers saved the Planet config.ini file in an editor that added a Unicode byte-order-marker character.

In theory, the BOM is a great idea. It’s a particular character (U+FEFF) which can act as a signature to tell the computer what variety of Unicode encoding the file is using — UTF-16LE, UTF-16BE, UTF-32, or UTF-8.

In practice, in the Unix-y web world, UTF-8 is king… and lots of things that eat UTF-8 don’t know what the hell a BOM is. We can’t use them in our PHP code because PHP sends them to output, corrupting your headers or binary data. We can’t use them in our Planet configuration files because the Python config file class gets confused by it.

Back in the 1990s they told us Unicode was going to be so easy… :) *wistful sigh*

Google Transit yay!

A few months ago I whined about the Google Maps transit planner not working very well.

Well somewhere since I last looked, they fixed it!

Transit directions now include San Francisco MUNI bus and train routes and walking to/from stations, so you can actually put in start and end points and get something useful! The alternate route selection is a little different from the driving directions (you get a short list of a few options, rather than being able to click and drag waypoints to whatever route you like), but still quite useful; it comes up with pretty close facsimiles to the three alternate commute routes I use in reality.

Goodbye, 511.org!

Now if they can just integrate the transit lookups into the iPhone Google Maps widget… d’oh!