Prepare field label and description for DDT (translatable queries)

This looks like a good start of a generalized approach to non-field string translation in core, which would be, don't handle it in core (at least for D7), but use drupal_alter() to enable a contrib solution.

This indeed relates to #357529: Implement translation of customized 'translatable' views properties in that that patch could do the same. That is, remove from that patch everything to do with a handler and instead merely call drupal_alter() as needed. The handler could then be handled in contrib in a way that applied not just to views or fields but to any non-field string.

If we take such an approach, the drupal_alter() call should start with something like this for all translatable strings:

drupal_alter('strings', $strings, $type);

where $type is the type of object the translation is needed for. E.g. in this case:

drupal_alter('strings', $strings, 'field', $instance['field_name'], $instance['bundle']);

Translation could be only one of the possible hook_drupal_alter_strings() purposes.

Great idea, although I am wondering about performance implications. We might make the call in a wrapper function which would check against the language_count conf variable to avoid the hook invocation for unilingual sites.

We might want to generalize the hook name by calling drupal_alter('translatable', $type, ...).

Edit: this might help also with translatable field settings. e.g. allowed values.

The current patch implements the generalization proposed in #3/#4.

the patch

mmh, we probably need to find another place to apply the translation as we get the translated value also while editing the original string (see the attached screenshots).

IN #357529: Implement translation of customized 'translatable' views properties we're setting a flag on the view object when editing:

+      // Set a flag to indicate that this view is being edited.
+      // This flag will be used e.g. to determine whether strings
+      // should be localized.
+      $view->editing = TRUE;

@yched: Yes, that flag is already part of Views (not introduced in the patch). Right now at least some of the values of flagged properties are passed through t(). The patch introduces support for plugins for different translation options.

For fields, yes, I guess a flag would also be good to avoid having to hard-code the translatable properties.

So far we've identified label and description as translatable. What other properties might be translatable? I guess admin-entered select options for a text field would be one.

While it's tempting to use drupal_alter(), that only really makes sense if we potentially want what drupal_alter() is designed for--more than one module making alterations. If instead what we want is a single translation handler, we'd probably need a way to register a handler.

+    drupal_alter("translate_$type", $object, $options);

If we do use drupal_alter(), probably it would be good to be able to catch all translation in a single alter hook implementation.

+    drupal_alter('translate', $properties, $type, $options);

That would mean we'd have to pass not the object itself but a stripped-down version with only the translatable properties.

If we think for a moment from the point of view of modules implementing translation, so far (in i18nstrings) we've tended to create a unique ID for strings to be translated. For example, the description for taxonomy term with tid 21 might be taxonomy-term-21-description. Using an id allows for updates and deletions of translations. So we might end up with:

+    drupal_alter('translate', $properties, $id, $options);

where $id might be (in the taxonomy term example) array('taxonomy', 'term', '21').

Missed this, subscribing.

huh? Why "translate_$object"? Usually, there is 1 module that takes over translation services for objects and it just needs to know how to handle the object.

Consider how many hooks i18n would have to implement to allow to translate object values...

So, drupal_alter("object_translate", $object, $type, $options) would do better.

However, not wanting to hi-jack this issue - but apparently I'm tinkering about normalizing object data (or exploding data into multiple table columns) and adding a magic query tag throughout core for some time now. Use a table as outlined in #141461-26: Object translation option #1: locale system, optimization strategies (and as implemented in Translatable module) to auto-perform a LEFT JOIN on all tagged queries to auto-load the proper data initially already. Separate issue, not existing yet.

That issue now exists and even works better than I imagined: #593746: Prepare Drupal core for dynamic data translation

subscribing...

More complex is how field_read_instance() and field_info_instance[s]() should handle the notion of 'translated' or 'non translated' instance information.
Bottomline is: the properties that show up in Field UI's forms should always be the *untranslated* ones, or the translated values will end up being saved as the primary definition.
Similarly, the following API sequence:

This issue, we will have to tackle in a general sense, because it not only applies to field labels + descriptions.

Let's see what the bot thinks about this patch. :)

Failed: Failed to install HEAD.

mmm, test bot was working? Lets try again.

Looks nice and elegant. Thanks, yched!

Why are we changing core's DB schema around at this point in the release cycle? Shouldn't this be handled by i18n module?

The original post talks about removing some ugly dynamic t() stuff, but I see no hunks like that in this patch. Therefore, this seems like an API addition to me?

Are there other data that may be serialized into the 'data' column - e.g., attributes added by contrib modules - that require translation?

If so, simply pulling label and description into the schema as separate fields helps, but it's an incomplete solution--and one that contrib can't (easily) follow.

We're going to continue to have strings that require translation and that are stored in serialized fields. This issue came up in #357529: Implement translation of customized 'translatable' views properties (see sun's comment).

@nedjo:

Are there other data that may be serialized into the 'data' column - e.g., attributes added by contrib modules - that require translation?

Surely List's allowed values, which really need a way to be translated.

I should clarify that Dries and I are not necessarily opposed to API changes at this stage, if they fix critical issues. We just want to avoid them when we can, and ones that affect lots of module/theme developers need a really good excuse.

subscribing

meta issue: #717610: Remove t() calls from $instance['label'] and $instance['description']

subscribing

#25: field_label_translate.patch queued for re-testing.

I'm afraid this is for D8 now :(

Related issue: #1016006: Default title, body and other field labels not localizable.

Some examples of not being able to translate field labels and their description (as motivation of fixing this in D8):
#1028538: Some shortcut links not translated
#1052478: 'Find content' not translated in Content shortcut bar

Related (almost duplicate) issue: #1130732: Field label translation not displayed or can only be translated as a built-in-interface string with english as default language.

Related issue: #1157426: Field system uses t() incorrectly and inconsistently.

I guess we need to wait to figure out how to address object translation in general before going on with this (see the discussion going on in the issue above).

See also: http://groups.drupal.org/node/149984

Do we know how object translation is dealt with now? If so should this still be postponed?

This is a completely obsolete approach for D8: we are leveraging config translation now.

Brilliant, thanks @platch. I was just trying to clean up some of the Postponed issues that seemed to get stalled!