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 information provided through hook_translation_info() can be easily provided by implementing hook_entity_info(). Defaults can still be filled-in through hook_entity_info_alter(), hence hook_translation_info() becomes useless and should be dropped.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | et-entity_info-1114410-7.patch | 7.37 KB | plach |
| #4 | et-entity_info-1114410-4.patch | 4.76 KB | plach |
Comments
Comment #1
plachComment #2
pcambraTested commerce integration with no hook_translation_info but all translation properties inside hook_entity_info and hook_entity_info_alter and works just fine, however, shouldn't be advisable to issue the hook_entity_info_alter() of entity_translation after the rest of hook_entity_info_alter() that alter the translation properties?
Comment #3
plachGlad to hear this :)
However. Entity information is recursively merged giving priority to new data, so there should be no need to implement
hook_entity_info_alter()to provide translation information. Entity translation has a pretty low weight by default (11) so it is likely to alter entity information after most of the other modules. Anyway, since it's only providing defaults, a hook implementation running after ET will just find missing value filled with default ones and should have no problem to alter them.Comment #4
plachAnd here it is.
Comment #5
plachComment #6
plach#4: et-entity_info-1114410-4.patch queued for re-testing.
Comment #7
plachFixed PHP docs.
Comment #8
plachCommitted and pushed.
Comment #9
plachComment #10
plachComment #11
BerdirThis change broke my Translation Management Tools tests, it looks like this changed the comment body field from $language to und when creating a comment. Is that the expected behavior or is it actually broken?
Comment #12
plachWell, prior to this change comments always had a translation handler associated, even if the module was disabled. Now the comment entity info is provided only if the module is enabled. Not having a translation handler associated actually implies all fields being created as language neutral regardless of their translatability.
If the comment module is enabled in your tests, and I suppose it does :), then we have an unintended side effect which I'd be thankful if you could investigate on. However #1534674: Comment field language is completely broken in core, so perhaps it's just ET that is not working properly due to that.
Comment #13
BerdirI will look into it when I find the time, wrote it down in case you happened to know anything.
This is my test: http://api.worldempire.ch/api/tmgmt/sources%21entity%21ui%21tmgmt_entity...
As you can see, I'm enabling comment in the ET settings, changing the translatable flag to TRUE and then try to create a comment, which fails after this change (tracked it down with git bisect).
Comment #14
plachOk, I will look into this ASAP, thanks.