Bug #81870

Dropdown _langSelector not aware of language mode copy/translate

Added by R3 H6 over 4 years ago. Updated 7 months ago.

Status:
New
Priority:
Must have
Assignee:
-
Category:
Backend User Interface
Target version:
-
Start date:
2017-07-14
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
7
PHP Version:
Tags:
Complexity:
hard
Is Regression:
Sprint Focus:
On Location Sprint

Description

If an editor choosed copy mode for translating and then adds an new content element and translate it directly from the edit form, he ends up with inconsistent content.

Steps to reproduce:
  1. Create a page
  2. Translate the page
  3. Create a content element in the default language
  4. Translate the content using copy mode (page module)
  5. Create a second content element
  6. Choose [NEW] language from the dropdown in the edit form
  7. Save content and return to page module view
  8. Now use the warning for inconsistent content

Applies to 7, 8 and 9

Solutions:
- Check current mode before translating on server side *
- Add TSconfig to hide/remove this dropdown (and show only the record language)

  • doesn't solve the issue that the user can't choose the mode when translating the first content element over the dropdown
#1

Updated by Presedo Roberto about 4 years ago

  • Priority changed from Should have to Must have
  • Complexity set to hard

Using TYPO3 8.7.8 here. I'm facing the same issue.

I tried to provide a patch, looking at the code that generates of this drop-down menu, but it seems to me that this is not a problem that can be solved easily.

A content element is not necessarily displayed on the page that stores it. It may also be displayed in several pages (via Typoscript for example) and each page can have a different translation mode.

This may sound silly, but the best solution so far is to hide that drop-down menu, or as in Page mode, ask the user if he wants to make a copy or a translation ...

#2

Updated by Susanne Moog almost 2 years ago

  • Sprint Focus set to On Location Sprint
#3

Updated by Philipp Seiler 7 months ago

This is still present in the latest v10 version. Can lead to very inconsistent or even broken page contents, depending on how the user translates an element. The fallbackType setting in the page configuration is pretty useless, until this is fixed.

Also available in: Atom PDF