Project

General

Profile

Actions

Bug #88965

open

Siteconfigurations fallbackType "strict" shows free contents

Added by Anonymous over 4 years ago. Updated about 1 year ago.

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

0%

Estimated time:
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.


Files

t3-trans-bug-fe.jpg (16.3 KB) t3-trans-bug-fe.jpg Anonymous, 2019-08-16 09:17
t3-trans-bug-be.jpg (59.1 KB) t3-trans-bug-be.jpg Anonymous, 2019-08-16 09:17

Related issues 3 (3 open0 closed)

Related to TYPO3 Core - Bug #90261: fallbackType: fallback renders default language content although there is free mode content availableUnder Review2020-01-30

Actions
Related to TYPO3 Core - Story #101564: User Interface related translation issuesNew2023-08-03

Actions
Related to TYPO3 Core - Story #101561: DataHandler related translation issuesNew2023-08-03

Actions
Actions #1

Updated by Anonymous over 4 years 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.

Actions #2

Updated by Susanne Moog over 4 years ago

  • Sprint Focus set to On Location Sprint
Actions #3

Updated by Anonymous about 3 years ago

This is still present in 10.4 (testet 10.4.12)

Actions #4

Updated by Sybille Peters about 2 years ago

Is this still reproducible?

Can you clarify the description? I am having a hard time understanding what is the problem from the description. (I was trying to figure out if related to another issue).

Actions #5

Updated by Anonymous almost 2 years ago

  • Related to Bug #90261: fallbackType: fallback renders default language content although there is free mode content available added
Actions #6

Updated by Anonymous almost 2 years ago

Sybille Peters wrote in #note-4:

Is this still reproducible?

Can you clarify the description? I am having a hard time understanding what is the problem from the description. (I was trying to figure out if related to another issue).

It is still reproducible. Including 10.4.30.

For me the description is accurate. I do understand from scratch what the issue is about. Maybe some screenshots can help.

Actions #7

Updated by Oliver Hader over 1 year ago

  • Sprint Focus deleted (On Location Sprint)
Actions #8

Updated by Benni Mack about 1 year ago

  • Status changed from New to Needs Feedback

Tobias Gaertner wrote in #note-1:

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.

I think we just a better description:
  • Strict => do overlays (we start from 0,-1) and check for translated records, throw away the ones that are not translated. But also include the ones that editors created just for that language (Real-World Example: English is default, polish is the translation, but we also want to show news that are only created in polish (no record in language=0)
  • Free => We just query the ones that

It is a very subtle but important difference: That is the SQL query including the sort order!

I cannot imagine a scenario where we set to "we want strict mode, but we should never allow polish editors to create their own news in just for that language without l10n_parent"). Do you know one?

Actions #9

Updated by Anonymous about 1 year ago

Thanks for investigation.

Mh I actually never thought of "strict" in that way...

But couldn't the sorting become very strange in "strict" mode if editors mix up free and translated content?

In general this is not what I expected from a "strict" mode and in many cases it behaves exactly the same like "free" mode then (despite sometimes the ordering).

But ok, if in this case it indeed works like intended...

Actions #10

Updated by Benni Mack about 1 year ago

Tobias Gaertner wrote in #note-9:

Thanks for investigation.

Mh I actually never thought of "strict" in that way...

But couldn't the sorting become very strange in "strict" mode if editors mix up free and translated content?

Yes. that's why the Page Module says "mixed". I really dislike the page module information, as we somehow should transform the page module to reflect the state of the site configuration (which I consider is "what people would need out there"). I then think we need to rather work on the page module structure and the naming.

In an ideal world (maybe v14), I think we can drop the overlays logic completely and just query a specific language directly (don't know how fallback logic could be implemented then). Technically "overlays" is the opposite of "fallback". Overlays => start with language=0 and try to find translations, "fallback" = if content isn't there in a specific language, fallback to other languages (which is really hard on a DB level), but overlays is really hard to grasp for newcomers.

Actions #11

Updated by Jo Hasenau 9 months ago

  • Related to Story #101564: User Interface related translation issues added
  • Related to Story #101561: DataHandler related translation issues added
Actions

Also available in: Atom PDF