API documentation for development other modules

I agree with Nancy. I would like to make Vocabulary Index compatible with i18n. For that I need to know about the possibilities to generate a taxonomy tree, but only with the terms belonging to the currently used language. Does i18n provide a function like taxonomy_get_tree() or do I have to create my own function that includes i18n support for creating trees?

So you say i18n override the taxonomy_get_tree() query? That's worth checking it out...

i8ntaxonomy 6.x has db_rewrite_sql:

/**
 * Implementation of hook_db_rewrite_sql()
 */
function i18ntaxonomy_db_rewrite_sql($query, $primary_table, $primary_key){
  // No rewrite for administration pages or mode = off
  $mode = i18n_selection_mode();
  if ($mode == 'off' || arg(0) == 'admin') return;

  switch ($primary_table) {
    case 't':
    case 'v':
      // Taxonomy queries
      // When loading specific terms, vocabs, language conditions shouldn't apply
      if (preg_match("/WHERE.* $primary_table\.tid\s*(=\s*\d|IN)/", $query)) return;
      // Taxonomy for specific node
      if (preg_match("/WHERE r\.nid = \%d/", $query)) return;
      $result['where'] = i18n_db_rewrite_where($primary_table, 'taxonomy', $mode);
      return $result;
  }
}

The mention of taxonomy_get_tree:

// Produces translated tree
function _i18ntaxonomy_term_select($title, $name, $value, $vocabulary_id, $description, $multiple, $blank, $exclude = array()) {
  $tree = taxonomy_get_tree($vocabulary_id);
  $options = array();

  if ($blank) {
    $options[0] = $blank;
  }
  if ($tree) {
    foreach ($tree as $term) {
      if (!in_array($term->tid, $exclude)) {
        $choice = new stdClass();
        $choice->option = array($term->tid => str_repeat('-', $term->depth) . tt("taxonomy:term:$term->tid:name", $term->name));
        $options[] = $choice;
      }
    }
    if (!$blank && !$value) {
      // required but without a predefined value, so set first as predefined
      $value = $tree[0]->tid;
    }
  }

  return array('#type' => 'select',
    '#title' => $title,
    '#default_value' => $value,
    '#options' => $options,
    '#description' => $description,
    '#multiple' => $multiple,
    '#size' => $multiple ? min(9, count($options)) : 0,
    '#weight' => -15,
    '#theme' => 'taxonomy_term_select',
  );
}

Cleaning issue queue for old versions. If you want to get any support consider using the forum or updating to 6.x.

See #626858: Internationalization 5.x Maintenance Policy. Approaching end of support.

OK, I was just closing all 5.x issues...

About this, there's an API function to disable/change query rewriting. See i18n_selection_mode()

@NancyDru,
Yes, i18ntaxonomy uses db_rewrite_sql() to add language conditions to queries. The problem with this hook is we need some heuristics here for identifying the queries, and we try to use as far as possible Drupal core (unofficial) standards for table names and fields. For taxonomy these are 't', 'tid', 'vid'....

So please let me know what we would need to support any other module, but we cannot just add any table alias because that may clash with other different contrib modules too..

I haven't really worked with the i18n module in the past but I am on a contract to work on a site for a major international organization that has a site which is available in five languages. The site also is also using several contributed modules to provide content as rdf (rdfcck, evoc, sparql). The way I am reading the db_rewrite_sql implementation in the i18n module is that it's going to add the (WHERE n.language="en"...) clause to any query which uses db_rewrite_sql, even if the query is accessing a table which does not have a language column. Since the rdfcck and evoc modules use db_rewrite_sql in several of it's queries, but the tables the modules use do not have a language column those queries fail. Since these are contributed modules, that haven't been updated in awhile I'm not sure I can expect that they'll be changed anytime soon, so if I'm going to continue to use the i18n module do I have to patch any contributed module which uses db_rewrite_sql if the i18n module is enabled?

Is this a bug in the modules which use db_rewrite_sql for not taking into account what any other enable modules which implements the db_rewrite_sql hook might do, or a but in the i18n module for making the assumption that any module which uses db_rewrite_sql code is going to provide a language column in any table it access and write the SQL such that the i18n_db_rewrite_sql function will rewrite it correctly?

I haven't looked at the code in detail but I just brought up a clean drupal instance, enabled the content translation and locale modules and the latest 6.x version of the i18n module. I installed/enabled the devel module so that I could execute some PHP code and executed the following:

print db_rewrite_sql('select * from {files}');

and it produced the following result:

select * from {files} WHERE (n.language ='en' OR n.language ='' OR n.language IS NULL)

It looks to me like it *is* touching queries which are accessing tables other than the node table.

Cleaning old issues (> 1 year without follow up)

@NancyDru,

Yes, but I mean I am not following up on these old 6.x issues. And if no one else is we better close this one...

Also, I don't see specific questions here, we are not producing any handbook page, etc...

So if you have specific questions about i18n API, need a better documentation for a function, etc, I'll try to fix / replay to that ones. That's why we have a 'Documentation' category for issues. But I think it will work better one question at a time.

But if not, really, having more issues open is the better way to make this issue tracker useless.