Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Among the various possible approaches under discussion for object translation in core, see http://groups.drupal.org/node/18735 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.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | locale_textgroup_schema.patch | 8.3 KB | Jose Reyero |
Comments
Comment #1
Jose Reyero CreditAttribution: Jose Reyero commentedThis 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.
Comment #2
nedjo#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.
Comment #3
Jose Reyero CreditAttribution: Jose Reyero commentedThis 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
Comment #5
plachI am afraid we will have to reconsider for D8 :(
Comment #6
jhedstrom