J. O'Conner

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.

BCP 47 stands for Best Common Practice 47, and even without the acronym, the name alone means almost nothing. So, what is BCP 47?

BCP 47 is the current best practice for creating language codes. A language code is a text identifier that specifies a specific human language, and the code provides the means to define the language in terms of a basic language, a script used to write that language, and even a particular region in which the language is used. BCP 47 prescribes the code and its parts with enough precision to uniquely identify a natural, human language and distinguish it from other languages.

BCP 47 is a standard that uses other standards, and it prescribes how to combine those standards together to create a language code. BCP 47 is a combination of at least the following existing standards:

• ISO 639
• ISO 15924
• ISO 3166
• UN M.49

Why is this important to you in the internationalization or localization business? It is important because our industry requires common standards and agreement for how to communicate, transfer, and exchange language data. A BCP 47 tag is necessary to accurately identify language text across different applications and tools.

Lots of existing applications, tools, and platforms already use BCP 47:

• Java
• ICU4C, ICU4J
• HTML
• XML
• YUI

This is not an exhaustive list, but hopefully it gives you a sense of the importance of this standard. When you need to tag data with a language identifier, you should seriously consider BCP 47 instead of any home-grown convention.

Having provided plenty of links in this post, I hope you’ll take some time to familiarize yourself with this important language tagging standard. Happy reading!

Several years ago, Google was unhappy with the pace of change in the Java language and community. Their solution was to create the Dalvik VM and their Android platform. They were careful to not call it a Java platform, a Java implementation, JVM, or JRE; instead, they said it was the Java language on the Dalvik VM.

Now is Google doing something similar to JavaScript? It is true that the JavaScript language is evolving slowly. Google certainly has shown that it can innovate without a standards body before (see Java above). Is Google trying the same thing again, but with JavaScript? Is Google attempting to ignore the Ecmascript/JavaScript standards community and move ahead without them?

Google has a new language called Dart. This language is like JavaScript, but has many new language features. It will be interesting to see if Google gets as much benefit and praise for this as they did Android and the Dalvik VM.

More on Dart:

• http://googlecode.blogspot.com/2011/10/dart-language-for-structured-web.html
• http://www.dartlang.org
• http://www.dartlang.org/docs/spec/dartLangSpec.pdf

What I find so interesting about the Dart announcement is that Google already has a great tool for developing web applications without coding directly in JavaScript — It’s GWT, the Google Web Toolkit. Basically, it’s their very popular toolset for writing applications in Java and compiling it down to browser neutral JavaScript. If you’re unfamiliar with GWT, yes, you read that correctly…a compiler from Java to JavaScript. As a user of GWT, I can say that it works great! And this has great appeal in the developer community already. So why Dart? Why yet another language that they compile to JavaScript?

Yesterday I asked the question:

Which countries have multiple time zones?

And I promised an answer today. Congratulations to Paul Clapham, who made a great effort listing them!

The W3C document Working with Time Zones is the source of my information. That document lists the following countries as having more than one time zone:

• Argentina
• Australia
• Brazil
• Canada
• Chile
• Democratic Republic of the Congo
• Ecuador
• France
• Greenland
• Indonesia
• Kazakhstan
• Kiribati
• Mexico
• Micronesia
• Mongolia
• New Zealand
• Portugal
• Russia
• Spain
• The United States

The question: What’s a third party cookie? OK, let’s assume I’m an expert at these things, which I’m not, but let’s just assume that I play an expert at these things. Here’s your answer….

Cookies are small pieces of information stored in your browser’s cached files. If you visit a site, say example.com, that site might decide to store some state on your browser — a cookie. The cookie is a 1st party cookie because it is created and sent back and forth between your computer and that site, example.com, in your browser’s url field.

So what’s a 3rd party cookie? Well, often a document will fetch additional pieces of information from other sites, maybe a javascript file or an image, or maybe even entire documents. Anytime the document from example.com imports a file or script or image from a different web site (the 3rd party site), that site can also set cookies. Those cookies are 3rd party cookies.

Let’s look at this a little more closely. Imagine you browse to http://example.com/hello.html. This site might send back a 1st party cookie: FOO=1. The cookie could be stored in the domain of example.com, and only visits to that example.com would prompt the browser to automatically send that cookie value to example.com on subsequent visits. Because of the rules around cookie security, however, your browser would never send an example.com cookie to another site like example2.com.

Now imagine that the example.com/hello.html file has additional links to other sites. Maybe hello.html has an image link that pulls a photo from example2.com. Now example2.com is being called from your example.com/hello.html document. Your browser will not send any example.com cookie values to the referenced example2.com site. However, the example2 site may decide to drop a cookie as well. Since it is not the primary site of your document, which is example.com/hello.html, the example2.com cookie is called a 3rd party cookie.

Hmmm… so here we have examples of 1st party and 3rd party cookies. So, what’s a 2nd party cookie? I don’t actually know the answer to that question. If the site of your document is the 1st party and referenced sites are 3rd party, that really leaves the browser or its user as the 2nd party. Maybe a 2nd party cookie (which I’ve never really heard in any discussion) would simply be a cookie manually created by the user? Hmmmm…. probably not an important point. However, hopefully you know the difference between 1st and 3rd party cookies!

Are you a web service API developer? The web truly is a world-wide web. Unfortunately, a great number of globally unaware developers are on the global web. This creates an odd situation in which web services are globally accessible but only locally or regionally aware.

There are a few important things to remember when creating a global web service. Let’s just cover ONE today: non-ASCII query parameters are valid, useful, and often necessary for a decent, global web service.

It seems so obvious to me, and it probably does to you. Sometimes a service needs to exchange or process non-ASCII data. The world is a big place, and although English is an important part of the global web, more people speak a different language. English is a big percent, but lots of people use Chinese or an Indic language too. Let’s make sure your web service can process all those non-ASCII characters in English or any other language!

Let’s look at some examples of non-ASCII query params:

• http://example.com?name=田中&city=東京
• http://example.com?名前=田中&市=東京

In these examples, you must perform two steps to get the query params (both keys and values) into the correct form:

1. Convert the keys and their values to UTF-8 if they are not already.
2. Perform the “percent encoding” on each UTF-8 code unit

To do #1, you’ll need to use whatever character conversion utility you have in your developer’s library: the Java charset encoding converters, whatever.

The #2 step is the important one for this blog. For each hexadecimal code unit in the UTF-8 query portion, you must “percent encode” the code unit. Let’s look at the first example query params:

name=田中＆city=東京

The JavaScript function encodeURI actually does a good job of doing this for us:

encodeURI("name=田中&city=東京") produces the string:

name=%E7%94%B0%E4%B8%AD&city=%E6%9D%B1%E4%BA%AC

Notice that you should also include this encoding for the keys in the param list. In the next example, I’ve used Japanese values for both keys and values.

encodeURI(“名前=田中&市=東京”) produces this string:

%E5%90%8D%E5%89%8D=%E7%94%B0%E4%B8%AD&%E5%B8%82=%E6%9D%B1%E4%BA%AC”

Note that both the keys and vaues have been “percent encoded”.

On the server side, your server will understand how to decode these values into their correct UTF-8 string values if you have configured it correctly. Correct configuration of a server usually involves a charset conversion filter for a servlet container and sometimes just a config setting for Apache.

More on this at a later time.

Recently I became aware of Twitter’s new translation initiative that enlists the help of its user base. I think it’s a unique and possibly worthwhile gamble. After all, the translations are free, and twitter pays it users by giving them a …. “special badge on their public Twitter page displaying their status as an official Twitter translator.”

The idea is simple enough. An invited twitterer/translator logs into their site. Having been identified as a translator, the user sees additional buttons on their twitter web UI…buttons that allow you to translate the page labels and text. Cool.

Twitter wants to translate into all the world’s language eventually. For now, however, they’ll settle on these in the short term:

• French
• German
• Indonesian
• Italian
• Japanese
• Korean
• Spanish

Hey, great idea, Twitter. I wonder if the “special badge” of honor will be enough to enlist talented, real help?

Using online chat services can be very frustrating, especially when the expert chat professionals just can’t or won’t answer questions. My recent attempt to order Time Warner cable service got weird after a while…admittedly after I couldn’t get an answer about the HD recording capacity I began to wonder if this was a bot.

My transcript follows:

User John_ has entered room
Analyst Paul has entered room

Paul(Mon Aug 23 2010 04:50:59 GMT-0700 (Pacific Daylight Time))>
Thank you for contacting Time Warner Cable Online Customer Service, my name is Paul. May I have your complete name please?

John_(Mon Aug 23 2010 01:51:13 GMT-0700 (Pacific Daylight Time))>
John

Paul(Mon Aug 23 2010 04:51:20 GMT-0700 (Pacific Daylight Time))>
Thank you for providing your name. How may I assist you today?

John_(Mon Aug 23 2010 01:51:38 GMT-0700 (Pacific Daylight Time))>
What size is the HD DVR box on new service installation?

John_(Mon Aug 23 2010 01:51:51 GMT-0700 (Pacific Daylight Time))>
How many hours of recordings can I make?

Paul(Mon Aug 23 2010 04:52:35 GMT-0700 (Pacific Daylight Time))>
I understand that you would like to know about HD DVR box. Is that correct?

John_(Mon Aug 23 2010 01:52:39 GMT-0700 (Pacific Daylight Time))>
yes

Paul(Mon Aug 23 2010 04:52:49 GMT-0700 (Pacific Daylight Time))>
I will be glad to assist you.

John_(Mon Aug 23 2010 01:53:33 GMT-0700 (Pacific Daylight Time))>
Hmmmm…Paul are you there?

Paul(Mon Aug 23 2010 04:53:51 GMT-0700 (Pacific Daylight Time))>
Yes, I am here to assist you.

Paul(Mon Aug 23 2010 04:53:57 GMT-0700 (Pacific Daylight Time))>
I would like to inform you that view our Cable Box Comparison Chart. High-Definition (HD) boxes will provide you access to HD programming. Digital Video Recorder (DVR) boxes will allow you to Pause Live TV, Record 2 shows at once, and Record, and Record 30+ hours of programming. HD-DVR box provides combine the capabilities of the (HD) and (DVR) boxes.

John_(Mon Aug 23 2010 01:54:22 GMT-0700 (Pacific Daylight Time))>
30+ hours of HD recording?

Paul(Mon Aug 23 2010 04:55:46 GMT-0700 (Pacific Daylight Time))>
Please bear with me just a few moments while I research this information for you.

John_(Mon Aug 23 2010 01:55:52 GMT-0700 (Pacific Daylight Time))>
Can I add my own Firewire or USB drive to increase the recording capabilities?

Paul(Mon Aug 23 2010 04:57:15 GMT-0700 (Pacific Daylight Time))>
Thank you for being online; I am still in the process of checking the information. Please bear with me just a few moments while I research this information for you.

Paul(Mon Aug 23 2010 04:58:43 GMT-0700 (Pacific Daylight Time))>
Thank you for your patience.

Paul(Mon Aug 23 2010 04:58:55 GMT-0700 (Pacific Daylight Time))>
I would like to inform you that you need to contact our local office further information. Please accept my apologies for the inconvenience caused.

Paul(Mon Aug 23 2010 04:59:01 GMT-0700 (Pacific Daylight Time))>
Would you like me to provide you the number?

John_(Mon Aug 23 2010 01:59:37 GMT-0700 (Pacific Daylight Time))>
no, that’s not needed.

John_(Mon Aug 23 2010 01:59:50 GMT-0700 (Pacific Daylight Time))>
so, which question is not answerable?

Paul(Mon Aug 23 2010 05:00:08 GMT-0700 (Pacific Daylight Time))>
Please accept my apologies for the inconvenience caused.

John_(Mon Aug 23 2010 02:00:21 GMT-0700 (Pacific Daylight Time))>
ok, but which question is difficult?

Paul(Mon Aug 23 2010 05:00:51 GMT-0700 (Pacific Daylight Time))>
I do apologize for the inconvenience; unfortunately, this chat support center specializes in online offers.

John_(Mon Aug 23 2010 02:01:13 GMT-0700 (Pacific Daylight Time))>
of course, I understand that. I want an online order.

John_(Mon Aug 23 2010 02:01:23 GMT-0700 (Pacific Daylight Time))>
to do that I have questions first.

Paul(Mon Aug 23 2010 05:01:54 GMT-0700 (Pacific Daylight Time))>
I will be glad to assist you.

Paul(Mon Aug 23 2010 05:01:56 GMT-0700 (Pacific Daylight Time))>
May I know the services you are interested in?

John_(Mon Aug 23 2010 02:02:21 GMT-0700 (Pacific Daylight Time))>
well, I bet you can guess at least one of the services…the one named above.

John_(Mon Aug 23 2010 02:02:46 GMT-0700 (Pacific Daylight Time))>
HD DVR cable service

Paul(Mon Aug 23 2010 05:03:29 GMT-0700 (Pacific Daylight Time))>
Thank you for the information.

Paul(Mon Aug 23 2010 05:03:36 GMT-0700 (Pacific Daylight Time))>
May I have your complete address along with the zip code?

John_(Mon Aug 23 2010 02:03:52 GMT-0700 (Pacific Daylight Time))>
sure, but will you answer my questions?

John_(Mon Aug 23 2010 02:05:05 GMT-0700 (Pacific Daylight Time))>
Paul, you’re making this awkward. I want to order cable service but have a question about the HD recording capacity of the HD DVR machine. Additionally, I’m asking whether I can increase the recording capacity by providing my own external drive.

Paul(Mon Aug 23 2010 05:06:16 GMT-0700 (Pacific Daylight Time))>
Please bear with me just a few moments while I research this information for you.

Paul(Mon Aug 23 2010 05:08:57 GMT-0700 (Pacific Daylight Time))>
Thank you for your patience.

Paul(Mon Aug 23 2010 05:09:00 GMT-0700 (Pacific Daylight Time))>
I would like to inform you that after installation you can contact our local office in order to increase the recording capacity. Please accept my apologies for the inconvenience caused.

Paul(Mon Aug 23 2010 05:11:01 GMT-0700 (Pacific Daylight Time))>
May I please confirm if you are still connected with this chat session?

John_(Mon Aug 23 2010 02:11:16 GMT-0700 (Pacific Daylight Time))>
Paul, do you know how much wood a wood-chuck chucks if a wood-chuck could chuck wood?

Paul(Mon Aug 23 2010 05:13:25 GMT-0700 (Pacific Daylight Time))>
This chat support center specializes in online offers. I will be more than happy to assist with questions about these offers.

John_(Mon Aug 23 2010 02:14:07 GMT-0700 (Pacific Daylight Time))>
Thank you for your help Paul.

Personally, I think I had a ‘bot online. What do you think?

No, I have some other observations about this chat, particularly about the time stamp time zones, but I’ll leave that for another post.

We’ve already decided that determining a timezone for a desktop application is easy. It’s too easy, and so let’s not even waste our time there. Instead, let’s think about something more difficult: how do you determine the timezone of a visitor to your website?

If your site authenticates users, you have most of your problem solved. Along with your user’s preference for username, password, and favorite soccer team (if soccer is your web site’s focus), you can encourage users to register their locale and timezone. This really isn’t so much to ask, not if you are going to offer them rich, useful, or entertaining content.

So ask for a timezone preference! When you ask, however, make sure you ask for something more useful than a simple UTC time offset. Knowing that a visitor is in a UTC-8:00 time zone is helpful but not as helpful as knowing that that same visitor is in the Los Angeles/America time zone. The latter option obviously provides more information about the user. Of course, the Los Angeles/America time zone tells your system that a visitor requires a UTC-8 offset, but it also differentiates this user from someone in Canada that may use the same hour:minute offset. It’s more information! More information usually translates into a better user experience, especially if you take care to utilize that information to customize the experience.

It is also possible to get the browser’s default timezone using a bit of JavaScript. Is this the user’s preference? Maybe, maybe not, but it is available. I’ve heard arguments that suggest that this is not the correct timezone to use. However, my opinion is emphatically this: the timezone of the user’s host pc is probably the best thing you have available in the absence of a specific user preference setting. Yes, people move around; yes, a user can visit your site on the west coast one day and then the east coast the next day without changing the pc setting.

var d = new Date();

var tzOffset = d.getTimezoneOffset();

Is this perfect? No, not at all. In fact, this javascript really just provides a minute value offset from GMT and local time. Still, for formatting a time with a correct timezone offset, this is useful.

If you don’t use a user preference setting in your app or a bit of JavaScript to query your visitor’s host timezone, what else do we have? Hmm…that’s an interesting question. What else is available for determining the timezone of a user visiting your site? Well, they do have an IP address. There are public services and databases that attempt to map this for you, but I just don’t know how accurate this is. I suppose I don’t have any specific reason to doubt its viability; it certainly seems possible at some level. But I’ve not actually spoken with anyone that has used this accurately or successfully. If you have, let me know.

Until next time!

Web applications have an unusual problem regarding timezones and formatted, user-viewable dates for a few reasons:

• several timezones are usually involved, and the determination of which should be used isn’t particularly clear
• date formatting code for even a modest list of locales isn’t available in browsers by default

Timezones Everywhere

Desktop applications have it pretty simple. Their users work on a host, and that host has a configured timezone. Windows and Mac users have convenient access to those settings in their “System Properties” or “Control Panel”. If a desktop application needs to display the date or create a time, it has access to the local host timezone. Usually there’s no question…this is the correct timezone for an application to use. If a user temporarily relocates to a different timezone, the user is responsible for changing that setting in his system settings.

Web applications have potentially several timezones to juggle as they manipulate time:

• client timezone
• server timezone
• event location timezone
• site timezone
• user account timezone

The client timezone is the computer’s system timezone — the timezone set within system properties or the control panel. This timezone is controlled on the local desktop or host environment. JavaScript in a browser has indirect access to this host provided timezone, and that timezone is available as the default — and usually the only — timezone available to a browser-confined application.

The server timezone is the timezone of the physical server on which your application runs. In a global, world-wide application, this server timezone is probably the least relevant of all the timezones because a server can be almost anywhere in the world and is most likely not representative of the user majority.

The event location timezone is the timezone of an actual event; it is the physical event’s location. For example, world cup soccer matches are held in South Africa this year. It might be tempting to use the event’s timezone when publishing soccer match times. Unfortunately, if I’m a Brazilian fan trying to determine a game time, the South African timezone and time display may not be useful and may be confusing. Here’s an example from a Google search page that shows game times for a U.S. English-speaking user:

The site timezone is the timezone associated with the web app’s domain or site. Let’s use world cup soccer again. Yahoo has dedicated sports sites for various locales/regions around the globe. For example, sports.yahoo.com is primarily the U.S. site, but it has navigational links to allow a user to go to other regional versions of the sports.yahoo.com experience. If you look at a similar schedule of existing or upcoming games, you’ll notice that Yahoo chooses to display times using the site’s timezone.

One view of upcoming games looks like this on the U.S. English site. Notice that it uses Eastern Daylight Time for the site’s timezone:

A different look from the Brazilian site shows this. Note that the times use the BRT timezone:

The point here is simple: you have lots of choices for displaying time and time zones to your users. Making the choice is difficult. Once you’ve determined which zone to use, the technical issues aren’t nearly as hard to solve.

In this specific blog, I’ll not solve the technical aspects of displaying time in the proper time zone and format, but I will leave you with my personal suggestion. In general, I think a web site should use as much information as it has available to customize information and to present it clearly to its users. For times and dates, it makes sense to me to present that information in the timezone and format that the user is accustomed to seeing. If your site knows that I’m a U.S. English speaker, maybe you should at least display times using a U.S. timezone. Of course, some regions have multiple zones, and that becomes a new problem. However, in the case of the U.S, which has multiple zones, a California resident is probably more likely to know that EDT is a 3 hour offset. It is doubtful that most California residents would know immediately that South African time is …. well …. some other offset. You see, the South African timezone just doesn’t help me much if I intend to actually watch or record the event. EDT is at least a bit more familiar.

There you have it…some ideas about timezones and their display. Use what your site knows about users to display information. The more localized in formats, the better in my opinion.