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.This is a parallel patch to #367595: Translatable fields. The idea in that patch is to load all translations of a $thing, then decide which one to display at render time. So for fields, we'd load all values like any other multiple value field, except keyed by language, and then in rendering only render $node->field_name[$language]['view'] as compared to the standard $node->field_name[0]['view'].
I'm not yet sure where this decision should live, but here's a possible option which adds support for a #translate property to $elements in drupal_render_children(), and allows only the child in the current language to be rendered if that's set.
Doing it exactly like this would be quite inflexible - we wouldn't have a chance to implement a fallback solution there for untranslated content or whatever. So there might be a need for drupal_alter('children', $element) in there instead - so that locale/translation module could handle anything more complex themselves.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | translation_rendering.patch | 4.19 KB | catch |
| #9 | translation_rendering.patch | 8.6 KB | catch |
| #2 | drupal7-sun.drupal-render-translatable_.patch | 1.41 KB | sun |
| #1 | drupal7-sun.drupal-render-translatable.patch | 1.48 KB | sun |
| translation_rendering.patch | 1.42 KB | catch | |
Comments
Comment #1
sun- Changed to #translatable
- Allow multiple fields.
Comment #2
sun- Wrong key order.
Comment #3
sunComment #4
dmitrig01 CreditAttribution: dmitrig01 commentedLet's use this somewhere. How about nodes?
Comment #5
catchdmitrig01 - see the fields patch for where it'd be used first, although they need syncing up.
The main remaining issue here is we don't have a way to do fallbacks (i.e., if a field isn't translated into Slovak, show it in Czech, if there's no Czech translation, show it in English). I don't think this needs to be handled by core necessarily, but it ought to be possible for contrib to hook in. I think it could probably be brute-forced in hook_node_build_alter() or somewhere else, but ideas welcome. Notwithstanding that, the main thing missing here is tests, will get started on that today.
Comment #6
yched CreditAttribution: yched commentedOne drawback - possibly not major - is that you build and keep in memory all the render arrays for all languages. On pages that list 10s of nodes, that could make a noticeable memory occupation.
Then only one language actually gets themed, but for formatted text fields, for instance, the check_markup step happens *before* theming ('sanitize' step), for all fields (and all languages, in the 'translatable fields' approach) when the $object is viewed.
Granted, that last point can also be seen as a drawback in current D7 fields (and CCK D6) : if a field is 'hidden', we still run check_markup on it...
Comment #7
plachsubscribe
Comment #8
catch@yched, yes there's a risk of more memory issues on sites with either a large number of translations, or long texts to be translated, however I think it's a minor issue compared to either rewritten or additional database queries to fetch translations themselves. It's also a problem that's only going to appear on sites with really heavy translated content, whereas extra joins/queries would hit any site with translation enabled even if the quantity of translated content itself is quite light.
With check_markup() I've got one possible approach which might cut a lot of calls to it down - by stuffing the sanitized data in the node/field cache attached to the loaded fields/nodes instead of in the filter cache - opened an issue for this here #369011: Performance: do check_markup() in text_field_load().
Comment #9
catchHere's a slightly modified patch, with added tests for both single and multiple fields. Works fine. So the remaining question is whether drupal_render() is the right place to do this, or if we need to be slicing out unwanted translations earlier on (i.e. at a stage before check_markup() might get called at all). If we do want to move things earlier in the process, IMO we still need a generic place to do this, even if that's just a hook.
But minus that discussion, this is working OK now, so CNR.
PS. Who sneaked windows line breaks into Fields in Core? :(
Comment #10
catchMinus the field patch.
Comment #11
moshe weitzman CreditAttribution: moshe weitzman commentedIf we wanted to keep drupal_render() ignorant about translations, we could add a #pre_render callback during array building and that callback tosses out all the stuff we don't intend to render. Perhaps not a significant difference either way.
Comment #12
catchHi Moshe, spoke with sun and chx, and they said the same thing, so I'm working on that as we speak.
Comment #13
catchFor now I'm going to merge this into #367595: Translatable fields since the issues are too entangled to track separately.
Comment #14
sunI agree. This issue was good for initial distinction and brainstorming, but neither of both issues can go in without the other. Thus, marking as duplicate.