Is localized software really ‘language’ compliant?

When users read ‘software localized’ they immediately realize that software messages are written in their own language but when developers read the same phrase they should immediately realize that software must fit specific languages rules and character sets.

The difference seems obvious but you can discover very strange behavior when applied to Mozilla platform.

Consider the cyrillic charset, Firefox is translated (ie localized) in Russian but when developers need to interact with underlying operative file system with file paths containing native language characters the life becomes tough.

Recently an user left a post on ViewSourceWith (VSW) extension forum about a bug with cyrillic file names, so I thought the problem was on VSW but after some test I realized the problem is related to Mozilla XPCOM implementation.

The UTF-8 format usage is sometime inconsistent under the hood expecially when must read, write or simply use file names containing non-ASCII characters.

I was very surprised to discover the APIs that run processes don’t work properly especially under the planet-most-used operating system Microsoft Windows.

There are many open bugs on bugzilla (172817, 409796, 408923) but nobody cares so I’ve decided to write myself a working (I hope) component for Microsoft Windows.

The lesson learned is: Localizing software is important but making software locale compliant is important too!

Do you agree?

This entry was posted in Localization and tagged , , , , . Bookmark the permalink.