SmoothFriction.nl

posts - 39, comments - 20, trackbacks - 0

Saturday, November 21, 2009

The importance of specifying your locales

Lately I’ve run into several bugs which were caused by developers incorrectly assuming that the default locale settings were good enough for parsing a value. I’ll show you what I mean.

Case 1

Consider the following snippet:

.something {
    width: 21.4em;
}

This is a simple CSS rule, making all elements with class ‘something’ have a width of 21.4em. In .Less, we parsed this without an explicit locale. The output would only show 21em, truncating the value from the implied decimal separator onwards. Once we set the locale to Invariant (who needs specific locales in CSS?), the problem was fixed. All in all a fix of only an extra parameter on the parse method.

Similarly, I am setting up a private TeamCity server, just for trying out how it works. I used a git plugin to enable downloading the source from github, which threw an exception when parsing the date. Consider the following two snippets:

  private static final String GIT_DATE_FORMAT = "EEE MMM dd HH:mm:ss yyyy Z";
  private static final String VERSION_DATE_FORMAT = "MM/dd/yyyy HH:mm:ss";
  public static final SimpleDateFormat GIT_DATE = new SimpleDateFormat(Constants.GIT_DATE_FORMAT);
  public static final SimpleDateFormat VERSION_DATE = new SimpleDateFormat(Constants.VERSION_DATE_FORMAT);

  private static final String GIT_DATE_FORMAT = "EEE MMM dd HH:mm:ss yyyy Z";
  private static final String VERSION_DATE_FORMAT = "MM/dd/yyyy HH:mm:ss";
  public static final SimpleDateFormat GIT_DATE = new SimpleDateFormat(Constants.GIT_DATE_FORMAT, , new java.util.Locale("en"));
  public static final SimpleDateFormat VERSION_DATE = new SimpleDateFormat(Constants.VERSION_DATE_FORMAT, new java.util.Locale("en"));

The first one is the bugged one, the second one is the fixed one. All I did was make sure the date is being parsed expecting english localization. This simple fix enables the plugin (it’s from the git-teamcity plugin on github) to work on any system, opposed to the ones who happen to have their locale set to any english variant.

This leads me to one conclusion: developing on a non-english locale is a good thing, you’ll find a lot more bugs that way! Joking aside, these examples led me to be a lot more careful with assumptions, especially on region specific settings.

posted @ Saturday, November 21, 2009 1:24 AM | Feedback (0) | Filed Under [ general localization ]