Posts Tagged ‘Internationalisation’

I mentioned a couple of posts ago that I’d had to wipe my Ubuntu machine at work, replacing it with Windows 7, because PL/SQL Developer running via Wine refused to do extended characters properly. I was convinced at the time that this happened because Wine uses code page 437 by default, and I needed it to use code page 1252 (that is, a Western European code page rather than a US ASCII one). A commentator called Sokrates suggested I should set the Oracle NLS_LANG environment variable -but, although I had considered that at the time, I dismissed the idea because (a) setting a Linux environment variable didn’t seem, to me, to be a likely way to alter a Windows application’s settings and (b) that default code page 437 is definitely ‘wrong’ for doing extended characters -and thus seemed the most obvious line of attack.

Well, I should have listened to Sokrates!

So, first of all, here’s a video of me using the wine regedit command inside a Centos 5.3 virtual machine and noting the default, original code page settings. You’ll then see me run PL/SQL Developer, connect to a Windows 10.2.0.4 database, and encounter the problem of the disappearing extended characters. First, I create a procedure that uses extended characters and am able to compile it no problem… but when I re-open the code, all the extended characters have been stripped out or converted:

So that’s the problem. The question now is whether a code page setting in the registry will fix the problem, as I had hoped. In this next video, therefore, you’ll see me change the code page setting in the registry from its original 437 to 1252 (which is a code page that definitely supports extended characters). With the registry changed, I relaunch PL/SQL Developer and try to store my procedure with the correct extended characters re-inserted. Here’s how well that went:

Finally, I take Sokrates’ original advice and set the NLS_LANG environment variable to a locale that’s identical to the one being used by the database itself. I have to launch PL/SQL Developer from the command line this time, so that it picks up that new environment variable setting. Once it’s running, though, I do the same as before: paste back in my extended characters, re-compile the code… and then open the procedure back up to have a look at what got stored. Here’s how that turned out:

So, the good news is that I can have my Ubuntu installation back at work. The bad news is that I was an idiot to have dismissed an idea without having tried it out. Sorry, Sokrates. And thanks!

I wrote some time ago about how to get Debian to allow you to type characters like é, ç, ü and ß -pretty necessary stuff if you are in the habit of typing non-English music track titles (for example). Apply the technique described there to Ubuntu 9.04, however, and you will wreck your X configuration, with reboots into a strictly command-line environment the norm thereafter!

In fact, life is a lot easier in Ubuntu in this regard, because there is GUI support for enabling the ‘compose key’ that lets you type these sorts of non-English characters. Click System -> Preferences -> Keyboard and then select the Layouts tab. Click the Layout Options button, and you’ll see this sort of thing:

As you can see, simply expand the Compose Key option and then select whatever key combination you want to invoke the ‘compose behaviour’. I’ve gone for the right-ALT key, but you pick whatever suits you.

Immediately you do that (and click Close, twice), you’ll be able to implement foreign language composition. For example, I’ll launch gedit, press-and-hold the right ALT key and type a comma; when I release all those keys and then type the letter ‘c’, I’ll actually see a c-cedilla (ç). Or, if I hold down right ALT+colon (which means right alt+shift+the apostrophe key), let go, and then type the letter ‘a’, I’ll actually see a-umlaut (ä).

And all much easier, thanks to the GUI, than fiddling with xorg.conf scripts!