Core

Hi Bernd,

I read your issue description twice, but I just do not understand your problem. Is this still valid for you? Could you please explain in a bit more detail what you try to achieve? What do you mean with "relink language ru (L=3) back to English (L=1)"? Which link should be created and when? In a content element or in a language selector?

This issue is still valid, even with TYPO3 4.1.10 and 4.2.6. The term "relink" refers to the fact that TYPO3 replaces untranslated parts by the corresponding part in another language. This is usually the default language (German for me), but for Russian it should print the English text.

As an example, see http://www.schulungsraum-muenchen.de. There, untranslated Turkish prints correctly the German text because of
config.sys_language_mode = content_fallback ; 1,0

But Russian had the TypoScript code
config.sys_language_mode = content_fallback ; 0,1
So it should print the text for L=1 (English for me), but it does not and prints the German text instead.

So config.sys_language_mode does not work according to the documentation.

sry, i don't see any russian or turkish translation there.

config.sys_language_mode = content_fallback ; 0,1

doesn't make sense, as it always fall back to 0 which is german in your case.

also using "" is wrong.

Exactly, the Russian and Turkish should be redirected as untranslated, so there is no translation.

I now tried
config.sys_language_mode = content_fallback ; 1
without quotes for the Russian, so it should redirect to English; but it still redirects to the German default. No idea.

The problem is that config.sys_language_mode only affects the page record. There is no content-fallback if the current page is translated, but not all records on it.

I have written a patch that implements this for TYPO3 4.2.6. Please try it out and let me know if that helps.

- michael

Attached is a patch that fixes the problem at least partly:

Preconditions:
- config.sys_language_overlay is 1
- config.sys_language_mode = content_fallback; <uid-list>

In such a case, a page that is translated will always select the default language unless the record is localized. However, if the record is localized for a language which is different than the selected one but matches the content-fallback list, this would currently have no effect.

The patch solves this by walking through the content-fallback list.

Added new patch which implements the same for t3lib_pageSelect::getPageOverlay(). This will affect menus etc.

I´ve tried out the first patch, it works great.

I tried the second patch. It's just great.

i've implement the second patch in TYPO3 - 4.3.3, works !
- even if an alternative Pagetranslation exist with no Content on it

Why is this not in the Core ? This is an must have for mulitlanguage-sites.

I use this with patch from 6009 - ( T3X_danp_languagefallback_patch-0_0_0-z-200708151515.t3x )

Hi guys,

the point is that nobody has sent this patch to Core List.

To get this fix in the next releases, one of you has to post it to the TYPO3-Core-list.
Check out http://typo3.org/teams/core/core-mailinglist-rules

Send to core list...

upload new patch for TYPO3 4.4.0

patch is also send to core list

The 8986_v3 Patch has a drawback:

The option hide page if no translation exists is ignored, if the language in question does not fall back to the default language directly. In this (not so rare) case the page will be show, no matter if a translation exists an the tranlated page is set hidden or no translation has been set up (in which case content fallback will work).

So the patch has to be refined to respect the l18n_cfg field from the pages table.

Any ideas, how?

I do not think this will work correctly because tslib_fe calls the patched function with different language ids from the "content_fallback":

$fallBackOrder = t3lib_div::intExplode(',', $sys_language_content);
foreach($fallBackOrder as $orderValue)    {
    if (!strcmp($orderValue,'0') || count($this->sys_page->getPageOverlay($this->id, $orderValue)))    {
        $this->sys_language_content = $orderValue;    // Setting content uid (but leaving the sys_language_uid)
        break;
    }
}

Instead of returning the result for that language, your patched version return the result for some other language. TSFE will assign a wrong language id (not the one you found but the one it supplied to the patched function).

What you should do to ensure that languages work:
- content_fallback is set correctly, no changes here
- set config.sys_language_mode to hideIfNotTranslated (or whatever it is, see in TSRef) or to 0 (what best suits your needs)
- [!!!] make sure that you do NOT have an "alternative language record" for the language where you do not have any content. An existing alternative page language makes the page translated and it shows you the translated page content, which is empty in your case. Content fallback happens only and only if you have no alt page language (=page is not translated). This is how it should work. Even TSRef says so: "The system will always operate with the selected language even if the page is not translated with a page overlay record. This will keep menus etc. translated. However, the content on the page can still fall back to another language, defined by the value of this keyword"
- [!!!] make sure that hidePagesIfNotTranslatedByDefault=0 in the install tool. If it is 1, you will get a 404 error when you remove the alt page language record.

So there is no bug there. And the patch is wrong, sorry.

I wrote all of the above because we just had the same issue and solved it only by a proper combination of settings. In our case the Install tool setting was causing problems.

Patch set 2 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/14464

Patch set 3 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/14464

Patch set 4 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/14464

The current patch has been testet with current master and "normal" content rendering, patchset 3 also with TYPO3 4.5 and TemplaVoila.

Please look at the more general solution in #17354.

#17354 takes a much more generic approach. Please see my comment in that review (https://review.typo3.org/14464).
As such it tries to change more and would imho clearly be a [FEATURE] (as it is already mentioned in the review-request). Since feature-freeze for 6.0 is over it also can't even go into 6.0. And face the facts: We have broken content_fallback in the LTS-version (from 4.5 all through to 6.0).

So imho #17354 would be nice to have and is under discussion as a new "feature" (in what form it might be accepted). But this here for the moment is a bugfix (!).

#34670 (duplicate) shows some additional information

Patch set 5 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/14464

I have this problem too using typo3 6.0 and templavoila 1.8.0. Is there a working patch for typo3 6.0?

I´ve just patched my 6.0.2 installation and it works fine. I used the Patch-Set 5 which is currently under review.

Mike Gebhard wrote:

I´ve just patched my 6.0.2 installation and it works fine. I used the Patch-Set 5 which is currently under review.

for me works ok too

Patch set 6 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/14464

Patch set 7 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/14464