Posted by adraskoy on November 22, 2010 at 7:47pm
I'm updating a contrib module to be i18n-compatible, and am finding the documentation thin on the ground, mostly a few notes here: http://drupal.org/node/313262
Digging through the code it appears that aside from node content, the main i18n support is for drupal variables. So, for a module to be compatible we need to make sure that it stores its data in drupal variables. Is this correct? The module I'm working with uses a custom table instead so I figure that switching to drupal variables is probably the best way to add i18n support.
Thoughts? Once I've got this working I will contribute some documentation for i18n, so knowing about any other relevant mechanisms not mentioned on the page referenced above would be useful.
Comments
For performance reasons, it's
For performance reasons, it's a bad idea to use Drupal variables for large amounts of data, and especially not for values which will be updated frequently. The reasons why are discussed here.
What does your module do? If it simply needs to be "language aware" then you probably don't need to be concerned with i18n. Read the global $language object and process accordingly. $language->language gives you the code for current language, such as en (that's for D6, in D5 it was in $locale.) If your module is dealing with nodes, then you may want to use translation_node_get_translations to find translated versions of a node.
Hope this helps.
Currently part of the team at https://lastcallmedia.com in a senior Drupal specialist role.