Steampunk company management video game

Difficulties with internationalization

Print Email

InternationalisationFirmLife is a game that will be available in several languages. This involves the modification of the language choice and of the web site content.

This work can be simplified for static contents if the engine used is good enough, however, when working with dynamic contents it is much more complicated, mainly when we want to keep a common database that does not change with the language.

In this article I will explain how we did to solve this issue and what the solutions we had were.

What we want to do

To begin, here is a small chart of what we want to do:

Firmlife DBAs you can see we would like to have a common database containing some tables (like users) and we would like to have databases with the same structure but different data (like languages).

To choose which database we want to use we will call a function at the beginning of each request that will return the database value (for instance: it would return the current user language for him to see data from the English database).

The solutions

To manage internationalization of dynamic contents, there are several solutions. I'm going to describe the main ones with their benefits and flaws in the case of our game and the engine we use.

One web site per language

With this solution there is one entire web site per language. Language separation is well defined; however it is not possible to have a common database. Moreover, this kind of web site is much more difficult to maintain because all the source code is repeated for each language.

A language field for tables of the database

This solution allows us to separate languages and continue to have data common for all languages. It would have been a good solution if data retrieval was not that annoying. Indeed, with this solution, to display data for a language we have to filter data in function of the language, which means that requests to the server are heavier and that there is a bigger risk to make mistakes!

A database per language

Another solution would be to have a database per language and to keep a common database. This solution has the benefit of working very well but it is not easy to develop.

The chosen solution and difficulties

The last solution being the best one, this is the one we chose despite its complexity of integration because we need a robust system to manage the internationalization of the web site.

The development of this solution was not easy and we encountered several difficulties. Indeed, the engine we are using for the web site is not supporting this kind of feature in its current version. Thus, we had to anticipate and modify the engine's source code by ourselves. Then, we had to write a new plugin to automate the choice of the correct database and connection.

After all this work done, we finally managed to develop our internationalization system allowing us to keep common data. With this system we can have several database types: not only the common database and the databases for each language but also, for instance, databases for each instance of the game, and so on. To do so it is very easy because we just have to annotate our models to specify their database type and for each type a database will be created for each value/language with all the affected models inside. The choice of the value/language for each type of database is defined at the beginning of each request by calling a specific method for each type.

This system allows us to manage our databases in a very flexible and automated way. Thus, selection of the correct database for the current request and the current model is hidden for the developers and for the users and it works well!

FirmLife won't be limited only to English and French, thus more languages will be added very easily with this new system!

Post your comments...

    Newsletter

    Random image

    Who is online ?

    We have 142 guests and no members online

    Calendar

    << < December 2017 > >>
    Su Mo Tu We Th Fr Sa
              1 2
    3 4 5 6 7 8 9
    10 11 12 13 14 15 16
    17 18 19 20 21 22 23
    24 25 26 27 28 29 30
    31            

    Twitter

    Twitter