Currently in Drupal core we have no general solution for making fields translatable.
There are several emerging options. Here are some. If you know of others, please add them in, and also add more information on those already listed.
Choosing between these approaches is the key challenge as we implement translation of user-defined strings in Drupal 6.
- Extend the locale system to support translatable objects
- Summary: This option would extend the
- Issue: http://drupal.org/node/141461.
- Existing UI and storage.
- Consistency with other string translation.
- Build-in support for .po import/export.
- Existing patch.
- Requires separate handling for each field. E.g., each string is translated separately, out of context, and in the code a separate call is required each time a field is to be translated, inserted, updated, or deleted.
- Records are fragmented among many rows, making it costly to load translations.
- Follow the node/tnid approach for other object types (users, etc.)
- Summary: Currently the node table has a langauge field and a tnid field for linking nodes as part of a translation set. This approach would do the same for other objects. E.g. taxonomy terms would get language and ttid fields. taxonomy/term/21 might be a French version of taxonomy/term/20 (English).
- Issue: none.
- Consistency with nodes.
- The node approach of having a separate object per language has raised many challenges and difficulties--dealing with multiple paths, handling changes in tnid, determining between tnid and nid as primary object identifier, etc. These would multiply if all our other objects that need translation followed the same approach. Multiple records per user, one per language, each at a different address?
- Parallel tables, automated locale handling based on schema
- Summary: In this approach, fields that are translatable would get a 'translatable' => TRUE attribute. The locale system would scan tables for translatable fields and create parallel tables with all primary keys, translatable fields, and a language field. Automated handling of translation on CRUD operations.
- Issue: http://drupal.org/node/367603.
- Fields API includes built-in support for translation
- Summary: In this approach, the new Fields API would include built-in support for translation. To make a new or existing field translatable, one would simply convert it to use the fields API.
- Issue: http://drupal.org/node/367595.
- Build in support would mean no need for custom handling of each translatable field.
- Greater incentive for use of the new Fields API.
- Translations wold be loaded on initial object load, rather than waiting until later and loading each translation as a separate override.
- Wouldn't handle data not converted to the Fields API.
- Don't solve this in core, but introduce a hook to allow contrib to solve.
- Issue: http://drupal.org/node/155047.
I read an email saying this sprint should happen over the next two weeks. That's probably a bad idea considering the resources necessary to complete the Drupal.org redesign. --David Strauss on 1 Feb 2009