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.
When used as a field formatter (not as view) the module doesn't use the translated versions of alt/title tags for caption and title; it uses the default language instead.
Comment | File | Size | Author |
---|---|---|---|
#10 | juicebox-field_xml_not_language_aware-2656092-10.patch | 1004 bytes | rjacobs |
|
Comments
Comment #2
rjacobs CreditAttribution: rjacobs commentedYeah, I can replicate this. The issues appears to be related to the way language detection is working when the XML is generated (which is a separate Drupal request). The translation appears to be working fine for the markup that's printed as part of the embed code, but it's the XML that governs what the user actually sees in the final gallery, so there's definitely a bug here.
Core's language negotiation and detection appears to work fine within the XML request, but it is somehow not being applied to the entity and field (re)building logic that happens there. From a technical perspective this is fundamentally different from the way Drupal 7 behaved, so I'll need to investigate more.
Comment #3
rjacobs CreditAttribution: rjacobs commentedAlright, I see that few assumptions are made regarding language detection (by default) now. So we have to do that part ourselves for any freshly loaded entities instead of depending on core to do it automatically (as in D7). I think I have a way to do it programtically now within the XML controller -- see attached patch.
@steponeloops, can you try this out?
I still need to see if there is also anything that needs to be done for this within the view xml controller before committing any changes, so that will be forthcoming.
Comment #4
rjacobs CreditAttribution: rjacobs commentedAs best I can tell the views integration does not have this problem as language filters, and the language detection process, seem to be internal to the view itself.
If someone with true multilingual content can test out the patch that will definitely help.
Comment #5
steponeloops CreditAttribution: steponeloops commentedYes, the patch (#3) seems to work!
EDIT: some galleries work correctly and show the correct caption in both languages, but one gallery (on the same site) works only in the default language, 2nd language gives a "Juicebox Error: Config XML file not found."
Comment #6
rjacobs CreditAttribution: rjacobs commentedInteresting, thanks for checking that out. They key is figuring out what's unique about that error case. When this error comes up do you also see any specific messages in your site's error log? Also what form of language detection do you have configured (I'm assuming just the "URL" option that uses a prefix)?
If you are able to share a direct link to the gallery that demonstrates this (on a patched instance) that would also be great. That would allow me to see more details about how the main gallery page is requesting it's XML, etc.
Comment #7
rjacobs CreditAttribution: rjacobs commentedOk, regarding #5 I'm willing to bet that the gallery with the error is coming from a node that does not have a translation, and your were viewing it with the content language set to something other than the default. I can replicate this, along with a specific exception in the logs, under those conditions.
The multiilingual APIs in Drupal 8 have completely changed (for the better), but its definitely causing some complications for this specific XML generation case.
I think the patch from #3 adds the appropriate transnational handling process, but the current language detection piece still needs work. Also moving to major as this is making field-based galleries totally incompatible with multilingual sites.
Comment #8
rjacobs CreditAttribution: rjacobs commentedOk, I found a much, much cleaner way to do this. It seems that core does offer a method for this need, which internally resolves the current language, checks if the entity in question has a translation in that language (with a default language fallback), etc.... all in one call:
EntityRepositoryInterface::getTranslationFromContext()
The patch also addresses some cleanup of the way the XML loaders manage services as the getTranslationFromContext() call requires loading a new service (EntityRepository), and so that triggered some other related cleanup.
Comment #9
steponeloops CreditAttribution: steponeloops commentedOK, the patch #8 fixes the problem! (patched against 8.x-2.x-dev, 2016-Jan-23) - Thank you.
Comment #10
rjacobs CreditAttribution: rjacobs commentedGood stuff. The patch from #8 included some refactoring details that were a little tangent so I broke those off into a separate commit. So now the remaining code fix that directly addresses this bug is quite simple and elegant (new attached patch).
Comment #12
rjacobs CreditAttribution: rjacobs commentedCommitted. Thanks to steponeloops for assistance testing things out.