Project

General

Profile

Actions

Bug #48673

closed

Changed language overlay behaviour in TYPO3 6.*

Added by Rainer Becker almost 11 years ago. Updated about 7 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
Localization
Target version:
-
Start date:
2013-05-30
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
nightmare
Is Regression:
No
Sprint Focus:
Remote Sprint

Description

Create this records:

- 0A All languages
- 1A Default Language
  - 1B Default Language translated
- 2A Default Language (hidden)
  - 2B Default Language translated
- 3A Default Language
  - 3B Default Language translated (hidden)
- 4A Default Language
- 5B Default Language translated

Setting: sys_language_overlay = hideNonTranslated

In FE / default language / TYPO3 V6 these will be shown:
0A, 1A, 3A, 4A (which is correct in my opinion)

In FE / other language / TYPO3 V6 these will be shown:
0A, 1B (which is incorrect in my opinion; 2B and 5B are missing)

In FE / other language / TYPO3 V4.5 these will be shown:
0A, 1B, 5B (which is still incorrect in my opinion; 2B is missing)

Is this change intended? If yes: Where is this documented? This is a major change in one of the most crucial enterprise features of TYPO3...
Btw: If records are fetched via extbase in V6 all translated records (0A, 1B, 2B, 5B) show up.
In TYPO3 6.1 the behaviour is unchanged.


Files

TYPO3_6.0_LanguageModes.pdf (119 KB) TYPO3_6.0_LanguageModes.pdf Test results Rainer Becker, 2013-06-03 09:35
l10ntest.zip (1 MB) l10ntest.zip Language test suite Rainer Becker, 2013-06-04 11:43
test.jpg (107 KB) test.jpg comparison of all constellations (only as paperscan - sorry) Gernot Ploiner, 2014-02-24 21:01

Related issues 11 (1 open10 closed)

Related to TYPO3 Core - Bug #17354: fallback for menus. "content_fallback;1,0" has no affect for page records (e.g. menu)Closed2007-07-22

Actions
Related to TYPO3 Core - Bug #19114: sys_language_mode content_fallback with a defined fallback chain does not output expected fallback content Closed2008-07-16

Actions
Related to TYPO3 Core - Bug #52960: FE Language overlay differs from BEClosed2013-10-18

Actions
Related to TYPO3 Core - Bug #39798: Language and colpos changes on re-ordering of Content ElementsClosed2012-08-14

Actions
Related to TYPO3 Core - Feature #34823: Remove language "default" from Alternative Page Language RecordsClosed2012-03-14

Actions
Related to TYPO3 Core - Bug #60052: sys_language_mode=content_fallback only supports language uid 0 as fallbackClosed2014-07-02

Actions
Related to TYPO3 Core - Feature #33734: Domain - Language mappingClosed2012-02-07

Actions
Related to TYPO3 Core - Bug #63684: sys_language_uid and sys_language_content are always the sameRejected2014-12-08

Actions
Related to TYPO3 Core - Task #69966: Integrate localization and fallback resolving in PlainDataResolverNew2015-09-19

Actions
Related to TYPO3 Core - Bug #69999: Cannot create CE without default languageClosed2015-09-21

Actions
Precedes TYPO3 Core - Bug #56351: view page in another language than default language from Backend is incorrectClosed2014-02-26

Actions
Actions #1

Updated by Alexander Opitz almost 11 years ago

  • Status changed from New to Needs Feedback

Not showing 5B is correct behavior for "hideNonTranslated":

“ Hide default translation of the page” incompatible with content binding: When using the “Binding” method (ie. “config.sys_language_overlay = 1 / hideNonTranslated”) you must supply placeholder records in the default language if you use the “Localization setting” for pages “Hide default translation of the page”.

http://docs.typo3.org/typo3cms/FrontendLocalizationGuide/LocalizedContent/ContentBinding/Index.html
As sxw: http://typo3.org/documentation/document-library/guides/doc_l10nguide/1.1.0/sxw/?no_cache=1 as some Tables are broken in the HTML Version.

Not showing 2B is IMHO also correct, as the page is hidden.

Does this hint solve your problem?

Actions #2

Updated by Rainer Becker almost 11 years ago

My case is just about content elements, the page is visible in both languages - sorry, I didn’t mention that.

So 2B should show up - no matter that it’s orignal 2A is hidden.

Ok, the 5B case is documented then. In my opinion this is not very intuitive (my clients think so too). In large scale translated projects there are cases, where an english page consists of different content elements than the german one. Telling the editor to either link records which have different meanings in de/en is no good solution; why shouldn’t it be possible to create a record just in EN?

Actions #3

Updated by Alexander Opitz almost 11 years ago

Then maybe you need another translation mode.

Actions #4

Updated by Rainer Becker almost 11 years ago

I tried all combinations of sys_language_modes (not set, strict, ignore, content_fallback, content_fallback;1,0) against sys_language_overlay (not set,hideNonTranslated, 1).
No one leads to the desired result. I attached my test matrix results (green background means: this one should show up in my opinion).
Or which other language related setting did I miss?

Why does Extbase fetch data in another way than styles.content.get()? (It show all the records I want to see in strict/hideNonTranslated mode)

Actions #5

Updated by Markus Klein almost 11 years ago

Hi!

I agree that the translation stuff has some flaws. Especially the fallback mechanism is not doing so well.
I didn't inspect your report in detail yet, but I'll try to bring some attention to this crucial part of TYPO3.

Thanks for you tests. Could you also upload your test setup as t3d? This would help to compare your test setup against mine.

Actions #6

Updated by Rainer Becker almost 11 years ago

I created a little test suite. You can see and change the language settings (sys_language_uid, sys_language_mode, sys_language_overlay). I created icons to visualize the results. Results are splitted in contents fetched by TypoScript, contents fetched by Extbase (for this to work you need to install the attached ext) and all contents.
Please have a look at it and tell me, if this works for you.
Btw: the results are... interesting.

Actions #7

Updated by Alexander Opitz almost 11 years ago

  • Priority changed from Should have to Must have

Raise priority as I think this should be fixed for LTS.

Actions #8

Updated by Alexander Opitz almost 11 years ago

  • Status changed from Needs Feedback to New
Actions #9

Updated by Matthias Secker over 10 years ago

I totally agree that this is a must have for LTS.
In most multilingual websites I use

  • sys_language_mode = content_fallback
  • sys_language_overlay = hideNonTranslated

Since TYPO3 6 I'm not able to add some extra CEs to a tranlated page, but I think this is a necessary feature.
For now I deactive sys_language_overlay, but I face some side effects e.g. TS CONTENT objects will not be overlayed.

Furthermore I got problems with l10n_mode in TCA. Using the data from original language CE by using "exclude" or "mergeIfNotBlank" will not deliver the data in my extbase extension , so I have to fill out every CE field for every language, even if the content is the same. Tried this with and without sys_language_overlay. Can anybody confirm this behavior?

Would be great to see some improvements in LTS.

Actions #10

Updated by Markus Klein over 10 years ago

  • TYPO3 Version changed from 6.1 to 6.2
  • Is Regression set to No

I invested quite some time to investigate the status quo.

Together with others we came to the conclusion that is unfortunately by far not trivial to fix and even more the concept behind translation in TYPO3 CMS has to be re-thought.
There are ideas from Oliver Hader and there are working patches like [1], but neither can this patch be backported, nor does it really fit with improvements desirable for 6.2 and later.

The last decision was that Olly will implement his ideas into 6.2, but nobody can guarantee if this works out in the remaining time.

[1] https://review.typo3.org/9937

Actions #11

Updated by Gunther Schöbinger over 10 years ago

  • Target version set to next-patchlevel

In my option the working patch is no solution. The output in the frontend of TYPO3 is buggy and it does not show 1:1 the translations from the backend. This still confuse the editors:

1. sys_language_overlay = 0
  • the frontend displays content-elements with a separate language (pdf: only NL)
  • the frontend did not show content-elements with the label "all languages"
2. sys_language_overlay = 1 / hideNonTranslated
  • the frontend did not show displays content-elements with a separate language (pdf: only NL)
  • the frontend displays content-elements with the label "all languages"

Both possibilities("all languages" and separate contentelements) are available/visible in the backend, but only one of these could be visible at the frontend.

Actions #12

Updated by Gernot Ploiner about 10 years ago

Same Problem here. Tested with TYPO3 4.5.30 and 6.1.7! So the Problem exists much longer than 6.x!

I create Content as following:
- default language with translations (de+en)
- standalone default language (de)
- standalone translation (en)
- all languages (de+en)
The Backend-View looks like as expected.
In the Frontend it is not possible to get the same contellation.

I understand the backport problem. Whats about new fixed TypoScript Keywords (e.g.: sysLanguageMode / sysLanguageOverlay) and set the sys_language_mode and sys_language_overlay to deprecated?

With Templavoila the Problem doesn't exist. But at this time a lot of people switch from TV to other solutions and meet this problem. So it is very important to fix it as soon as possible.

My TypoScript:

config {
sys_language_uid = 0
locale_all = de_AT
language = de
htmlTag_langKey = de

#column1:
sys_language_mode = strict
#sys_language_mode = content_fallback
#sys_language_mode = ignore
#column2:
#sys_language_overlay = 1
#sys_language_overlay = hideNonTranslated
#sys_language_overlay = 0
}

[globalVar = GP:L = 1]
config {
sys_language_uid = 1
language = en
locale_all = en_GB
htmlTag_langKey = en
}
[end]

page = PAGE
page {
10 = CONTENT
10 {
table = tt_content
select {
pidInList = this
orderBy = sorting
#column3:
languageField=sys_language_uid
}
}
}

Actions #13

Updated by Gernot Ploiner about 10 years ago

Thank you TYPO3 6.2
select.includeRecordsWithoutDefaultTranslation = 1
Not tested yet, but i think this is what i need :-)

Actions #14

Updated by Stefan Neufeind almost 10 years ago

includeRecordsWithoutDefaultTranslation was added in #49106

Actions #15

Updated by Christian Ludwig over 9 years ago

Are there any news about this bug?
We are running a site with 6.2.4 still having problems with the translation.

Our setup:

# Default (German)
config {
    sys_language_uid = 0

    locale_all = de_DE.UTF-8
    language = de
    language_alt = de
    htmlTag_langKey = de-DE
}

# English /en/
[globalVar = GP:L = 2]
config {
    sys_language_uid = 2

    locale_all = en_GB.UTF-8
    language = en
    language_alt = en
    htmlTag_langKey = en-GB
}
[global]

# Chinese /cn/
[globalVar = GP:L = 3]
config {
    sys_language_uid = 3

    locale_all = zh_CN.UTF-8
    language = zh
    language_alt = zh
    htmlTag_langKey = zh-CN
}
[global]

We have translated all pages 1:1 (German:English) and only some Chinese pages are missing. Here the german content gets displayed (menus are shown in Chinese, TS-Content in German, see description at the end of my post).

No we need to change the fallback language to English (L=2) with these additional settings:

config.sys_language_mode = content_fallback; 2,0
config.sys_language_overlay = 1

Everything seems to work fine, but contents from a custom fluid extension with IRRE elements suddenly disappear from every page.

An other problem that existed before is that content (global footer) added by TypoScipt to the template (Fluid cObject ViewHelper) with styles.content.get is displayed in the fallback language instead of the exiting content. I tried select.includeRecordsWithoutDefaultTranslation = 1, without success.

lib.footer < styles.content.get
lib.footer {
    select.pidInList = 16
    select.where = colPos=0
    select.includeRecordsWithoutDefaultTranslation = 1
}
Actions #16

Updated by Markus Klein over 9 years ago

@Rainer
I'm just reading your PDF file again.

A few questions:
  • Which language had which UID?
  • What does a crossed-out language mean?
  • What language did you request for each testcase? L=?
Actions #17

Updated by Rainer Becker over 9 years ago

DE is sysLangUid 0 (default),
NL is sysLangUid 2

Green backgrounds mean "This record should show up", check means "it did show up".
Columns "DE" mean "page is called with L=0, "NL" means page is called with "L=2"
Crossed out means "record exists but is hidden"

Left column:
  • * = ContentRecord for language=ALL
  • DE+NL = ContentRecord is created for DE and translated to NL
  • DE (crossedout) + NL = ContentRecord is created for DE and translated to NL, DE is hidden
  • DE + NL (crossedout) = ContentRecord is created for DE and translated to NL, NL is hidden
  • DE = ContentRecord is created only for DE
  • NL = ContentRecord is created only for NL
Actions #18

Updated by Andreas Allacher over 9 years ago

Bug #49176
does not yet work for me with 6.2.5

Not sure where it checks regarding l10n_mode exclude.
The problem here es specifically the addSysLanguageStatement and if I query against a l10n_mode exclude field. Especially, if I want to mix l10n_mode exclude fields with non excluded.
Details regarding this I posted in the ticket: #49176#note-13

Actions #19

Updated by Mathias Brodala over 9 years ago

Andreas Allacher wrote:

Bug #49176
does not yet work for me with 6.2.5

Confirmed. The same issue is hitting us currently in Extbase.

Not sure where it checks regarding l10n_mode exclude.

Nowhere. There is not a single occurrence of this in the Extbase persistence layer.

Actions #20

Updated by Mathias Brodala almost 9 years ago

Please delete the last comment as it's clearly spam.

Actions #21

Updated by Markus Klein over 8 years ago

  • Category set to Frontend
  • Status changed from New to Accepted
  • Assignee set to Markus Klein
  • Target version deleted (next-patchlevel)
  • Complexity set to nightmare
  • Sprint Focus set to Remote Sprint
Actions #22

Updated by Mehdi Guermazi over 8 years ago

Still have this bug in 7.3.1
I can't create a content in the 2nd language without showing it in the default language.

Actions #23

Updated by Robert Dickhaut over 8 years ago

Still have this bug in 6.2.
Need a resolve for this problem - this is very bad for multilanguage websites.
And many sites are multilang. ...

Actions #24

Updated by Tizian Schmidlin over 8 years ago

Same here in 6.2.15

Actions #25

Updated by Rafal Brzeski about 8 years ago

Same in 6.2.17. It's a nightmare to manage complex website with a multi language content, because of this issue :/

Actions #26

Updated by Markus Klein almost 8 years ago

  • Assignee deleted (Markus Klein)
Actions #27

Updated by Tymoteusz Motylewski over 7 years ago

  • Category changed from Frontend to Localization
Actions #28

Updated by Helmut Hummel over 7 years ago

Rainer Becker wrote:

Create this records:

This is a pretty decent test scenario, thanks!

I created tt_content records like described and tested in 4.5 and 6.2

The behavior in both versions is identical with identical configuration.

In FE / other language / TYPO3 V6 these will be shown:
0A, 1B (which is incorrect in my opinion; 2B and 5B are missing)

This is also my observation.

In FE / other language / TYPO3 V4.5 these will be shown:
0A, 1B, 5B (which is still incorrect in my opinion; 2B is missing)

This is not true. The behavior is exactly like in 6.2.x and only 0A, 1B records are shown!

Is this change intended? If yes: Where is this documented?

Nothing has changed, nothing needs to be documented.

Actions #29

Updated by Helmut Hummel over 7 years ago

  • Status changed from Accepted to Needs Feedback

Given we do not take Extbase into account and only look at pages and tt_content, I think this bug report (stating the behavior of language overlay changed) can be closed.

Actions #30

Updated by Riccardo De Contardi about 7 years ago

  • Status changed from Needs Feedback to Closed

Closed. See last comment + no activity since long time (90 days)

If you think that this is the wrong decision or experience the issue again then please reopen it or open a new issue with a reference to this one. Thank you!

Actions

Also available in: Atom PDF