J. O'Conner

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!

Looking for a new position? EMC is looking for an Internationalization Consultant! I can’t take it, but maybe you can.

Summary

The Internationalization Consultant is responsible for participating in planning and discovery sessions, providing consultation on I18N requirements and optimal business/engineering process design, overall status assessments, and contributing to the campaign for education and awareness of I18N standards for product design and development throughout the enterprise.

More Information

For more information, you should check out the EMC job listing directly. Or search their job listings for requisition id #55885BR.

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.

Japanese language students must learn 196 additional Kanji to consider themselves literate. These additional characters will be added to the already daunting 1945 characters that are part of the “Joyo Kanji” list, which brings the total count to 2136. Joyo kanji are the basic, fundamental characters of the language…the minimal set that an adult or post high school person should know.

I remember my college days learning Japanese. I thought I was pretty good to have learned the Joyo kanji in my 4 year career. At this point 4 years would barely be enough for me to choke down the additional requirements.

I think the motivation for adding the characters is interesting. As you might imagine, it is much easier to recognize a written kanji than it is to write it oneself. In this digital age, we have lots of help writing kanji. Input methods make it…dare I say…almost easy to write kanji. And since we read so much more than we typically write, and since input methods simplify text entry, we don’t really have to worry about recalling every stroke of any kanji. The software handles this for us nicely. So, not particularly concerned that students be able to accurately write the new characters, Japan’s Agency for Cultural Affairs has added these characters with the primary hope that students should at least read and recognize them.

You can learn a bit more about the Joyo Kanji:

• Joyo Kanji
• Overhaul of Official Kanji

Recently I had the opportunity to sign up for health benefits with a 3rd party site that manages these things for my employer. Sites that collect data often limit the set of characters that you must use for each field. That’s reasonable for numeric fields, date fields, etc. After all, you don’t want invalid data in a field, and you’d like to help users enter correct data wherever possible.

However, I think it’s unreasonable to limit characters that are legitimately used in a field type. For example, these characters show up all the time within perfectly valid names:

• APOSTROPHE ‘
• HYPHEN -
• ACUTE ACCENT ´
• DIAERESIS ¨

Come on…in 2010 these are not exotic characters. They exist in all kinds of unimpressive, common names….like O’Conner for example! In the figure below, the data collection form dislikes the apostrophe. Come on, it’s part of my name.

Unfortunately this is all too common. Do you have a problematic name? Share it with me…what name causes you grief in online forms?

I’ve owned a Macbook Pro before…it wasn’t a great experience, but it was acceptable. It was during a period of my career when my primary job was to communicate with other developers and to evangelize Java. The Macbook worked in that environment.

Now my needs are different, but I find myself using another Macbook Pro. Fine machine, don’t get me wrong…but I have to admit that I’m a bit lost regarding how to update the tools that were preloaded with the OS. For example, I find most of the common tools on this machine:

• perl
• php
• apache http server
• java

In all cases, these tools exist but are outdated in some way. They have newer versions that have features that I’m interested in, and I want to upgrade.

The question now is simple…what is the best way to find and upgrade these types of developer tools in a Mac OS X environment? Colleagues have mentioned “fink” and “Macports”. Are there other sources of Mac OS X software ports for these common developer tools? Do those sources place the new tools in the same locations used by the old tools, effectively replacing them in the system? Or do they place the new tools in a separate, different location?

I’ll find out the answers to these questions on my own as well, but I’m curious if you have tips and suggestions before I get too far down my own newbie path.

The submission deadline for technical sessions and tutorials for the upcoming Unicode Conference has been extended. You now have until Friday to procrastinate.

I’ve submitted my proposal, a technical session. Here’s the somewhat offbeat proposed session:

Character Conversions from Browser to Database…and Back Again

As characters travel through a typical web-based application, they must cross several boundaries and borders. These include the following:

• browser processing and JavaScript
• browser request creation
• middle-tier request processing
• database storage

Along the way, many forces conspire to transform and manipulate your noble, beautiful characters into unrecognizable, mutant forms. What causes those conversions and transformations? How do you combat destructive conversions?

This session takes you on a journey with some great characters on their travels from browser to database…and back again. Some make it back whole, and others simply never survive…

After several years away from full-time internationalization work, I’m happy to announce a significant change. I am working as the Media Globalization Architect at Yahoo. This is a dream job for me, and one that will definitely be challenging.

My primary globalization experience has been gained through developing internationalization frameworks and APIs, particularly for the Java platform. Sure, I’ve also worked to define best practices for Java EE apps as well, but never on the scale of Yahoo’s media properties! And that’s exciting.

I hope you’ll join me here in this blog from time to time as I write about some of my experiences as a Globalization Yahoo! I haven’t educated myself on Yahoo’s corporate blogging policy, but I do know that I’m tasked with developing and maintaining thought leadership in the globalization arena, particularly for web-based media. So it doesn’t seem unreasonable to share some of my ideas and experiences here.

Until next time,
John O.

Yesterday a coworker complained that Excel wasn’t displaying a CSV (comma separated values) file correctly. Our application allows the user to send a report via email. The application provides the report as a CSV file. Because the report can contain multilingual text, we’ve decided to encode it in UTF-8. Unfortunately, when users click on the file to display it, usually in Excel, all of the multi-byte encoded characters display incorrectly.

The problem was immediately clear to me…Excel was opening the UTF-8 encoded files, but it was incorrectly identifying them as Latin-1 encoded files. In the absence of any charset identification, Excel must guess about a file’s content encoding. In our environment, many host PCs use en_US locales with Latin-1 as the typical charset. Excel uses that default to read and display CSV files.

My solution to the problem was to use the byte-order marker (BOM) to identify the CSV file as a Unicode file. I instructed my colleague to prepend the FEFF character to the file. The Java application that writes the file uses a FileWriter that encodes to UTF-8 to create the CSV file. It was simple to just output the BOM as the first character in the file.

Now when our customers double-click on these files, Excel opens the file, notices the BOM, and automatically selects UTF-8 as the file’s charset encoding. Now Excel displays the previously mangled characters correctly. And I was able to help resolve a problem with an easy solution.

Maybe you can give your applications a hint about plain text files as well. Writing the BOM to your file can help Unicode-enabled applications know how to decode your Unicode files.

This job sounds fantastic to me. If you enjoy the i18n business and are ready for what sounds like a great opportunity, check out Symantec in Mountain View, CA. I’m not affiliated with Symantec in any way, nor do I know anyone that works there. It just looks like a great opportunity for someone. If I weren’t comitted to the Ventura/LA area, I’d be there in a heartbeat!

Here are some of the details and a link directly to the their job search site. Type “internationalization” into their search engine.

Internationalization Technical Manager
Job id: 587240

Shared Engineering Services – US Internationalization
The International Engineering & Tools Services (IETS) group is responsible for making Symantec products ready for the worldwide market such as EMEA and Asia Pacific & Japan regions. The group provides specialized services to product engineering groups, from software design to verification, and also leads engineering directions and standards on product development for international deployments

Responsibilities

• Manage a team of highly technical Internationalization developers and engineers responsible for providing specialized development services to all Symantec product development groups and establish strong work relationship with all product development groups.
• Take a leadership to standardize company wide software design for use of International environments.
• Work with the product development groups to set their engineering plan aligned with Internationalization standard and best practices for the international customers.
• Take a responsibility of having Symantec software products achieve Symantec standard quality before the releases for the international customers.
• Ensure that the world wide Internationalization development group members are following a defined development process throughout the product lifecycle to achieve goals for the international customers.
• Cooperate with the regional managers to prioritize and make work assignments and tasks based on members’ skills and availabilities.
• Set clear objectives for direct reports and keep track of deliverables and qualities. * Manages day-to-day technical decisions with the team members on the internationalization development activities.
• Be responsible for the technical development and improvement of the internationalization development functions.
• Interface with senior management and senior engineers in the group to report on operational goals and technical directions.
• Direct an Internationalization development area by acting as a project team lead.
• Mentor less experienced team members in advanced technologies, and develop and perform technical skill development plans.