Project

General

Profile

Actions

Bug #83874

closed

Localization manager wrongly chooses the same language to translate from as to translate to

Added by Beat Haenger about 6 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2018-02-13
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
7
PHP Version:
7.0
Tags:
Complexity:
Is Regression:
Sprint Focus:

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

translation-manager-bug.mov (9.63 MB) translation-manager-bug.mov Beat Haenger, 2018-02-13 09:21

Related issues 2 (0 open2 closed)

Related to TYPO3 Core - Bug #79443: Translation Wizard translates already translated content elementsClosed2017-01-24

Actions
Related to TYPO3 Core - Bug #78599: Copy localized content element leads to wrong reference, translation failsClosedMarkus Mächler2016-11-07

Actions
Actions

Also available in: Atom PDF