I have a TYPO3 site with a single page tree. Default language is 0 and one translated language is available which is 1.
The fallbackType configuration in the site config is strict, for the language with the id 1. The site has a language switch and shows only records of the respective language.
The problem is, that the language with the id 1 has also the configuration fallbacks: '0'. I realised, that this configuration might not be needed, because only the records are shown in the frontend, of the current language. This configuration also creates URLs of non Translated records of language id 0 for language id 1, which should not be accessible from the frontend.
Am I right in the assumption, that I can just remove the configuration fallbacks: '0' for language id 1 without breaking anything?
Related
I have a table with multiple 1:n subtables that have translations.
Now the client wants to list all records on all language versions of the website. The problem is that Extbase caches the values of the different ObjectStorages and does not differentiate between the languages. Now if I have two records with the same record the first one will fetch the title and this one is then being used for all records. So I have a crazy language mis-match.
I would like to define the language overlay of the subtables fixed for sys_language_uid and don't know how. This code: https://gist.github.com/hhoechtl/a374f7526440ba987c19 does work perfectly for a single-select but it does not work for my listview..
Is there any way I could force the language of the subqueries?
As an example. This is an italian record (sys_l = 1) and it gets shown on the german detailview with german subinfo: (https://jobfinder.look4u.it/de/job?tx_jobfinder_stellenanzeigen%5Baction%5D=show&tx_jobfinder_stellenanzeigen%5Bcontroller%5D=Stellenanzeigen&tx_jobfinder_stellenanzeigen%5Bstellenausschreibung%5D=149&cHash=6da4a876cac6125e3b0f5b0924f35463)
When you open it on the italian page ( https://jobfinder.look4u.it/it/job?tx_jobfinder_stellenanzeigen%5Baction%5D=show&tx_jobfinder_stellenanzeigen%5Bcontroller%5D=Stellenanzeigen&tx_jobfinder_stellenanzeigen%5Bstellenausschreibung%5D=149&cHash=6da4a876cac6125e3b0f5b0924f35463 ) the additional info is nicely in italian thanks to the code from hhoechtl above.
But the problem is in the listview where german (0) and italian gets mixed: https://jobfinder.look4u.it/de/anzeigen-arbeitgeber/agenturen
Extbase takes the values of 2 properties from the first record (sales controller) in italian and then keeps that lookup for all folowing records. And I'm not able to change the lookup here in the listview. The code from hhoechtl somehow doesnt work in this query.
I have found a solution. The patch released in July 2022 actually solves exactly this problem!
https://review.typo3.org/c/Packages/TYPO3.CMS/+/75099/2
Since I'm running v10 on this site I have manually implemented the patch on my T3 version and now Extbase is behaving as it should.
We have changed the primary language for our site https://staging.venicexplorer.net from English to Italian. But the problem is it is showing English text when we selected Italian and vice versa. We are now altering the languages of the content. But this is a very time consuming job. Can anyone please tell me whether there is any shortcut method?
Thanks
Prasun
Here are some hints for updating the language of content and pages in the database:
Content
The language of a content element (table tt_content) is in the field sys_language_uid. Default language is always 0, "all languages" is -1.
Each translated record (sys_language_uid NOT IN (0,1)) can (aka "connected mode") have a link to its default language counterpart. This is set in the field l10n_parent.
Pages
First of all for TYPO3v9 this depends on the feature toggle unifiedPageTranslationHandling. I will assume that your instance is already fully migrated to not use pages_language_overlay any more.
The same rules as for tt_content apply: sys_language_uid is the language, l10n_parent the default language record.
Other records
The same applies to all other translated records in TYPO3 or its extensions.
Technically, these fields are defined for each table in TCA in [ctrl][languageField] and [ctrl][transOrigPointerField] but sys_language_uid and l10n_parent are used mostly.
Notice
This is not an exhaustive list. There are fields that are only set in the default language (e.g. access restrictions). Make a backup first! But that should cover most bases.
I have some messed up values for tt_content.sorting in TYPO3 6.2 for translated records (sys_language_uid=1).
That means that styles.content.get displays the right order (as visible in the backend) in the original language, but not in the translated language (where in the backend everything looks fine, as it follows defLangBinding but in the frontend, the wrong values from the sorting fields are used, so the sorting is messed up.
We did modify some settings in the last few weeks
// before
// config.sys_language_mode = content_fallback:1,0
// config.sys_language_overlay = hideNonTranslated
// currently
config.sys_language_mode = strict
config.sys_language_overlay =0
but I am unsure if that is connected. The sorting in the DB is really wrong for some fields. It is correctable by moving individual CEs in Page or List module.
There are many related ancient bugs on forge.
My questions:
Is there a script that fixes the sorting for the translated CEs for the entire site in accordance to the main language?
Is there something like defLangBinding for the frontend - that would help as well, as the wrong sorting values would become meaningless. Or a modification for the styles.content.get query?
Why don't you just try to bring your content records in sync again? This could be done by pure SQL if there are no or only a few exclusive records in the second language. If not, you are going to mess it up even more.
This query will give you a table with the default language and the translated record side by side, including the sorting value:
select a.header, a.uid, a.sorting, b.sorting, b.uid, b.header from tt_content as a inner join tt_content as b on a.uid=b.l18n_parent where b.l18n_parent > 0 and a.sys_language_uid = 0 and not a.deleted and not b.deleted;
You could then adapt this query to an update query that sets the sorting value of table b to the one in table a.
To check if you have records without a parent in the default language, you can use this query:
select * from tt_content where sys_language_uid > 0 AND l18n_parent = 0 AND NOT deleted
As for your configuration, have a look at the manual for sys_language_overlay:
If set, records from certain tables selected by the CONTENT cObject
using the “languageField” setting will select the default language (0)
instead of any language set by sys_language_uid / sys_language_mode.
In addition the system will look for a translation of the selected
record and overlay configured fields.
So this seems to be connected to your problem: Before, TYPO3 was (maybe - you didn't post the setting for sys_language_overlay) configured to first fetch records in the default language, try to overlay them with a translation and then output it.
Now that sys_language_overlay is deactivated, the records are fetched in the translated version right away and their sorting is considered.
I had to import a few posts from one TYPO3 site into another, which lead into some exploring of the DB structure. A specific question arose:
In localised content elements (tt_content entries with sys_language_uid = 1), the fields t3_origuid and l18n_parent are redundantly filled. l18n_parent is required for the backend localisation view to work.
Do they always have the same value? Or is there a use case where the values of the fields can differ?
l10n_parent / l18n_parent
The field configured in TCA as transOrigPointerField (usually l10n_parent or l18n_parent) is used for localization.
It always contains an id of the record in the default language (even if the record was translated from a record in non-default language), see https://docs.typo3.org/typo3cms/TCAReference/singlehtml/#transorigpointerfield
t3_origuid
The field configured in TCA as origUid (usually t3_origuid) is filled when record is copied or translated, and contains an id of the source record, see https://docs.typo3.org/typo3cms/TCAReference/singlehtml/#origuid
The fields will have the same value in some cases (e.g. translating a record from default language), but in other will have different value. E.g. when copying a record on the same page t3_origuid will be different than the l10n_parent.
To allow localization it is required to have transOrigPointerField (l10n_parent). Having origUid (t3_origuid) field is not hard requirement but a good practice as as some additional features may require it to work. Especially in newer versions of TYPO3. For example the Translation Wizard is currently using t3_origuid field.
l10n_source (since TYPO3 8.6)
Since TYPO3 8.6 a new database field l10n_source for tt_content table has been introduced together with a new TCA ctrl configuration translationSource. The translationSource field contains an uid of the record used as a translation source, no matter whether the record was translated in the free or connected mode.
see more in the documentation on l10n_source field
Those fields can have different values.
t3_origuid is a generic field pointing to a record from which the current one was derived in some way. For example by copying or localizing it. Here is some documentation for it.
The field l18n_parent is reserved for localization purposes.
Just as a addition to Jost's post:
To determine which field you should use check the value of:
$TCA['tx_yourtable']['ctrl']['transOrigPointerField']
ie. for tt_content it's:
$TCA['tt_content']['ctrl']['transOrigPointerField'] = 'l18n_parent';
In the table pages_language_overlay I can see that there are entrys with sys_language_uid = 1. But there is no language if i look under list on page with id=0. How can I recover the language?
The problem is that I tried to create a new language with the id = 1 on a copy of the project. Then I had some problems because TYPO3 didn't get it managed it right with realURL (see here). What can I do?
You will have to create an additional language record for your website:
in backend: activate the list module
select the root node of the whole page tree (id=0)
check if there is already a block "Website Language" with a record in it
if not: click on "Create new record" (little icon with green plus close to top of window)
select System Records -> Website Language
select the name, ISO code and flag for your language
save
Now make sure that your new language record has id=1. If the ID is higher your autoincrement value in table sys_language was not zero (possibly because you have created and deleted a language earlier). In this case you will have to modify sys_language manually (export to SQL, modify SQL accordingly, delete table and reimport).
Cheers, Jörg.