- 🇳🇱Netherlands bbrala Netherlands
The issue was posponed on 🐛 Translated field denormalization creates duplicate values Needs review . HAL is no longer in core. So i think this should no longer be the case.
We added support for CRUD operations on content entities via REST without test coverage. Test coverage followed in #2737719: EntityResource: Provide comprehensive test coverage: for every entity type, every format, every method → . Translation support never materialized — this issue is the proof of that:
As such, we have no official, and no documented way to handle translations of entities. Do we return all translations at once or not? How do you modify existing translations? And so on.
@Crell and @dixon_ outlined how they thought it should work in #21 and #22: they tried to adhere to RESTful principles as closely as possible. But alas, per the timeline: no work was done.
So, that brings us to today, where Drupal 8 has been out for more than a year (since November 2015), Drupal 8.0, 8.1 and 8.2 have been released, and 8.3's beta is being tagged in a few days. Drupal 8.3 will ship without this too. That's 4 minor releases without support for this. Time to change that. 8.4 MUST have this fixed.
However, that also means that we can't just do anything. We cannot break backwards compatibility. Unfortunately, the #21/#22 proposal would break BC.
As I wrote in #46:
Just had a discussion about this with @damiankloip & @tedbow. (On January 30, but only got around to finish this now.)
There are two key observations that were made:
- Doing the multipart approach @dixon_ suggested in #22 may very well be approach (the ideal solution), but doing so is unquestionably a BC break.
- Ted showed in #32 that this already works today. In a way that is natural/intuitive/guessable to a Drupal developer: via a langcode path prefix. Changing that now would also effectively be a BC break, since it's extremely likely that multilingual sites are already suing this.
So doing the ideal isolation would result in a double BC break, hence that approach must be postponed to D9.
The pragmatic solution is therefore to just expand the test coverage in
EntityResourceTestBaseto test all HTTP methods against all entity types in multiple languages.
Why does the existing code already kinda work? Thanks to \Drupal\Core\ParamConverter\EntityConverter::convert(), which calls getTranslationFromContext().
In other words, the ideal solution is without question off the table. But is adding tests enough? There are several problems/questions to answer:
getTranslationFromContext() supports not just path-based language negotiation, but also domain etc. Do we want to support that?serialization-normalizer-based formats (currently only json): test that /de/node/1?_format=json returns the German translation, and also allows modifying that translationhal-normalizer-based formats (currently only hal_json): test that /node/1?_format=hal_json returns all translations, and /de/node/1?_format=hal_json returns only the German translationTBD
None.
TBD
None.
Needs work
11.0 🔥
The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.
(Drupal 8 Multilingual Initiative) is the tag used by the multilingual initiative to mark core issues (and some contributed module issues). For versions other than Drupal 8, use the i18n (Internationalization) tag on issues which involve or affect multilingual / multinational support. That is preferred over Translation.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
The issue was posponed on 🐛 Translated field denormalization creates duplicate values Needs review . HAL is no longer in core. So i think this should no longer be the case.