I'm using Typo3 10.4.28 with gridelements 10.4.3 (not w/DataProcessing)
To minimize redundancy in a Multilanguage-Site I set Content Elements (CE) without own Text-Content to language=all and translate only CEs with Text.
It feels very logical and useful to me, to set language=all on gridcontainers (where I'm not using its title or other own text-fields), to be able to set contained Plugins, Menu-Elements and Images to Language=all, even if it also includes a translated Text-CE
(and I have seen this done in a Typo3 with gridelements where I have only regular backend access and don't know exactly how they achieved that).
But when translating CEs within language=all gridelements, this is not rendered correctly in the frontend on the translated page.
Translated CEs are either rendered twice (fallbacktype: strict/fallback) or all language versions are rendered (fallbacktype: free).
According to gridelements maintainer #Jo Hasenau, putting translated elements into language=all containers is not supported directly with unmodified gridelements.
Thanks to his comments I found a setup which (while hacky) works more or less:
fallbacktype: free
[siteLanguage("languageId") == 1]
lib.gridelements.defaultGridSetup.columns.default.renderObj.20.stdWrap.if {
isInList.field = sys_language_uid
# -1 is language=all
value = -1,1
}
[GLOBAL]
# allows only content in the correct language or "all"
# repeat for each other languageId
I found a problem with this setup though: in free-mode, translated elements get ordered in frontend based on their own "sorting" instead of their original element's. This means, translated elements might switch places with Language=all elements, compared to the default language. Fixing this in (translated) content would be a big hassle on a large site.
So I tried to find a fix for fallbacktype: strict
(where "you get the original element with a translation overlay and after that the translation itself")
lib.gridelements.defaultGridSetup.columns.default.renderObj.20.stdWrap.if {
isFalse.field = l18n_parent
}
I hoped this would exclude only "the translation itself", but sadly it also excluded the "translation overlay". In fact both seem to be identical to typoscript at this point.
Update:
A pure TS-Solution for strict and fallback is found, and my above solution for free technically works as well (free is just not suitable), so this case seems closed.
A small word of warning for anyone who wants to use this structure, though:
sys_language_uid -1, aka Language All might be removed from Typo3 in upcoming versions:
https://decisions.typo3.org/t/rethinking-translation-handling-based-on-a-session-of-t3cmd-2022/734/16
As discussed in the Gridelements issue tracker, you should go for strict or fallback mode, since free can not work by definition.
Still your approach with strict is wrong, since you don't have to include the target language records, but only default language records or those that got language all but after the translation overlay.
This overlay will add a virtual field named _LOCALIZED_UID
Reason: Both strict and fallback use overlays to render their content, and since there always is a record of the default language available, this will be the one to fetch, while the content will then be overlaid.
So the solution should be:
[siteLanguage("languageId") > 0]
lib.gridelements.defaultGridSetup.columns.default.renderObj.20.stdWrap.if {
isFalse.field = _LOCALIZED_UID
value = -1
isGreaterThan.field = sys_language_uid
negate = 1
}
[GLOBAL]
Without additional conditions, since it will be the same for any target language.
To explain the Syntax you need to know, that the TypoScript if-conditions only know AND but not OR, so if you want the result of an OR condition you need to negate the opposite AND condition, which is what the snippet does.
It checks for a non existing _LOCALIZED_UID and the language of the record being greater than -1 - and if this is both true, it will negate the result. If any of the conditions is false, the negated result will be true.
Basically this is the same behaviour as with pages, which are kind of top level containers themselves.
If you want just one single element of that page to be translated, you need to create a translated page record before. So having a page with the "language => all" behaviour will only work together with a properly configured fallback, if there is no translated content on that page at all.
So you don't have to switch the frontend rendering TS template, but just follow the rule you already described.
I set Content Elements (CE) without own Text-Content to language=all
and translate only CEs with Text
Since a Gridelements container is a CE and the child elements are basically content of that CE, just as with pages you always have to translate a container element as soon as it contains at least one translated element.
So language "all" should only be applied to containers that don't contain any translated child element at all.
Related
I am adding a field to the pages table (is a relation to a file) and would like the value of the field in the pages record to be copied to the translated record by default.
Currently, the copied field is empty (default value), which is probably a good idea in most cases.
I am thinking of something that behaves like l10n_mode = prefixLangTitle without the prefix.
Depending on the TYPO3 version this should be possible with one of the following behaviours for the inline field:
https://docs.typo3.org/typo3cms/TCAReference/7.6/Reference/Columns/Inline/Index.html#behaviour
https://docs.typo3.org/typo3cms/TCAReference/8.7/ColumnsConfig/Type/Inline.html#localizechildrenatparentlocalization
https://docs.typo3.org/typo3cms/TCAReference/latest/ColumnsConfig/Type/Inline.html#allowlanguagesynchronization
Sine the localizeChildrenWithParentLocalization feature is broken with pages and pages_language_overlay though, I guess the only working versions would be CMS 8 or 9 with properly configured language synchronization.
https://forge.typo3.org/issues/78743
Use
['behaviour']['allowLanguageSynchronization'] => true
if the translated record will use the value from the default field by
default (will effectively be copied), but it should be possible to change
this later.
See pages.author as example.
When "Custom value" is selected, the value can be overridden.
Alternativively, use
l10n_mode = exclude
if the field should always have the value of the default language and you
should not be able to change it in the translated record.
Small problem with translated content in TYPO3 8.7.13:
Translation in connected mode. In default language there is one element hidden which should be visible in translation. In the backend it looks like it would be visible but in the frontend the element is missing. (The other way round there is no problem: when the element in default language is visible i can always hide it in the translation.)
My language configuration:
[sys_language_mode] = content_fallback
[sys_language_overlay] = hideNonTranslated
Translation in connected mode (we use L10N-Manager)
Is there a possiblity to make the translated element visible in the foreign language even when the element in the default language is hidden?
Thanks!
I'm not sure if my informations are up to date, but when I had similar case in older TYPO3 versions there were no way to achieve that. The workaround which I've used was to change type type (CType) of content element to "Empty", which was custom content element prepared especially for such cases. It is possible also to change the type to "Plain HTML" and just leave the bodytext empty.
Is there a way to 'reset' or db entries to delete or something else without deleting all content already translated... (and would that solve the issue?)
In the first go all translation went well, I chose a 'one tree' setup pressing translate rather then copy, but adding and modifying the content over time certain elements where not available for translation anymore ...
at one point the second step in translation asked for the origin language (if I recall well) and trying to resolve I chose another language than the default, now I do not have the choice anymore and the record summary proposes elements from german rather than from my default language (italian) which might be the problem since I can only introduce new content in the default language.
if I try to localize from the list view clicking the language flag, in the language selection field I get [INVALID VALUE("1")] and as only option (Default) [0] to select ...
I use TYPO3 V7.6.13, EXT:gridelements and EXT:t3sbootstrap (the nested CE's where the first to show trouble)
content of my database table sys_language: (my default lang is italian)
uid | pid | tstamp | hidden | title | flag |
1 0 ... 0 English gb
2 0 ... 0 German de
does anyone know good reference or a solution to this problem ?
That sounds like your sys_language records (in yoour root-page, id = 0) are disabled or missing.
Those records make languages available for translation.
The other factor for translation selection is the translation of the current page. You need to have the page translated to a language (given above) to be able to translate any record in that page. That also is neccessary for pages which contain only data.
first check (as suggested by bernd) if your language setup is valid:
do you have a sys_language record for every added language in your
root-page ? (you can control the sys_language table with phpMyAdmin)
is the page translated ?
in my case that was all fine but I needed a thorough cleanup:
I deleted all hidden records in the backend
I activated the system extension 'recycler' and deleted all in the
list (from root-page recursive)
I then checked with phpMyAdmin which records in tt_content where
hidden (and did not show in the backend) and deleted those manually
once I did that the translate request answered perfectly and I could restore the missing CE's translations
note: I still had gridelements showing up in wrong sequence for the translation in the backend but correctly in the frontend, the nested CE's seem though, and of course 'CLEAR CASH FREQUENTLY' to avoid surprises ...
I have this in nearly every project: TypoScript cascades to child nodes in the pagetree by default. If you want to prevent it from being applied to child nodes, one solution is to create an extra TS template that undoes it and include it as "template on next level".
E.g. you want to apply some TS to a specific parent page, but not it's children:
temp.somemenu.wrap = **|**
Apart from the "template on next level" approach, solutions/hacks include:
if you know which level you start from:
[treeLevel = 2]
temp.somemenu.wrap = **|**
[global]
If you have the pid and want to wire it in a constant:
[page|uid = {$targetPagePid}]
temp.somemenu.wrap = **|**
[global]
EDIT: adapted to constant – this is quite a robust solution!
Isn't there some switch to make a TS setting NOT cascade? Or define the number of levels it can cascade to?
Something like
<INCLUDE_TYPOSCRIPT: source="path/to/my.ts" treeLevelsDown="0">
or
[global treeLevelsDown = 0]
temp.somemenu.wrap = **|**
[global]
This would mean that the TS is kind of self-aware, knowing on which tree level it has been set. Not sure if that's even possible.
Does it make sense?
Or am I missing some existing solution?
No, this does not work any other way than those you already mentioned in your question. The reason for this is, that TYPO3 start from a page and the looks upwards the page tree, until it finds a TypoScript template. (It collects all extension templates on the way and applies them on top of the first found root template).
Therefore it never goes down, but only up. If it would stop cascading after a certain level, what should be used as TypoScript template for those sites? It still needs a configuration to render the page.
The question is theoretical, and #pgampe answers it.
About my use case, here's the solution from #bernd-wilke-πφ, which works just fine
// just apply to page references
[page|uid = {$pidReferencesList}]
// add some additional js (a list filter)
page.includeJSFooter {
refs = {$templatePath}/Resources/Public/additional_js/references.js
}
// add some markup
lib.thecontent.wrap = <div id="items-list-wrapper">|</div>
[global]
What I'm aiming to do!
I'm creating a template for a site in typo3, and i'd like to get rid of typo3's default content zones, and replace them with my own.
I.E. On the page menu.
to remove left, content, border
and to keep/add. Header. Main. Right.
The problem!
I've found snippets around the web, and bluntly, what I'm expecting to happen, isn't happening. Where every post seems to be "Thank you, great success! ++", the code I paste isn't throwing any errors, and isn't doing anything, well, at all.
My attempt
Via the typo3 documentation http://typo3.org/documentation/snippets/sd/24/
I call mod.SHARED.colPos_list in order to choose the three sections to display
t3lib_extMgm::addPageTSConfig('
mod.SHARED.colPos_list = 0,1,3
');
And I edit the TCA in extTables.php to set them to my specs.
$TCA["tt_content"]["columns"]["colPos"]["config"]["items"] = array (
"1" => array ("Header||Header||||||||","1"),
"0" => array ("Main||Main||||||||","0"),
"3" => array ("Right||Right||||||||","3"),
);
extTables.php is being called as as a die(); cuts the page.
I've cleared the cache and deleted typo3temp, logged out and in again.
But nothing happens.
My main guess, is, is this feature anything to do with templavoila? I removed it as I felt like trying out the new(er) typo3 fluid templating system, and didn't feel that I needed a GUI editor.
Any ideas?
Well - the more pages and content elements you got the more problems you will have to face when using TemplaVoila. Having comma separated values in XML structures saved to a single database field will be a performance killer as soon as you want to collect content from more than one page (uncached teaser menus or the like). Handling of references and "unused elements" is questionable as well. Of course it will work for small to medium sites, but concept wise a clean approach looks different.
Backend layouts are available since TYPO3 4.5 and work flawlessly since they just represent a normalized relation between elements and pages based on colPos. If you need more, Grid Elements will take this principle to the next level, offering even nested structures but still based on normalized relations, which will make your life much easier when it comes to DB cleaning and other maintenance tasks.
Find an introduction to backend layouts here: http://www.youtube.com/watch?v=SsxfNd4TYbk
Instead of removing default columns you can just rename them...
TIP: Use TemplaVoila extension for templating, you'll find much more flexibility there.