TYPO3 Core

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?

Then maybe you need another translation mode.

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.

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.

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

includeRecordsWithoutDefaultTranslation was added in #49106

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
}

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

• Which language had which UID?
• What does a crossed-out language mean?
• What language did you request for each testcase? L=?

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"

• * = 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

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

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.

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

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.

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. ...

Same here in 6.2.15

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

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.