How i built fortmcmoney.com – Part 5 – Internationalization

In the fifth post of the series, i will talk about how i handled Internationalization (I18N) in fortmcmoney.com. I will explain how this process started and how this process evolved to what it is.

Introduction

Fort McMoney is available in 3 languages: french, german and english. Internationalization always bring a great challenges when developing interactive experience. First, you have to put a system to load files containing labels for selected language. After, you have to build fluid UI components to ensure your labels fit into each of your components. As it may look simple at first, it’s always harder than you think.

Static JSON files

When i first started I18N on the project, i’ve created 3 JSON files, one for each language, that looks like this.

Editing was made in a text editor by me when requested by QA team. That system worked great at application level, but not on management level. QA team wanted a way to edit label quickly without disturbing me all the time.

Using our CMS to build JSON files

The custom CMS developed for the project was already giving QA team a lot of flexibility over our application. They wanted the same flexibility with labels edition. So, our backend developer created a simple CRUD view (Create, Read, Update, Delete) that saved all our labels into a database table. After saved into database, the script collected all labels for french and outputted it into a JSON files saved on the server. The same operations was made for english and german labels.

This system as work perfectly until the project goes into production. As the project was hosted on Amazon Cloud Services, our CMS was hosted on around 100 instances running independently. The problem occur when labels were edited. The database saved the results and outputted the JSON files into server from which the save request was made. The 99 other servers were not updated. We had to find a solution to this problem.

Dynamic JSON caching

Our problem was the result of using static files hosted in each server instance. I’ve suggested two solutions to our IT team.

1. Save JSON files in a static server instead of Amazon’s instance hosting our CMS
2. Use dynamic caching to serve JSON labels from our CMS instead of loading JSON files

Our IT team choose to go with solution 2, as it was quicker to deploy in production.

So, we deleted all three static JSON files and started delivering JSON labels from database on application startup. It works great, but it created a huge load on our database server and could result in a potential crash during peak. We could do better.

We decided to cache JSON output, on database updates, and delivered cached data when requested on client side. When a label was created or edited, the cache was cleared and rebuild using the new data. That system work like a charm for us and it’s the solution used in production right now.

Audio and video subtitles

There is a lot of audios and videos were spoke language by characters didn’t match user language. Subtitles, for each audio and video files, are loaded only when necessary into SRT format. I’ve used this AS3 SRT Parser with some custom changes. This file format prove to be stable in my application and easy enough to edit by our QA team.

Conclusion

I hope you enjoy this post about Internationalization in fortmcmoney.com. In the next post of the series, i will talk about dasbhoard development in fortmcmoney.com.

Thanks for reading.

Posted under Fort McMoney
Tagged as Tips, Internationalization, Fort McMoney, Case Study