- πΊπΈUnited States smustgrave
From the comments it seems like this isn't ready for review as the approach is still being decided. Let me know if I'm wrong.
- π©πͺGermany hchonov πͺπΊπ©πͺπ§π¬
I've just added a related issue - https://www.drupal.org/project/drupal/issues/3353243 π Unpublished entity reference translations use a fallback while unpublished translations of the main entity do not Needs work and when making a decision both issues have to be considered.
- π§πͺBelgium kristiaanvandeneynde Antwerp, Belgium
We have a site where we don't want language fallback to happen. We made this work by relying on the behavior discussed here. By simply making sure that we have a translation for all languages, even if empty, we can choose which languages the content is available in by setting the unwanted translations to unpublished. This correctly leads to an access denied in our eyes.
I'm not denying the IS makes a valid point about inconsistency, but I am also agreeing with @plach that we can't simply change this behavior. It would kill our site's access logic and probably a lot more site's expected behavior too.
- last update
9 months ago 30,684 pass, 2 fail - last update
9 months ago Composer error. Unable to continue. - π¨πSwitzerland Berdir Switzerland
π Many calls to ContextRepository::getAvailableContexts() due to entity upcasting Needs review is currently implementing basically π Deprecate the "entity_upcast" operation specified in EntityConverter Active , although for now more as a proof of concept to see if that works.
Not sure what to reply to #33. Relying on this behaviour is IMHO unreliable, there are many ways to view an entity, like reference fields, views, various API integrations which will all not use the entity_upcast operation. See also my explanation over there. *Maybe* that doesn't apply to your specific site and you never reference an entity that's still being translated from another entity that already is and have no other entry points to view those entities, but it doesn't seem like something that should be relied on on.
If that's the behavior that you want then what about instead implementing access logic that denies view access if the entity language doesn't match the current language, so you essentially never allow access to view an entity "in the wrong language" (if the user isn't allowed to edit, to allow preview). Then you don't need to maintain fake-translations.
In our case, we handle this by displaying a message on top of the content that it's not available in the current language.
I wish entity_upcast would never have existed, I'm pretty certain this was just a misunderstanding of what that operation is meant to be used for, it's undocumented, but I also acknowledge that people now rely on it now that it exists. I don't know what to do about that. A configurable BC layer for this seems quite a bit of complexity.
- π§πͺBelgium kristiaanvandeneynde Antwerp, Belgium
Relying on this behaviour is IMHO unreliable ...
We got to that point where we checked how Drupal works, saw that under certain conditions access would be denied and found that said conditions matched our client's requirements perfectly. At that point we went with it.
Whether this is advisable for all projects is definitely up for discussion, but Drupal supported it without any mention of it being a bad idea or plans for removal of said functionality in the future. If we were to change this outside of a major version, our project and potentially others would definitely suffer.
Which is why I still side with #8 here. We are fortunate enough to be part of the 45 followers here, but breaking BC here will definitely upset more people than those following this issue.
In our case, we handle this by displaying a message on top of the content that it's not available in the current language.
Our client has specific needs about who can translate what entity in certain languages. By combining the behavior exhibited here with Group, we managed to deliver said functionality perfectly. there's bound to be other people who came up with similar solutions.
I wish entity_upcast would never have existed
+1, but I don't have a time machine :)
- π§πͺBelgium kristiaanvandeneynde Antwerp, Belgium
Ran into another issue where we need to be able to deny access to missing translations (which we're currently using aforementioned workaround of unpublished translations for). Documented this on the unofficial parent issue: #2951294-63: Sort out and fix language fallback inconsistencies β
Should we go ahead and make that one the parent issue of all the other related issues, including this one?