Internationalization
Posted: Tue Sep 16, 2008 11:11 am
I'm looking to internationalize my community application.
For front-end templates, I will be using different language folders for each language. That's the easy part.
The hard part is internationalizing the database data end.
It's not just articles that will need to be translated. It's also user profile fields such as names, addresses, etc. stored in the database.
Here's an idea. Tell me what you think...
Create a duplicate database for each language, complete with data. The English version will be named EN, and a Spanish version will be named SP.
Now, suppose user John selects Spanish for his language preference, all data will be now be read from the SP database.
John adds a new friend in the system. This data is saved in the SP database. Obviously this data needs to replicate to the other language databases. The database has a trigger which copies data to the EN database. It's all wrapped in a transaction so in case the trigger update doesn't work, everything rolls back.
Next, John writes a new blog entry XYDD. This entry is then saved in the SP database. However, since no such blog ID exists in the EN database, the trigger also copies it there.
Now, John switches to the English language, and thus the EN database. He then views the XYDD blog entry, and sees the Spanish content. He modifies it to English and saves it. Since the default language of the site is English, triggers in the EN database are different in that they will try to replicate the change to all databases that don't have the XYDD blog entry content.
Would something like this work? It sounds like a lot of data duplication, but the advantages are:
For front-end templates, I will be using different language folders for each language. That's the easy part.
The hard part is internationalizing the database data end.
It's not just articles that will need to be translated. It's also user profile fields such as names, addresses, etc. stored in the database.
Here's an idea. Tell me what you think...
Create a duplicate database for each language, complete with data. The English version will be named EN, and a Spanish version will be named SP.
Now, suppose user John selects Spanish for his language preference, all data will be now be read from the SP database.
John adds a new friend in the system. This data is saved in the SP database. Obviously this data needs to replicate to the other language databases. The database has a trigger which copies data to the EN database. It's all wrapped in a transaction so in case the trigger update doesn't work, everything rolls back.
Next, John writes a new blog entry XYDD. This entry is then saved in the SP database. However, since no such blog ID exists in the EN database, the trigger also copies it there.
Now, John switches to the English language, and thus the EN database. He then views the XYDD blog entry, and sees the Spanish content. He modifies it to English and saves it. Since the default language of the site is English, triggers in the EN database are different in that they will try to replicate the change to all databases that don't have the XYDD blog entry content.
Would something like this work? It sounds like a lot of data duplication, but the advantages are:
- Less code change for internationalization
- Less per-database bloat, so performance is gained
- More chance of errors when writing data, since multiple sources must also successfully update.
- Triggers, which nobody seems to like... although I say this one might be ok, since it's not really altering data in the same database. It's altering the same fields in another database.
- Something I'm not seeing, since I haven't seen anyone propose doing it this way before.