Bug #88965

Siteconfigurations fallbackType "strict" shows free contents

Added by Tobias Gaertner about 1 month ago. Updated about 1 month ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
Localization
Target version:
-
Start date:
2019-08-16
Due date:
% Done:

0%

TYPO3 Version:
9
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

SiteConfiguration (language part)

languages:
  -
    title: Deutsch
    enabled: true
    languageId: '0'
    base: /
    typo3Language: de
    locale: de_DE.UTF-8
    iso-639-1: de
    navigationTitle: Deutsch
    hreflang: de-DE
    direction: ltr
    flag: de
  -
    title: English
    enabled: true
    languageId: '1'
    base: /en/
    typo3Language: default
    locale: en_GB.UTF-8
    iso-639-1: en
    navigationTitle: English
    hreflang: en-GB
    direction: ltr
    fallbackType: strict
    fallbacks: '0'
    flag: gb

Reproduce: see screenshots

Behaviour: content in connected mode is handled correct, but free contents are shown up always.

Feature-description says: "1. “strict” – Fetch the records in the default language, then overlay them with the target language. If a record is not translated into the target language, then it is not shown at all." (https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/9.5.x/Feature-86762-EnhancedFallbackModesForTranslatedContent.html)

Docs say: "...and include records without default translation. "
So this is what we get here . but not what I expact from a "strict" mode - if this i by design there is actually no really strict mode available. The "fallback" mode acts like expected and does not show the free record.

t3-trans-bug-fe.jpg View (16.3 KB) Tobias Gaertner, 2019-08-16 09:17

t3-trans-bug-be.jpg View (59.1 KB) Tobias Gaertner, 2019-08-16 09:17

History

#1 Updated by Tobias Gaertner about 1 month ago

Actually this behaviour for type "strict" is needed, but then it should be called "mixed" and we need an other mode "strict" which only shows properly connected translation record.

UPDATE: thinking about this... currently free and strict acting the same, so we don't need an additional type, the behaviour is already there with type free.

Also available in: Atom PDF