J. O'Conner

The IUC 36 call for papers went out last week – http://www.unicodeconference.org/e/IUC36-CfP-03-29-12.htm

This conference event brings together the best minds, ideas, and practices in the worlds of internationalization and localization,  There’s content sessions to please everyone including technical engineers, project managers, and product managers.

The Program Committee is requesting proposals for presentations. Check out the website for details, but some of the general areas are the following:

• Application Areas
  • Social Nets
  • SEO
  • Websites and web services
  • Libraries and educatoin
  • IDN
  • Mobile and Tablets
  • Security
  • Machine Translation
• General Techniques
  • i18n libraries
  • bidirectionality and scripts
  • html5
  • Data formats: json, xml,
  • project mgmt
  • font dev
• Culture and Tech
  • Endangered languages
  • Unencoded languages
  • Case studies
  • ISO language tag issues
• Regional Considerations
  • Africa, Asia, Middle East
  • Locales and CLDR
  • Emoji Support … sigh…

If you think you might want to present something new and exciting that you have been working on, consider presenting at the conference. Read the above link to find out more.

One last thing. Check out that Gold Sponsor!

Presenting a user interface in the customer’s language should be a high priority from your product management team. If not, they’re not doing their job in my opinion. Assuming you have the feature in your product roadmap, how do you choose the UI language of your customer on the web. After all, web applications have multiple, sometimes conflicting language signals.

A language signal is an indicator that gives your application a hint of your customer’s preferred language. In a web application, these signals are numerous. To help you in choosing from all these signals, I believe you should honor the preferences in the following priority. That is, check each signal for its existence in this order, and use the first signal that is available:

1. query parameters, for example http://example.com?lang=fr
2. domain name or path parameters, i.e. http://fr.example.com or http://example.com/fr
3. persistent application preferences
   • cookies
   • customer profile or settings
4. browser accept-language headers
5. geolocation hints
6. default application language

Query Parameters

Query parameters are often used to override every other language or application signal. If parameters are used, your customer (QE engineers or even end users) are intentionally trying to coerce the application into ignoring all other language signals. Query parameters beat out any other language signal when they are provided in the same request.

Domain name or Path Parameters

Sometimes you will partition your localized sites by domain name or by language tag paths. A domain name partition means that you select different or even localized domain names for specific markets. For example, your French site could be http://fr.example.com. You can also distinguish language preference on the path like this: http://example.com/fr or http://example.com/en-gb. When query parameters don’t exist, this is the next choice in our prioritization.

Persistent Settings

Of course, if your application has allowed the user to select a language preference, the application should honor that preference. The preference may be stored in a cookie or even in a user profile attribute on the server.

Accept-Language Header

Most browsers provide a list of user language preferences in each request. These languages are provided in request headers as values of the accept-language attribute. This attribute can have 1 or more language codes, and they indicate the priority of the user when requesting content. In the absence of other signals, your application should respond to the accept-language header.

Geolocation Hints

The last signal that actually provides information about the user is the geographic location from which the user is accessing your content. Although imperfect and imprecise, geography can provide a hint to your customer’s language preference. It’s definitely not the best indicator because multiple languages can be spoken in any geographic location. In a pinch, though, you may be able to provide a language selection tool that provides a list of the most prominent languages spoken in a specific area of the world.

Default Application Language

Finally, when all else fails and there have been no other indicators, you can provide the UI in the default language of the application. If your company is in Germany, maybe the default is German. If it’s the U.S., your default language is most likely English…or maybe even Spanish. You have to display the application in some language, and the default at this point is your last option.

In Summary

To summarize, a web application can serve a global audience. In doing so, it may accommodate customers in a variety of languages. Your application’s user interface may be selected from numerous possibilities, numerous signals from the user. Those signals are important data points to consider when making the language choice to present to the user. Using the signals described in this article, you’ll be able to consider some of the more important language preference indicators. Follow the prioritization I’ve outlined here, and you’ll make the right language choice most of the time…until you don’t. And there will be times when you don’t make the right choice from all these signals. When that happens, and it will happen, you have to give your users some way to indicate that problem. Take a look at my previous blog entry about language selection widgets for help with that.

The Unicode Consortium announced the release of Unicode 6.1.0 yesterday. The new version adds characters for additional languages in China, other Asian countries and Africa. This version of the standard introduces 732 new characters.

In addition, the standard also added “labels” for character properties that will supposedly help implementers create better regular expressions that are both easier to read and easier to validate. I admit little knowledge about these labels at the moment, but will research and report on them in the future if time allows.

One of the oddities of the new version is the inclusion of 200 emoji variants. This is perhaps the only issue of the standard that I just don’t understand. Back in the day when I was more involved in Unicode development, we had a huge effort to unify variants of Chinese characters. We preached that Unicode characters were abstract entities with glyph renderings that were determined by font, style preferences of developers and apps. Now it appears that the Unicode consortium has changed its position on this.  Or maybe partially?. The addition of 200 emoji “variants” just seems unnecessary, but that’s just my opinion and I admit that I may not know all the issues that formed the consortium’s decision.

We have some examples, straight from the announcement, that show only 4 of the 200 new emoji variants:

As the image shows, the “TENT” emoji has two variants — a text style and a more colorful, graphical emoji style. The standard defends these variants by saying that it allows implementations to distinguish preferred display styles. I think that is what fonts are for. Personally, I just don’t think variants are needed. And, I think that the variants make things more difficult for applications.

What do you think about variants in general? And what about emoji variants specifically?

You have to respect Apple. They have excellent products that are known worldwide for their quality and ease-of-use. Part of that ease-of-use comes from their commitment to producing internationalized, world-ready products. However, even the best companies and employees make mistakes.

Recently I purchased a new iMac 27″ computer for my family. Of course, they don’t believe it is for them since I spend the most time using it. But I’m going to stick with my story…it’s the new family computer. Anyway, I immediately noticed that Apple is pushing their iCloud service. During setup and first run of things like iPhoto, I was prompted to choose whether I wanted to use iCloud for backups, etc.

Of course, I had to try out the iCloud service, so I entered all my personal details — name, account id, etc. The service works as expected, and I have nothing interesting to report on that.

To make iCloud clearly available and visible, Apple puts the iCloud service settings into the System Preferences application.

Clicking on the iCloud icon brings up the iCloud settings of course. Again, not much to say there. You have all the typical iCloud-able apps to choose from: Mail, Contacts, Calendars, Photo Stream, etc. However, I did quickly notice that iCloud had a little trouble with my name. Instead of showing my full name as John O’Conner, the iCloud app prominently displayed it as John O'Conner. Oops.

I admit that this is not the first time I have seen my name displayed in this way. Web forms sometimes mistakenly store my name using character entity references. Apparently the apostrophe sends bank and medical systems into fits of confused stupor. However, I’m surprised that it trips up Apple in this way.

It just goes to show you that even some of the best companies can make mistakes with how they handle and display text data. It’s common to normalize text when putting it into a database. However, I don’t think a character entity reference is the right thing to put into your db. If you do, you certainly should remember to decode it when you display it to your user.

The questions pop up often enough in internationalization circles so I’ll address them here:

1. how should I localize a language selection list?
2. how should I sort it?

Localized Language Lists

Customers use a language selection list to change languages. You must assume that the currently selected language is inappropriate for some reason. One possible reason is that the user cannot read the page content. This means that a localized language list that displays all target language options in the language of my current page probably won’t be understood. For example, let’s pretend that I speak English but am on a Japanese web site. Presenting me with language options that include ” 英語” will not help me if I don’t read Japanese. I can’t be expected to know that those characters mean “English” to a Japanese person. This option is unhelpful. What is helpful?

The right way to represent any language selection list is to display languages in their own language and script. For example, English should be English, Spanish should be Español, Japanese is 日本語, etc. You don’t need to localize this list into every language. One list using the target language’s own language and script for each language choice is both sufficient and optimal. This guarantees that I’ll be able to read and select my target language regardless of the current page’s language setting. This is the most universal option you have, and I consider this a best practice for creating language selection lists.

Sort Order

I don’t know how better to prepare you for my answer…so here it is. The actual sort order is less important than consistency. Two points make this obvious to me:

1. if your customer wants to choose a different language, they probably don’t speak the current one, and the current language’s sort rules won’t be particularly useful anyway.
2. you can’t accurately guess what language rules you should use because you don’t know which language the user will select.

With these points in mind, I don’t think the sort order matters. Correct linguistic sorts for this list are not critical, and anything you choose will be inconvenient to someone. For this reason, I think you simply have to choose a sort order and be consistent every time you show the language list. My suggestion is that you simply order the list in U.S. English order if you consider U.S. English to be the base language of your product. If you consider your base language to be something else, use that. My point is that it doesn’t matter. Sure, you’ll be tempted to provide this list in the sorted order of the language of the current page or host OS setting. Sure that’s an option, but it’ll be incorrect more often than correct when it’s needed. Save your sanity. Choose an order. Be consistent. Don’t worry about localizing this order.

So this sort issue is bothering you still? You just can’t accept it? Ok, that’s fine, but consider this. The solution I’ve described is already used by some pretty big players. Since I just finished evaluating Facebook, let’s use it as an example. Regardless of which localized site I visit, regardless of my browser language preferences, Facebook shows the same list of languages in the same sort order. They don’t even use a US English sort. Their choice is something different, something almost like a US English sort, but maybe using the Romanized version of the target language? Here’s an example — Japanese is sorted with other languages that start with an “N” sound. The Japanese pronunciation is romanized as “nihongo”. So, “nihongo” starts with an n and sorts with other languages that start with n? I can’t quite figure the sort rules out BUT that’s my point…it doesn’t matter. Its consistent every time I go to the page, and it works. Here’s a shot of that Facebook page:

Conclusion

Providing a language selection list for your multilingual product is a great idea. It lets customers conveniently change the UI language of the product. Don’t over-think this problem. You can provide this feature without spending countless hours of debate. Follow my suggestions:

1. Provide a single language selection list in which each entry is translated into the target language and script.
2. Choose a sort order, any order. Be consistent in displaying this order.

Have a suggestion or comment? I’d enjoy hearing from you.

Please comment on this post or email me if you are interested in this localization engineer position. I’ll put you in contact with the recruiter.

Direct from the recruiter:

The requirement is for a Localization Engineer in San Jose working for one of the leading Web Commerce companies.  They are looking for more than the typical Localization Engineer as they need someone who has done some programming, not just scripting.   I have attached a description and also listed below some things the manager said they have been missing in the candidates so far.

What I’ve been missing so far in candidates is

-        Experience with web localization (more a focus on i18n engineering, but then without real coding skills), and enterprise localization tools (e.g. WorldServer)

-        Significant modern coding skills (going beyond a simple VBA macro or Perl script), e.g. ability to write some Java application, understand/fix/enhance existing code, or a simple plug-in against a documented SDK (more than just passive knowledge of Java, etc)

-        Ability to clearly articulate concepts or thoughts, describe processes

If this sounds like a good fit, I can email you more details. Good luck!

//John

Recently a recruiter let me know about this position. If you are interested, please email me (john at joconner dot com) or leave a comment. I’ll send you all the contact information and details. Or of course, you could just go straight to the web site yourself…either way. But, in my opinion, it always helps if you have an internal lead!

Here’s the job description, straight from the internal recruiter:

We are currently looking for a Sr International Product Managers for our Cobalt (www.cobalt.com ) office in the Seattle area.

The selected candidate will lead the efforts around globalizing our core automotive platform and requires

- Strong internationalization, globalization, and localization experience
- International rollout and deployment experience
- Experience in a B2C environment
- Experience working across countries and cultures

This is a FULL TIME with benefits that start day one.

Good luck!

//John

Sharing an iTunes library across multiple accounts on the same computer isn’t difficult…once you know the trick. And that’s the problem, the trick isn’t obvious. If you have a large family with lots of music, you might want to try this.

Creating a Family Account

First thing I did was create a “family” group on my iMac. As an admin on the machine, go to your System Preferences->Users & Groups. Create the “family” group and add all your family member accounts to it.

Create the Shared Folder

In your Finder, press <Shift>+<Command>+G. Enter /Users/Shared. This takes you to a shared user account that I just discovered. Create a Media folder here. Now copy or move your old Music folder (that contains your ITunes folder) to this /Users/Shared/Media folder. See image below:

Click on the Media folder and allow your family to have read+write access to it. Select the folder, press <CTRL>+I for information on the folder. You will be able to add your family group to the folder and add read/write permissions for this group. The image below shows the access portion of the information screen:

Click the + button to add the family group. Then change the Privilege to Read & Write. Then you might need to click on the lock icon to unlock the next option. I applied the privilege to this and all enclosed items, which conveniently provides the same access privileges to the iTunes content. You may want or need finer control on access, but we want everyone to be able to update the library.

Point iTunes to the Shared Library

Now that you have a shared library, you need to perform the repetitive task of pointing each user’s iTunes to this shared library. You can do this by logging into each user account and doing the following:

1. While holding the <ALT/OPTION> key, click on the iTunes application.
2. iTunes will open and ask you choose an iTunes library. Navigate to and select the shared iTunes folder you created previously.
   

That’s it. Now all your family members have access to the same iTunes library. Whether this is a good thing, I don’t know yet. If someone accidentally deletes my music collection, I’ll have to rethink this strategy.

(The iTunes logo is no doubt a trademarked image of Apple Inc., and hopefully I’m using it correctly. If not, please let me know.)

Today marks the first day of my official, end-of-year, get-caught-up on Android learning tour. And the first step is to install the SDK. Since I want to use Eclipse, I’ll need to install whatever Eclipse plugins/addons are available too. Let’s get started.

Installing the SDK

The Android SDK is on the Google Android Developer site. The SDK is a little difficult to understand. WIth enough reading over and over, I finally understand that the SDK has at least two parts:

1. A general SDK that is platform independent
2. A set of platform-specific tools.

If you don’t have the SDK at all, the best way to get both of these SDK pieces is to download and install the “Starter” SDK. After downloading it, unzip or install it into any convenient directory. Just make sure you have read/write access to this install directory. I installed these initial SDK files into ~/bin/android-sdk-macosx. Once you’ve done this, you will have both parts of the SDK, the general SDK and the platform-specific tools.

Updating the SDK

Apparently you can update the platform-specific tools without affecting other parts of the SDK. I have not done this yet because I am installing for the first time. When I do update, I’ll let you know the results.

Installing the Eclipse Plugin

This is probably the easiest part of the installation. Open your Eclipse IDE and open your menus selection Help->Install New Software. You can then add the Google Eclipse Plugin repository as shown below. Type in https://dl-ssl.google.com/android/eclipse/ for the software repository address.

You’ll see a list of software tools including the Android SDK plugin. Follow the rest of the onscreen instructions to install. Soon you’ll have everything you need to begin developing on the Android platform:

1. The JDK
2. Eclipse
3. The Android SDK
4. The Eclipse plugin for Android development (ADT)

I think there may be one more step…creating a target Android device for the emulator, but that may have to wait until the next blog.

Today I noticed that the Chrome browser is currently leading in the market share wars…at least on my site, which is the most important indicator.