Multi language content

If Modx database is modified fot next realesed, I think it will be great to modify thinking query optimization (by optimizing database structure).

I was a database administrator before I ever learned to code, and have a lot of experience developing and maintaining multi-lingual web applications for telemarketing. Database optimization and overall optimization of requests served by MODx, are definitely among my top priorities for this effort.

If we need to replicate each chunk, site content, template variables, and templates, soon or later we will have a lot of tables filled up in the database. But considering that we are going to have only 2-4 translations at one site, so we need to have 8-16 tables to support the translation, compare to 4 tables, when we are not replicating the tables.

Now lets talk about the amount of rows needed. Lets say that each site usually contain 200 site contents, 5-15 template variables, which sum up as 1000-3000 rows, 1-5 templates, and 100-150 chunks. So if we want to duplicate into 4 languages without replicating table, here is the number of rows needed.
site contents: 800 rows
template variables: 4000-12000 rows
templates: 4-20 rows
chunks: 400-600 rows

"SELECT COUNT(langid) FROM content_language WHERE docid=5"

I do not know what this will result in the whole php code... should I try on my own?

the multi-table solution is query-quicker, guillame is right (the problem with queries is the table size, not the whole database size)... but there is not only the content table to duplicate, there are also TV, metatags, and so on... while with "lang field solution" we have only a new field in these tables: it’s much easier to mantain!

for queries, I cannot figure out now how we can easily (i.e. with one query) filter the content in order to have all pages in the language preferred and, when these are lacking, the default language counterpart

I think that finding a way in which we can have that query, will solve if not all, a large part of the problems

for jason: I am always around here.. ;-)... do you know a way to have day of 30 hours? ;-)

(...) I am in the process of porting back down to PHP 4 so MODx can utilize it. It is also going to greatly simplify the core code and API’s in the process, hopefully, further improving MODx page rendering performance.

Quote from: madmage

for jason: I am always around here.. ;-)... do you know a way to have day of 30 hours? ;-)

On my roadmap already

I would hold off if you can on coding this yourself; I already have the data structure and new parser design to solve this implemented in PHP 5 (part of the development cycle of Tattoo), which I am in the process of porting back down to PHP 4 so MODx can utilize it. It is also going to greatly simplify the core code and API’s in the process, hopefully, further improving MODx page rendering performance.

ahem... it’s not so clear to me (damned babel of languages!)... do you have some big modification (data structure and new parser to solve WHAT?) that I should know before trying to close this issue?

i.e. you WILL modify the MODx porting back Tattoo stuff or you are not sure about this?