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.
The TF UI got moved to D8 / contrib, however there's still a prominent translatable or not option when creating a field via the field UI. It seems to me like this should move into the contrib module now.
Comment | File | Size | Author |
---|---|---|---|
#4 | field_ui-654934-4.patch | 1.38 KB | plach |
Comments
Comment #1
plachThis would make sense on the UX side, but we must consider that one might start creating content before actually installing Entity Translation. In this case one would have no way to change a field's translatability as field properties cannot be changed after content has been created.
By letting that choice in core we allow people plan the translatability of a field. We must also consider that Entity Translation might not be the only module exploiting translatable fields.
Comment #2
yched CreditAttribution: yched commentedHm, I think you can change that property after the event now.
Comment #3
plachIn this case no objection on this.
Comment #4
plachRemoved field translatability selector.
Comment #5
yched CreditAttribution: yched commentedComment #6
yched CreditAttribution: yched commentedOops. This raises a couple additional questions :
- field_ui_field_overview_form_submit() creates field with
'translatable' => TRUE
by default.Do we still want this ?
- the (node) body field is created with
'translatable' => TRUE
- node_configure_fields().Do we still want this ?
Comment #7
plachWe already discussed this in #563998: Field UI: no way to set the translatable property: IMO the answer is still YES, because translatability is not taken into account if no translation handler is actually enabled. If one enables a translation handler, he probably wishes to translate fields and making all fields translatable replicates our core content translation pattern: a field for each language.
Comment #8
yched CreditAttribution: yched commented"making all fields translatable replicates our core content translation pattern: a field for each language"
I don't get this last part, but the rest makes sense. Back to RTBC then.
Comment #9
webchickI definitely like removing this from the UI, since core doesn't do anything with it, and it forces a confusing decision immediately into the face of anyone adding any field, regardless if they use i18n features or not, which most sites don't. So, committed to HEAD.
But I'm wondering if we could discuss a bit more (either here or in another issue) about the default value of this should be. Plach and I had a long talk in IRC earlier about this. The jist was that this flag is toggling the *translatability* of fields, not whether they have translations. And generally speaking, you will want most fields translatable, so the current default probably makes sense.
On the other hand, though, this won't actually take effect unless you use Entity Translation (or equivalent) in contrib. And it'd be possible there to toggle the fields to translatable during hook_install(), then put in a much more streamlined UI (for example a matrix of all of your fields with "select all" and stuff like) for controlling of toggling this property itself. Clicking "configure" on 50+ fields to check them doesn't strike me as my fun idea of a good time. :P
Comment #10
plachI meant that in core the only way to translate content is through the Translation module which creates a node for each translation, so fields are replicated for each translation. Exactly what happens if you don't use non-translatable fields.
I need to think a bit more about webchick's proposal: can we perform this change to default values after the alpha deadline?
Comment #11
plachWhile working on #657972: Make field fallback logic actually reusable I changed my mind about this. I think that defaulting to FALSE should give a perfomance improvement on unilingual sites. See http://api.drupal.org/api/function/field_is_translatable/7, if a field is untranslatable we avoid a call to http://api.drupal.org/api/function/field_has_translation_handler/7 (for each field, for each
field_attach_X()
call).catch?
Comment #12
catchWe have a static cache in field_is_translatable(), so even when inserting 1000 nodes in a migration, field_is_translatable() only gets called 26 times. It'd be quite a small optimization but shouldn't matter too much either way.
The main issue I'm seeing in migrations (which is what I'm mainly profiling at the moment), is that functions like field_is_translatable() are called per entity, per field, per field_invoke op - on this site that's 89,000 times to insert 1,000 nodes (29 fields * ($default + $insert + $presave))- ish. That's an issue with _field_invoke() overall (which can take up to 8% of a migration run), not with the translatable functionality as such though.
Comment #13
plach@catch:
Do you mean field_available_languages()?
Edit:
Well, if this is not an issue strictly tied to translation, wouldn't this be almost the same scenario as in CCK? I mean, _field_invoke() already existed.
Comment #14
plachA side thought: what about displaying the "translatable" checkbox only if Locale (or any other module exploiting Field's multilingual capability) is enabled? We have an API function for this: http://api.drupal.org/api/function/field_has_translation_handler/7.
Comment #15
yched CreditAttribution: yched commentedre catch #12 : I had #760238: Optimize _field_invoke() sitting on my hard disk. Does not touch repeated calls to field_is_translatable(), though.
Comment #16
retester2010 CreditAttribution: retester2010 commented#4: field_ui-654934-4.patch queued for re-testing.
Comment #18
Jax CreditAttribution: Jax commentedThis patch was committed in http://drupalcode.org/viewvc/drupal/drupal/modules/field_ui/field_ui.adm...
Comment #19
plachThe issue has been set in 'needs review' status by webchick while committing.
Original issue: #563998: Field UI: no way to set the translatable property.
Comment #20
plachTalked with webchick: it's too late for changing our minds on this, hence marking fixed.