I would like to know if my approach is correct for a website that offers its content, managed by a CMS, in different languages.
The page itself:
People can book routes with a travel guide. Very simple. Now the company needs to add routes to the database in different languages.
I thought, that it basically creates the route and than can add descriptions in different languages. So I would basically store the content and the title of the route in a separate table with the route id and a language code.
What do you think ?
Here a picture of my ERM in MySQL Workbench.
http://imageshack.us/f/194/witchrouteerm.png/
Has anybody had similar projects and thinks that this approach will result in a problem or do you think it is the correct way ? I cannot really think of a different way. As I don’t want to give the route an additional column such as “lang_code”. As I would than need to create the route itself several times. This obviously is possible but more difficult to manage and more time-consuming regarding setting the Dates and so on.
I am looking forward receiving some comments here from people who had to make similar decisions about multi language support.
All the best,
Richard
Separating the language specific descriptions would be typical. The “locale” of the data descriptions should match the “locale” of the user. In your ERD, you have two columns (country and language) on the user table, but only one column (lang_code) on the content table. You would want to make them consistent. Go for the two columns, language and country, and follow a standard. All text would need to be separated (does “title” in “difficulty” need to be locale specific as well?)
The standard will depend on how you are determining the locale of the user (http Accept-Language header? user input?). The locale could be a two character language code (ISO 639) and a two character country code (ISO 3166). So, en_US, en_GB, en_CA, fr_CA, …
You may want to enforce a business rule that an American English language description must always exist for a route. Then you could have a hierarchy of preferred languages for a user. For example, if the user’s preference is defined as Portuguese Brazil (pt_BR), but you don’t have a route description for that, you could try Portuguese Portugal (pt_PT) instead, and if that does not exist, revert to English US (en_US). By keeping the language and the country as two separate columns, and introducing another field to flag default description for a language group (ie flag pt_PT as the default pt language if other variations are not found) you can make these kinds of operations a bit easier to perform.