Bug #83874
closedLocalization manager wrongly chooses the same language to translate from as to translate to
0%
Description
This bug only occurs in 7.6.23 (Vanilla). It seems to have been fixed in 8.7. The easiest way to understand the bug is to watch the video translation-manager-bug.mov (glorious Quicktime). I provide what I think is the technical cause and 3 possible ways to solve it.
Background:
In the localization manager (4-step Dialog with "Translate record ...") in step 2 you can choose the origin language if there are no already translated elements on the page. Once there are translated elements on the page and you create new elements in the default language and go through the localization manager again, the origin language selection in step 2 is done automatically. This is apparently done be checking all already translated elements on the page and checking the field t3_origuid which contains the element they were created from (transalted from or copied from)(this "or" is exactly the problem). Normally the field t3_origuid for translations is the same as l18n_parent and so the dafault language is chosen automatically in step 2 and there is no problem.
But t3_origuid can also be a different element. With the steps below you can get translations that have other translation in the field t3_origuid. If you have this, step 2 will result in choosing the same language as origin as you want to translate to which must be prevented.
Reconstruction:
1. Create a content element on a transalated page in any language that is not the dafault language.
2. Copy that element and insert the copy to the same page. This copy will be called element B.
(3. The original content element can be deleted.)
4. Create a content element in the default language on the same page. This element will be called element A.
5. Make the content element in not the default language (B) to proper translation of the element in the default language (A) by setting the field "Trans. Orig" (l18n_parent) in element B to element A.
6. Create a new content element in the dafault langugage. This new element will be called C.
7. Now the translate button will appear in the not default language (because there is a non-translated element).
8. Click the translate button an go through the localization manager ("Localize record ...").
9. Notice that in step 2 the origin language is chosen automatically ("Choose the language from which you want to localize the content").
10. In step 3 in the "Record summary" you already see the problem: The record to be translated is not the new content element C as it should be but element B which is already in the language you want to translate to.
11. Finish the localization manager and new element will be created. This is the "translation" of element B which does not make sense because B already was in the langugage you wanted to translate to.
12. The translate button will still be there and you can create as many copies from all content elements in not the dafault language as you want but you can never create a proper translation of C via the translation manager. Such pages are "messed up" and can require a lot work to fix.
Workarounds:
- The editorial workaround is to transalate the new element (C) directly in the element and not via the manager (which can be bad if there is not only 1 new element but many). (You can also delete all translations and translate again which can be even more work.)
- The admin workaround is the to set the field t3_origuid to the value of l18n_parent for all element with sys_language_uid not 0. This solves the problem on all pages but tt is not clear it this has side effects.
Solutions:
1. When translating to language X the automatical origin language selection in step 2 should never result in choosing lanugauge X itself as the origin. If the field t3_origuid is a record in langugae X itself, then the selection should be done be the user and not automatically. Better: If the language of the record in t3_origuid is not the default language then the origin langugage selection (step 2) should be done manually.
2. In the localization manager you can always choose the origin language manually in step 2. The automatical selection in step 2 is misguided because the field t3_origuid can be a record from the same language (as demonstrated above) and then you translation from a language to itself. If the manual selection is always there you can prevent that.
3. When the field l18n_parent is altered then the new value is also written in the field t3_origuid. As this might have other consequences I cannot forsee this should be thought through well.
I think number 1 is the way to go. Also one could check why this is no longer a problem in 8.7 and apply that change if possible.
Files
Updated by Riccardo De Contardi almost 7 years ago
I think I can confirm that it has been solved for 8.7.10; I performed the following test:
Prerequisites¶
- TYPO3 8.7.10 with two languages: Italian (ID=0) and English (ID=1)
- Create a page and translate it into English
Test procedure:¶
1) Create a content element in English called "Element B Original" (ID=97)
2) Copy it and paste it into the same page (Element B (ID=98))
3) delete the element created at point 1)
4) Create in default language (Italian) "Element A" (ID=99)
5) Edit "Element B" (ID=98) > Set "Trans. Orig": "Element A"
6) Create in default language (Italian) a new element "Element C" (ID=100)
7) The "Translate" button becomes available > start the translation
7.1) Only "Translate" mode is available
7.2) The Record Summary step contains only:
(99) Element A
(100) Element C
Results¶
When the translation procedure is finished, only "[Translate to English] Element C" Has been added
Do you think that a different test should be performed?
Updated by Beat Haenger almost 7 years ago
As I said: This solved for 8.7 but not for 7.6, I agree with you. In 8.7 it is never the case that the manager wants to translate from langugae X TO language X itself.
As it is a mayor inconvenience for editors to repair pages with such elements the fix should be applied from 8.7 if possible. Otherwise a different fix for 7.6 should be found.
Updated by Beat Haenger almost 7 years ago
Another way to redproduce the same issue:
1. Create a content element on a different page and translate it.
2. Copy this created content element to a new page. It will be copied with its translation.
3. Create a new element on the page you just copied to in the dafault language.
4. Translate the new element via the localization manager.
5. In step 2 the language will be automatically chosen but you will translate from the language itself.
The problem is the same: Regarding t3_origuid to automatically chose the origin language in step 2 and accepting the language you want to translate to as a valid result is wrong.
Updated by Beat Haenger almost 7 years ago
- Category deleted (
Language Manager (backend))
Updated by Tymoteusz Motylewski over 6 years ago
- Related to Bug #79443: Translation Wizard translates already translated content elements added
Updated by Tymoteusz Motylewski over 6 years ago
- Related to Bug #78599: Copy localized content element leads to wrong reference, translation fails added
Updated by Tymoteusz Motylewski over 6 years ago
- Status changed from New to Resolved
Hi Beat,
I have a very good news for you.
The issue has been fixed in v7.6 too!
Please see https://review.typo3.org/#/c/57628/
I'm closing this issue as resolved. If you disagree with the status, please let me know.
A side note, you can check if your database is not messed up (e.g. whether l18_parent field or t3_origuid field is correct) with this extension https://github.com/macopedia/mess_detector
Updated by Beat Haenger over 6 years ago
I can confirm that this is fixed in 7.6.32-dev