Internationalization and Date Formats

By Kyle Chow, Technical Localization Specialist at Nintendo and GlobalSaké NextGen Roundtable Member

Something I often see when trying to use the Japanese version of a website is that dates are written in a way that screams "the underlying framework of this site is US English!" For example, the screenshot above shows an article from January 17, 2025, where the date is being displayed with the UI set to Japanese. However, two major things stick out as unnatural to a Japanese speaker here:

The date format is the US English format of “<month> <day>, <year>”, whereas Japanese date formats are “<year><month><day>”.

The month (January) is displayed as a 1 with the accompanying character for month (月) - which in itself is correct - but the day and the year are simply displayed as numbers, whereas they should also have corresponding characters. The natural way to write the Japanese date would be 2025年1月17日.

The way I'd guess the date ended up looking like this is that the words for the months (January - December) were all translated into other target languages, but the day and year were left as variables because they're simply integers in the code, and then the final date display just concatenated these elements in the display order: 

“<word for month> + <number for day> + comma + <number for year>”. 

This works for US English…but not for pretty much any other region in the world.

So how do you fix this? One method is to adjust the underlying code framework by implementing an internationalization library. In this way, you can simply insert a "date" placeholder for each placement you want to insert a date, and the date format rendered to users in real-time will auto-adjust based on the user's locale.

Other regional differences such as number formats (for example, "1.3 seconds" versus "1,3 seconds", where some regions use a decimal point where others use a comma) and currencies also require similar solutions. While it can be tempting to put all this off, if you wait until years of work has already been done around a framework that doesn't support these regional differences, the cost of making the necessary changes will have multiplied exponentially compared to if they had been implemented upfront. And trying to clean things up will be a nightmare.

Having a date formatted differently may seem trivial, but these are the things that can make or break a user having a seamless experience versus a user thinking "hmm, something feels a bit off" and ending up not making a purchase or churning. So, just a reminder of the range of Localization’s scope--the cross-functional teams need to get onboard from the start!