Here is how the latest iTunes 10 application under Windows 7 on a computer that has the DPI setting set to 150% (“Larger”) also known as 144ppi.

Steve, what kind of QA is the iTunes team doing? As you can see this is not a minor/cosmetic issue anymore.

I created two test Win32/Unicode native applications one using MFC and one without MFC – the issue appear on both. I didn’t bothered to test .NET because I’m not interested in it.

Take a look at my screenshots below. It’s really simple to reproduce it yourself: just use the MSDEV Wizard to create a new application and paste some Unicode text into one of the dialogs.

Some interesting thing to consider:

• I didn’t change the font in the dialog – it’s using the default value: “MS Shell Dlg”
• If you modify the language of dialog from the default “English (United States)” to a language that does contains the testing characters they will display – but this is insane! It does mean that is still using codepages?! and worse that you cannot create a dialog containing characters from different scripts?
• Isn’t Windows supposed to do font face substitution?
• I tested only on Windows XP SP3.

Sad but this does look like a What You See is What you WON’T Get.

Later, same … day

Let’s see the list of bugs I’ve just discovered on Microsoft Connect using it’s “very sad” search feature

• By default the RC Files are not Unicode, even on Unicode projects, duh!
• Resource editor doesn’t tell you to save the files as Unicode when you have Unicode characters on it. So you loose them without knowing it!
• Resource editor doesn’t support UTF-8 – sad!
• Resource compiler doesn’t support UTF-8 – sad!

Bugs found on Microsoft Connect: 176612, 100833, 162872. Some of them being submitted 3 years ago for Visual Studio 2005: None of them solved even in newer versions like 2008.

And the DIY formula

Open the RC file using text editor and save it using File > Advanced Save Options and select Unicode – Codepage 1200. It took me quite some time to figure it out just because several people considered that Unicode related bugs are not so important. Maybe we can suggest to rename the Unicode option from the Application Wizard to “Partially Unicode”.

You could the clipboard for inserting Unicode text but be aware that thin method does not enable you to test real keyboard input. If you are not using standard windows controls you have to test quite a few different keyboard layouts.

From my point of view there are two types of keyboard shortcuts: the mnenonics (hot keys) and the normal keyboard shortcuts. Mnemonics are the underlined letters and they are fully translatable.

_{Position is more important than the letter on the key.}

One simple example is the Cut-Copy-Paste group they are all consecutive keys on the keyboard and are accesible only with one hand (Ctrl-X, Ctrl-C, Ctrl-V).

Anoher example would be the Undo function that is using Ctrl-Z on English. On a French keyboard it should map to Ctrl-Y because ‘Y’ and ‘Z’ are switched on these keyboards and we need to keep the position.

Use the virtual key codes for remembering the shortcuts

In order to be able to make the shortcuts available on multiple keyboard layouts you need to store the virtual key codes reported by the keyboard not the letter reported. There are many people using multiple keyboard shortcuts on their computer and they are switching from one layout to another very often. So you can’t rely on letters reported by OS but you can safely use the virtual key codes reported because these are not changing when the used is changing the layouts. In fact virtual key codes are.

You can find a full list of virtual key codes here.

It’s a good idea to keep the filenames not localized but to “localize” them on-the-fly – only when you show them to the user.

Why?

• It’s simpler to have the same filenames for all files and will generate less bugs inside code.
• You’ll have less Unicode related problems with the transfer of the files on FTP or filesystems not supporting unicode.
• It’s the only way you can have a multilanguage application or operating system, think that many people using different languages can access the same computer, even at the same moment – like Terminal Server.

Apple OS X

On OS X you can use .localized extension for setting the names that are going to be shown to the used. You can find a good description of how does OS X handle localized files on DisplayNames article on Apple site.

Localized directory and files names appear only if the “Show all file extensions” option is not selected in the Finder preferences – you need to login again after changing this.

Microsoft Windows Vista

You can customize the names of the folders and files using desktop.ini files.

There is a small glitch with this, you have to Reset Icon Cache after a change because the OS is caching the names and the icons. You can find several ways of doing that at http://smallvoid.com/article/windows-icon-cache.html

First parameter is a the full path to the a binary file (EXE or DLL) containing the localized string resources. The second parameter is the resource ID, Windows will know to load the correct language from the resources.

[.ShellClassInfo]
LocalizedResourceName=@%SystemRoot%system32shell32.dll,-21813
[LocalizedFileNames]
first.txt=@%SystemRoot%system32shell32.dll,-12712
next.txt=@%SystemRoot%system32shell32.dll,-21813

Use this script for forcing update of the texts.

@echo off
:: xp
del /F "%HOMEPATH%Local SettingsApplication DataIconCache.db"
:: vista
del /F "%USERPROFILE%AppDataLocalIconcache.db"
taskkill /f /IM explorer.exe
start explorer.exe

Microsoft Windows XP

You document to the users that they are going to see localized filenames only on Windows Vista because Windows XP doesn’t support this.

Linux

I’ve found no support for this right now. The only thing i’ve discovered in Ubuntu 8.04 is that you can change the GUI language and, after login, you’ll be propted to renamen Standard Folders (Like Documents, Music, …) to the new translated names – but it does not move the directories.