Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix error preventing to translate backoffice wordings when using a theme other than classic #14962
More information about this bug
Before this fix, back office translations would be pulled from the current FO theme as well, and any saved translation would also be attached to that theme, even if the wording didn't belong to the FO. This issue would render the translation of backoffice wordings impossible when using a theme other than "classic" (which has a custom behavior compared to any other theme since its wordings are included in the core).
The problem is related to how the theme translation section works when dealing with themes: it analyzes the theme's code looking for wordings, extracts them into a xliff catalogue in cache, then reads it to build the form. This extraction ONLY happens when working with theme translations. So what happened here was that when requested to load the backoffice translations, it would try to load the theme translations for some reason, and since its xliff catalogue hadn't been extracted, it raised an exception.
This PR reverts changes in #13088 that introduced the forced theme.
i've run some tests, just to clarify current state of translation system in 1.7
both, with changed domain to
i've moved this file to override folder, again, two domains. Result? new wording never found in translation system. This worked well in 1.6.
i'm going to Translations -> Theme -> My theme -> my language -> search "Search results", and what? no results, let's try with Classic theme!
In my opinion this is very important issue, we can't fully translate our custom theme.
But hey, let's try to insert translation directly to
Maybe this is similar issue to what you've worked in this PR? I think that
Another important issue which i have with new Translation system, is that we can't translate modules in theme context, so we can't have two themes, one module, and two translations for it, because module translations are stored in
I think the best place to discuss general issues with translations would be in this dedicated epic, or better, within the issues tracked there. Most of the issues you are talking about are there.
Regarding the first scenario, that's because backoffice translations are extracted from the core at build time (before we release a minor version), then put in XLIFF files which are bundled with the release or downloaded as language packs. The BO translation interface is based solely on these files when it comes to back office or front office translations, currently there's no way to make it pull new strings from the code. This is tracked by this issue: #13870
The second scenario happens in part because the theme translation system is different for classic and for other themes. The classic theme pulls its wordings directly form the XLIFF catalogue, while other themes must be analyzed to find new wordings. We need to make some tricky decisions regarding the expected behavior there (eg. should all wordings be displayed in the BO interface or just those that don't exist in the front office wordings? If we display them all, then what's the role of front office wordings?).
There are many issues with translations, and I'm meaning to untangle the bigger part of that mess in 1.7.7. For the time being, this PR only fixes the issue mentioned in the PR description, and only that.
Seems that the translation is not updated in the Symfony page
Except for this issue => OK => PR validated