HAve you looked at any other programs for pointers
While Ripping through a lot of open source software, I run accross the multi-language support issue a lot. I always remove it for my implementations, but have seen some nice work in OsCommerce and phpMyAdmin. Before wasting a lot of effort try looking at the source, or just their db structure; I know wasting time is fun though...after all, we all are using php here.
I faced the same problem some time ago, our requirements were the following:
1. the CMS had "X" number of classes of content (each with different attributes).
2. some attributes could be translated to "N" languages on different charsets. no on-the-fly translations, we used human input.
After trying many approaches, we defined our strategy by taking as much work as possible into the db server and working with simple views. Accessing different translations and classes was transparent to the scripted part of the model (we had implementations for Java and PHP).
I'm not allowed to post details about the solution, but I'll give you some tips. I know this might be a little obscure to follow just by reading prose, so I'll try to be clear ;-)
Generalities of our solution:
1. one central table used for the key, creation times, owner... and all fields that conform the content object's main structure. These fields are common to every class of content object.
2. One separeate table for each class. These tables had different fields, specific to each class.
With that we solved the different classes issue, but we still had to figure out how to manage translations. The solution was simple:
3. For each class we created the necessary translation tables (not all fields were translatable).
Ok, so we ended with a lot of tables (X * N), you say. Well, actually a bit more than that. The fact is that everything was thought and tuned to be managed automagically by stored procedures. The database server does literally all the heavy work for us. We could add and delete classes and translations with simple instructions. Search and indexing was also managed this way.
The other approach widely used is to setup a single table that contains all the content object attributes (much like ezPublish does). This later solution, while being very "simple" is also quite limiting, as you cannot perform complex work with the data inside the RDMS. It also has scalation problems and charset issues.
I believe CMS data structure is a very hot topic. I alone have run into enough material to write a book, and I'm sure everyone here has a word and valuable experiences to share. I believe I'm starting a thread on this.
OK, I just thought about this one, although I doubt the efficiency of this solution.
use lang abbreviation as table extension eg. en_table, fr_table etc ...
the queries while inserting and updating coupled with babelfish web service carry out the necessary operations.
Is this idea any good? It'll work for sure I know
Originally Posted by Widow Maker
and was wondering if anyone has used an XSL stylesheet(s) for doing the actual translation, from English to Spanish for example ?
I dont think XSL itself carries out the translation.