TYPO3 Core

Susanne Moog wrote:

What is the value of global setting [FE][hidePagesIfNotTranslatedByDefault] = false ?

Yes, it has the default value

$GLOBALS['TYPO3_CONF_VARS']['FE']['hidePagesIfNotTranslatedByDefault'] = false;

Let's calrify the steps to reproduce:

Website with 3 languages:

- deutsch (0)
- english (1)
- chinese (2)

Configure language "spanish" and use the following particular settings:

languages:
    -   title: Deutsch
        enabled: true
        base: /de/
        typo3Language: de
        locale: de_DE.utf-8
        iso-639-1: de
        navigationTitle: DE
        hreflang: de-AT
        direction: ''
        flag: at
        languageId: '0'
    -   title: English
        enabled: true
        base: /
        typo3Language: default
        locale: en_US.utf-8
        iso-639-1: en
        navigationTitle: EN
        hreflang: en-US
        direction: ''
        fallbackType: strict
        fallbacks: ''
        flag: en-us-gb
        languageId: '1'
    -   title: Chinese
        enabled: true
        base: /zh/
        typo3Language: zh
        locale: zh_CN.utf-8
        iso-639-1: zh
        navigationTitle: ZH
        hreflang: zh-CN
        direction: ''
        fallbackType: strict
        fallbacks: '1'
        flag: cn
        languageId: '2'

Expected behaviour for chinese website: pages without translation should lead to 404.

Actual behaviour: page with content from fallback-language (languageId => 1) is shown.

Just the presence of the fallbacks key, makes TYPO3 perform a fallback. Although fallbackType is strict. It should not fallback anywhere. fallbackType => free has this glitch too as far as I remember. But stay with the reported use-case first - as that was proven to fail.

Don't know if this helps, but from my tests the option "fallbackType" just addresses content behaviour. I don't know if this is by design or a bug.

Tobias Gaertner wrote in #note-6:

Don't know if this helps, but from my tests the option "fallbackType" just addresses content behaviour. I don't know if this is by design or a bug.

It also affects how pages are fetched/overlayed.

Ingo Fabbri wrote in #note-7:

Tobias Gaertner wrote in #note-6:

Don't know if this helps, but from my tests the option "fallbackType" just addresses content behaviour. I don't know if this is by design or a bug.

It also affects how pages are fetched/overlayed.

OK. But it looks like the global setting (mentioned by Susi) still applies. If you change the pages.l10n_cfg field to not show the page if not translated, it would work?

Despite being described here: https://docs.typo3.org/m/typo3/guide-frontendlocalization/master/en-us/LocalizationOverview/Index.html#hiding-pages-if-no-translation-exist

I would not expect it to behave this way, as the language-settings in the site-configuration imply other behaviour.

Ingo Fabbri wrote in #note-9:

Benni Mack wrote in #note-8:

If you change the pages.l10n_cfg field to not show the page if not translated, it would work?

That works.

But I would not call it a solution.

Me neither. But it points out the flaw: If you have a global configuration, the site-specific should override this setting. Currently the global configuration is still taken into account.

Thanks for testing!