Project

General

Profile

Actions

Bug #85987

closed

Menus doesn't respect language settings and show non translated pages

Added by Richard Haeser about 6 years ago. Updated 11 months ago.

Status:
Closed
Priority:
Should have
Assignee:
Category:
Localization
Target version:
Start date:
2018-08-27
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
8
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

Scenario:
- You have a 1-on-1 translated website
- TypoScript settings: config.sys_language_mode = strict and config.sys_language_overlay = hideNonTranslated
- Page in default language is enabled
- No translation

Output:
If you use a menu (HMENU or menu element doesn't matter) in the secondary language, the page from the default language is shown. So it is falling back on the default language.

Expectation:
Because you've set the mode to strict with no fallback, you expect this page to not show up in the menu.


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #88344: HMENU directory incompatible with free modeClosed2019-05-13

Actions
Actions #1

Updated by Richard Haeser about 6 years ago

This is the behaviour in CMS7 and 8

Actions #2

Updated by Riccardo De Contardi almost 6 years ago

@Richard Haeser I got this same issue on TYPO3 9.5.4

In site configuration I set for the second language

[fallbackType] = strict

and on TS Setup

config.sys_language_mode = strict 
config.sys_language_overlay = hideNonTranslated

So far, I've seen that if you edit the page properties:

Tab language > Localization > set Hide page if no translation for current language exists = YES

It works. I've not tested it with 8.5

Actions #3

Updated by Riccardo De Contardi over 5 years ago

@Richard Haeser can you perform a test with 9.5.5 ?

I tried the following short test (with 9.5.5)

1) TYPO3 with two languages ITA, ENG (ID=1)
2) In site configuration I set for the second language

[fallbackType] = strict

3) TS Setup:

page = PAGE
page.20 = HMENU
page.20.wrap=<ul>|</ul>
page.20{
  1 = TMENU
  1.NO.wrapItemAndSub = <li>|</li> 
}

page.100 =< styles.content.get

As you can see, I omitted

config.sys_language_mode = strict 
config.sys_language_overlay = hideNonTranslated

4) I set up a pagetree like this one:

Home
  |
  +---test b
  |
  +---test


5) Only the "home" page and the "test" page have been translated in ENG, so:
Italian English
Home Home in Eng
test b
test test in Eng

Results when viewing the home page:

  • in ITA, the menu shows both "test b" and "test"
  • in ENG, the menu shows only "test in Eng"
Actions #4

Updated by Riccardo De Contardi over 5 years ago

  • Status changed from New to Needs Feedback
Actions #5

Updated by Richard Haeser over 5 years ago

I can confirm that this is working correctly with the current 9.5.8 release now. Will check v8

Actions #6

Updated by Riccardo De Contardi over 5 years ago

After a short test, it seems that it is still present on 8.7.26: a page that is present in default language but not translated is present in both menus, default language and translated.

Unless you check "Hide page if no translation for current language exists"...

Actions #7

Updated by Riccardo De Contardi over 5 years ago

  • Status changed from Needs Feedback to Closed

I close this issue in agreement with the reporter;

If you think that this is the wrong decision or experience the issue again on recent TYPO3 versions, pleae reopen me or ping me. Thank you.

Actions #8

Updated by Gion Koch about 5 years ago

This issue still persists for 9.5.9.

I have two languages DE/FR.
In the FR menu are fallback DE pages listed, which are not translated to FR.

The fallbackType is set to strict for FR in my site configuration.

Actions #9

Updated by Simon Gilli about 5 years ago

  • Status changed from Closed to New
Actions #10

Updated by Susanne Moog almost 5 years ago

  • Sprint Focus set to On Location Sprint
Actions #11

Updated by Benni Mack almost 5 years ago

  • Status changed from New to Needs Feedback

Hi Gion,

can you please try out 9.5.13? Thanks a lot!

Benni.

Actions #12

Updated by Benni Mack almost 5 years ago

  • Related to Bug #88344: HMENU directory incompatible with free mode added
Actions #13

Updated by Gion Koch almost 5 years ago

Hi Benni

Updated to 9.5.13 but it is not fixed. Did an additional test in a new Setup with the same result.

Greetings
Gion

Actions #14

Updated by Riccardo De Contardi almost 5 years ago

  • Status changed from Needs Feedback to New
Actions #15

Updated by Susanne Moog over 4 years ago

  • Status changed from New to Needs Feedback

Hey,

can you please check the following two things:

- In global settins: [FE][hidePagesIfNotTranslatedByDefault] - to be strict, this should be set to true in your installation
- On the page that does not have a translation: what are the l10n conf settings for that page?

The site settings (and strict mode / content fallback etc.) are relevant for content, but not necessarily for the pages.

Actions #16

Updated by Gion Koch over 4 years ago

Hi

Apparently, the setting [FE][hidePagesIfNotTranslatedByDefault] does the trick. Thanks!
IMHO it should be moved to the Site Configuration as it is really misleading to configure such elementary configurations in two places.

I suggest to move this setting to the Site Configuration.

Greetings
Gion

Actions #17

Updated by Benni Mack over 4 years ago

  • Status changed from Needs Feedback to Accepted
  • Assignee set to Benni Mack
  • Target version set to 10 LTS
Actions #18

Updated by Riccardo De Contardi over 4 years ago

  • Category set to Localization
Actions #19

Updated by Benni Mack over 4 years ago

  • Target version changed from 10 LTS to next-patchlevel
Actions #20

Updated by Jonas Eberle over 4 years ago

  • Related to Bug #91185: HMENU does not link to showAccessRestrictedPages for non-default language added
Actions #21

Updated by Jonas Eberle over 4 years ago

I just tested this in 9.5.15 and 10.4.1-dev.

It works now as expected.

The setting [FE][hidePagesIfNotTranslatedByDefault] does not change the outcome (which is how it should be in my opinion).

Close it or leave it open for 8 ELTS?

Actions #22

Updated by Jonas Eberle over 4 years ago

  • Related to deleted (Bug #91185: HMENU does not link to showAccessRestrictedPages for non-default language)
Actions #23

Updated by Hagen Gebauer about 4 years ago

I am having problems with multi-level page menus in TYPO3 version 10.4.9

  1. My Site Configuration: English as default, and German as secondary language
  2. I am using the fluid_styled_contents templates MenuSubpages.html and MenuSitemapPages.html – no site-specific Typoscript HMENU
  3. MenuSubpages.html recursively calls the exact same section for each level, whereas MenuSitemapPages.html calls one for the first level and then recursively a section submenu for all following levels.

fallbackType: strict – shows all pages in original language if no translation exists
fallbackType: free – respects translations in first level of menu (and shows only translated pages) – but shows all pages in sub levels: also if no translation exists

config.sys_language_mode = strict
config.sys_language_overlay = hideNonTranslated
do not change a thing

['FE']['hidePagesIfNotTranslatedByDefault'] => 1
in LocalConfiguration.php is doing the job – but in the wrong place in my opinion. The fallbackType in the Site Configuration should work. And since fallbackType: free works in the first menu level but not in lower levels, this does seem to be a bug.

Also I do not understand why fallbackType: free appears to be stricter than fallbackType: strict.

Actions #24

Updated by Oliver Hader about 2 years ago

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

Updated by Benni Mack over 1 year ago

  • Status changed from Accepted to Needs Feedback

Hey Hagen,

I guess this might be a different issue. Can you confirm if the problem still occurs with TYPO3 v10?

Actions #26

Updated by Christian Kuhn 11 months ago

  • Status changed from Needs Feedback to Closed

Hey. I hope it's ok to close here: The main issue has been resolved and the question by Hagen should go to a fresh issue in case we missed something that hasn't been resolved with v12 yet.

Actions

Also available in: Atom PDF