the real multi-language Drupal, an elegant way

Hi,

Would that be using another database layer?

I think we will not need any extra database layer, we can use the existing ones - the idea is to change sql query after it was resolved, but before it was executed - that means inside of existing db_query(), or _db_query(), not SQL, but rather regex

for example, we could keep an array of user-selected translation rules

i18n_db_query
 ("node" => Array,
      (
     "description" => "cz_description",
     "story" => "cz_story"
      )
  "vocabulary" = Array,
      (
     "name" => "cz_name",
      )
  )

And during replacement, at first identify what table we are going to work with

SELECT * FROM node WHERE (status = '1' OR custom = '1') AND region = 0 ORDER BY weight, module

I am not SQL-wise, but I would guess it will be after keyword WHERE and maybe some another ones

If it is our table(s), we would target the area(s) after the keyword WHERE and replace all occurences of "node" with "cz_node" - the key is normal, the value depends on the selected language

this, of course, adds some execution time, and it would be the best to avoid regex and perhaps only split the strings and concatenate again, because the function is called before every query

 foreach $item(split(",", $part_of_the_query)){
  if($i18n_db_query[$table]->$item){
     $output .= $i18n_db_query[$table]->$item;
  } else {
     $output .= $item;
  }
}

please, forgive any error in the code above, I do not have any book to hand :)

romca

I think this is realy an issue and currently have no idea about how to do it - there is dba module that display the tables, perhaps we could use it to acomplish this work

the help message would instruct users to choose the correct columns - eg. "please, think before you click - is there any sense translating numbers? do you want your vocabularies to have language dependant synonyms? ..."

and, after the colum was activated, it will be created
SQL command? I do not know

romca

hi,

thanks for all your thoughts (that is why I wrote this call)

changes to the core:
I do see your point, but I think there would not be so huge changes as you think - great and little at the same time, only these lines inside db_query function are needed

if (function_exist(i18n_rewrite_query() && $i18n_translation_enabled){
$result = i18n_rewrite_query($query);
}

so, nothing happens for single-language sites, no overhead

concerning the Jose's comment of translating-everything:
I really do not prefer to translate everything, to duplicate tables, not only because of space, but mostly because of administration - administrative data really should be the same for both language versions, IMHO, administration would be much more easier.

Think about this situation : you create one story in two languages and assign it to several categories (keywords): "facet analysis" , "subject analysis", "information architecture", "20.th century" - and now, you would like to add one more category. How would you do it with i18n?

You must open *all* the created stories and reassign one by one - if you have 4 languages, it will be pain. If you make mistake in one object, it will not be the same for other three.

and even more - when there comes new module, you must implement i18n support if there is no appropriate hook inside (for example, in flexinode, there is no appropriate hook and when you need synchronization, you must do it yourself, or hardcode it).

On the other hand, if we could do it rewriting queries, no hooks are needed (I know, u probably don't like this idea) and user must only create another column and select synchronization for his/her preferred table-column pair. It is simple and should work for every object/module.

I don't like your proposal too much. It would require changes to the core where the current approach works without.

I know, the current approach works and I like Jose's module, without it, I could not use Drupal at all. But look - I have spent many hours before I understood i18n module (i am not coder) and only after then I could rewrite the synchronization functions to work with Drupal 4.4.1.

I will have to the same for Drupal 4.5 (you have said, that it doesn't work with it) and I will have to do it for every new module that I want to be multi-lingual. And I will have to administer copies of the contentually-same objects. This is what your "current working approach" looks like.

anyway, your critique is highly appreciated

romca