Among the various possible approaches under discussion for object translation in core, see for a complete list:

1. Each item that has translatable properties declares them on its fields ('translatable' => TRUE).

2. Locale module creates and maintains a parallel table for each table that includes translatable properties. E.g. if myobject has three translatable fields ('name', 'title', 'description'), Locale would create a table 'locale_myobject' and assign it the fields name, title, and description plus the primary key field or fields plus a language field.

3. In the db_select object, we add a method, $query->translate(). This would iterate through all existing tables, consult the schema, and (a) if fields have already been added, join on their locale_x table and load the translated version of the fields or (b) if it's a query for all fields, fetch all translated fields. $query->translate() could accept an array of languages, in which case there would be a join per language.

4. Add a method to db_delete to run any deletions also on locale_x tables.

#3 locale_textgroup_schema.patch8.3 KBJose Reyero
Failed: 9650 passes, 8 fails, 2 exceptions View


Jose Reyero’s picture

This looks like a great idea to me. Pushing the concept a bit further I'd add two options for the schema:

- 'localizable' => TRUE, for fields. That would replace the one mentioned above and means it is a string that may be localized.
- 'translatable' => TRUE, for tables. This would mean this table stores object with language attribute, and such objects may be translated as a whole (create another language version of them which will be somehow linked to this one)

In addition to these two, there's the language field (which we should make a 'reserved' name), and will mean this table stores objects with a language, and in turn, if running any 'language selection' option, the query conditions can be added in automatically. I.e. if you just want to see content only for English language, any query for selecting lists of objects will add the condition alias.language IN ('en', ''), thus we'll see only English or language neutral stuff.

While a 'translatable' table will have a linked table, which can be created automatically if translation module enabled like.

trid, int, translation set id
id, int numeric primary index in the linked table
nedjo’s picture

Status: Active » Postponed

#367595: Translatable fields may render this approach unneeded--or maybe not, if we're left with properties that won't be converted into fields.

So postponed until #367595: Translatable fields takes shape.

Jose Reyero’s picture

Status: Postponed » Needs review
8.3 KB
Failed: 9650 passes, 8 fails, 2 exceptions View

This is a rough draft of what this could be, waiting for the locale API to be improved...

The idea: you just need to ad 'localize' => TRUE to the fields to be localizable, locale handles the rest
* It adds a 'This field is localizable' to fieds in forms. First you need to add the '#schema_table' property for CRUD forms
* Hooks into object updating (which ideally would be done all through drupal_write_record or similar), and updates strings

The trickiest part is to do all the 'textgroup - table - field - string_id' mapping, that is sorted out in this patch.

For localizing objects later (once we have the strings handled and translating) we could use something similar to #141461: Object translation option #1: locale system, optimization strategies

There are a pair hacks for it to work with content types (they don't use drupal_write_record).

*The issue with this approach to be workable is that we need some object api (write, update, load, etc...) with some hooks so we can plug in when any object is created/updated/deleted/lodaded without implementing a thousand hooks. So maybe we should give one more push to

So patches this needs:
#361597: CRUD API for locale source and locale target strings
#365899: API methods for schema-based load and delete operations

Status: Needs review » Needs work

The last submitted patch failed testing.

plach’s picture

Version: 7.x-dev » 8.x-dev

I am afraid we will have to reconsider for D8 :(

jhedstrom’s picture

Version: 8.0.x-dev » 8.1.x-dev
Issue summary: View changes

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.