Bug #97763
open
Translation Button shown eventhough already translated
Added by Nikita Hovratov almost 2 years ago. Updated 20 days ago.
0%
Description
If content of a page is translated, but not the default language is chosen for the translation source, the localization button is still shown.
How to reproduce:
1. Create 2 additional languages
2. Have a page and add a content element in the default language
3. Translate it to the first language
4. Now, translate the third language, but choose the second language as translation source.
5. The translation button is still shown.
6. If you click on that button again it will skip the steps of the translation wizard and stay stuck in the last step showing just the spinner
Code hint:
It seems the new Page Module only considers the default language to unset the already translated records:
TYPO3\CMS\Backend\View\BackendLayout\ContentFetcher:179
if ((int)$contentElement['l10n_source'] > 0) {
unset($untranslatedRecordUids[(int)$contentElement['l10n_source']]);
}
The old PageLayoutView(L:1418) handled it differently:
foreach ($records as $record) {
$key = array_search($record['l10n_source'], $defaultLanguageUids);
if ($key !== false) {
unset($defaultLanguageUids[$key]);
}
}
Files
| translation-button.png (38.1 KB) translation-button.png | Nikita Hovratov, 2022-06-13 10:49 |
Updated by Gerrit Code Review almost 2 years ago
- Status changed from New to Under Review
Patch set 1 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/74919
Updated by Nikita Hovratov almost 2 years ago
- Has duplicate Bug #94397: Translation Button is shown in connected mode if l10n_source differs from l18n_parent added
Updated by Gerrit Code Review almost 2 years ago
Patch set 2 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/74919
Updated by Gerrit Code Review almost 2 years ago
Patch set 3 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/74919
Updated by Gerrit Code Review almost 2 years ago
Patch set 4 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/74919
Updated by Gerrit Code Review almost 2 years ago
Patch set 5 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/74919
Updated by Gerrit Code Review almost 2 years ago
Patch set 6 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/74919
Updated by Gerrit Code Review almost 2 years ago
Patch set 7 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/74919
Updated by Gerrit Hübbers over 1 year ago
- Related to Bug #98172: Translate button still appearing despite all content elements being connected, page being in Connected Mode added
Updated by Gerrit Hübbers over 1 year ago
With "patch set 7", the issue from "patch set 1" found by Oliver ( https://review.typo3.org/c/Packages/TYPO3.CMS/+/74919/comments/034c07a0_8351a07c ) still exists:
I did some testing and found that the button still reappears as soon as a new record is added to the default language, which is not yet translated to the language source of the second translation.
Additionally, I found that the same problem (button is shown while no record is available for translation) also exists for the case that we have another language, which copied the records from the first localization (so is in free mode).
Updated by Gerrit Hübbers over 1 year ago
- Has duplicate Bug #98172: Translate button still appearing despite all content elements being connected, page being in Connected Mode added
Updated by Gerrit Code Review over 1 year ago
Patch set 8 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/74919
Updated by Gerrit Code Review over 1 year ago
Patch set 9 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/74919
Updated by Gerrit Code Review over 1 year ago
Patch set 10 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/74919
Updated by Christoph Schwob over 1 year ago
Just want to add an idea to discuss:
afaik the backend user has no chance to see, from which language the elements has been translated. in den translate dialog this page will be skipped on every other translation round. And the left column is always the default language. Could we display this also?
Updated by Gerrit Code Review about 1 year ago
Patch set 11 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/74919
Updated by Eric Harrer 10 months ago
I can confirm this behavior for version 11 and 12. It doesn't matter if you translate into free or connected mode.
TYPO3 v11, connected mode:
https://www.youtube.com/watch?v=NupBfRon5cQ
TYPO3v11, free mode.
https://www.youtube.com/watch?v=Q7IeuGnv0OE
TYPO3 v12, connected mode:
https://www.youtube.com/watch?v=i7tWwocBFG8
TYPO3v12, free mode.
https://www.youtube.com/watch?v=w4anIZeSOP4
Updated by Eric Harrer 10 months ago
- Related to Epic #101557: Translation Handling Findings added
Updated by Eric Harrer 10 months ago
- Related to deleted (Epic #101557: Translation Handling Findings)
Updated by Eric Harrer 10 months ago
- Related to Story #101564: User Interface related translation issues added
Updated by Jo Hasenau 3 months ago
· Edited
- Assignee set to Jo Hasenau
- Priority changed from Should have to Must have
We recently picked up this issues again after discussing it in the Translation Handling Initiative. The problem seems to be easy, but actually it shows essential flaws we've got in the core regarding the different translation related fields and their actual purpose and the knowledge about those purposes in the developer community.
I will use a comment of the patches already provided - in this case related to Classes/View/BackendLayout/ContentFetcher - to describe the problem a bit more detailed:
// Remove a possible translation from the untranslated record uids list.
// If l10n_source is set, remove this value.
// Else fall back to l18n_parent, but only if the translation source is the default language.
Actually it is the other way around, since l18n_parent has to get the top priority. If there is a record in a language pointing to a translation parent in the default language, this default language record definitely has to be considered as translated to that language and definitely has to be in connected mode.
The value of l10n_source field simply depends on two different options:- Either you just translated the default language to the target language, then it points to the same parent element as the l18n_parent field would, but regardless of the translation mode. So in connected and free mode the value would be available and obviously point to the correct parent.
- Or within the translation wizard you fetched the translation content from another language, which had already been translated. In this case there is no way to determine if a record of the default language has been translated by just looking at l10n_source. So the free mode is not easy to fix.
With core versions before 13 there is the field t3_origuid though, which usually holds the parent of a copy action, which always precedes the data map process of fetching and filling in the actual content during a translation process. While this field could provide sufficient information, it often does not, especially when there were workspace actions involved. This is why the field has been removed during the development of version 13.
So the fix for connected mode is straight forward: Make sure the translation parent field gets the top priority over the translation source field throughout the core.
For the free mode we've got three options:- Either we provide a new field that gets the parent of a translation even in free mode but does not determine an actual connection.
- Or we will have to resolve possible connections between a default language record and a translation in a specific language recursively.
- Or we will have to provide a kind of translation index similar to the reference index that holds information about default language records and available translations. In this case we could even skip the translation parent field and make the table hold the whole set of information including connected or free mode.
IMHO we should go for options 1 or 2 for the time being but aim for option 3 in the long run.
Still we can come up with a quick fix for the connected mode, since this can be done independently from the free mode solution.
Updated by Jo Hasenau 3 months ago
For the connected mode adding a single line to content fetcher should be enough:
if ((int)$contentElement['l18n_parent'] > 0) {
$languageTranslationInfo['hasTranslations'] = true;
$languageTranslationInfo['mode'] = 'connected';
}
if ((int)$contentElement['l10n_source'] > 0) {
unset($untranslatedRecordUids[(int)$contentElement['l10n_source']]);
}
if ((int)$contentElement['l18n_parent'] > 0) {
$languageTranslationInfo['hasTranslations'] = true;
$languageTranslationInfo['mode'] = 'connected';
unset($untranslatedRecordUids[(int)$contentElement['l18n_parent']]);
}
if ((int)$contentElement['l10n_source'] > 0) {
unset($untranslatedRecordUids[(int)$contentElement['l10n_source']]);
}
Updated by Riccardo De Contardi 20 days ago
Still reproducible on 13.2.0-dev (latest main)