J. O'Conner

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!

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!

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!