Quantcast
Channel: Issues for Drupal core
Viewing all articles
Browse latest Browse all 292377

Do we still need to support hook_field_prepare_translation() ?

$
0
0

Background:
#1969728: Implement Field API "field types" as TypedData Plugins is moving the "field type" API from "pseudo hooks" (hook_field_[OP]()...) to methods on EntityNG FieldItem classes.

Among those is hook_field_prepare_translation() - not done yet in the patch above.
This strictly relates to the old "translation set"-based node translation model (translation = separate node).

The hook was part of the process of pre-filling form values on the "create new translation node" form, based on the source node values. Field API automatically took care of pre-filling the original values from the source node, the hook let field types do additionnal stuff on top of that:
- A typical use case was for node_reference to point to the *translation* of the target node rather than the target node itself.
D8's entity_reference currently doesn't bother with this though (I guess it doesn't bother supporting special cases for nodes and their old translation model)
- Another example is text field *unfilling* the source values if the user creating the translation node doesn't have permissions to use the input format those source values are in (see text_field_prepare_translation()). I'm not sure how this case is dealt with in the new translation model, but that's not through text_field_prepare_translation().

So the question is:
Should we bother porting hook_prepare_translation() to the new field type API right now ?
Or: do we want to make "prepareTranslation() : do extra massaging for the special case of nodes in their old translation model" part of the new API for field types ?


Viewing all articles
Browse latest Browse all 292377

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>