Initialize new tenant with German and English Metadata and Structures?

[stweil]

It's possible to create Metadata and Structures for a new tenant automatically in TYPO3. Ideally this should create 30 bilingual entries for Metadata and 92 bilingual entries for Structures like in this example.

It seems to be difficult to set up the site correctly to get this result. Often there will only be entries which are all either in English or in German.

Instructions for the recommended site setup which produces the desired result would be helpful.

[stweil]

The result shown in the image above was produced with a site config.yaml like this:

base: 'http://local.typo3:8080/'
languages:
  -
    title: German
    enabled: true
    base: /
    flag: de
    hreflang: de-DE
    languageId: 0
    locale: de_DE
    navigationTitle: Deutsch
    typo3Language: de
    websiteTitle: ''
  -
    title: English
    enabled: true
    base: /en/
    fallbackType: strict
    fallbacks: '0'
    flag: en-us-gb
    hreflang: en-US
    languageId: 1
    locale: en_US
    navigationTitle: English
    typo3Language: default
    websiteTitle: ''
rootPageId: 1
websiteTitle: 'Example Site'

It's not possible to produce this site configuration in the TYPO3 backend.

[stweil]

Here is the wrong result for Kitodo metadata which was created with "New Tenant" in an installation based on the TYPO3 Introduction (installed with composer require typo3/cms-introduction):

[stweil]

It looks like correct data is only produced if typo3Language is set in config.yaml for the site.
typo3Language is deprecated since TYPO3 v12 and can no longer be set in the TYPO3 backend.

Update: in my latest tests I found 3 possible ways to get correct bilangual data:

1. Add deprecated typo3Language: de
2. Set locale: de
3. Set locale: de_DE and link or copy de.locallang_metadata.xlf to de_DE.locallang_metadata.xlf (and similar for de.locallang_structure.xlf)

[stweil]

See also my related comment for dfg-viewer.

[michaelkubina]

Dear Stefan,
this discussion is a life saver! Thank you very much for your insights, this helped me set up our instance and have the new tenant actually localized! I was not able to wrap my head around, why it was not working...now i do.

The newTenantController uses the getTypo3Language method, which returns either <languageCode> or <languageCode>_<countryCode> (https://github.com/TYPO3/typo3/blob/fdc388af47616c86239920e212b3c4cba7520878/typo3/sysext/core/Classes/Site/Entity/SiteLanguage.php#L227)

So, if someone sets up the language of the site with a Typo3 preset (like i did), it will automatically have its locale like "de_DE" or "en_US" and therefore return "de_DE" as the prefix for the XLF files.

• Using the deprecated property is obviously not how to do it.
• Using just the language code as the locale should at least be mentioned in the extension documentation then, but needs additional attention by users and collides with the Typo3 presets. But its just as simple and small correction during site setup - it just needs to be mentioned somewhere.
• Having country specific translations would work best with the Typo3 presets and have the benefit of using country specific terms. But it would potentially require even more translation files, the presets do not necessarily code the correct country code, so the locale must be set none the less then. Otherwise it would fallback to default which is english.

So, i believe, the best way to do this, is to update the documentation accordingly, so that during site setup the locale is correctly set as "de", "en" or whatever language codes might be available in the future.

What do you think?

[sebastian-meyer]

Thanks for debugging this, @michaelkubina!

So, the correct way of handling this would be to prefix our XLF language files with full language/country codes, right?

I don't like recommending using "incomplete" language codes in site setup, because deviating from the TYPO3 default is error-prone. Instead we should try to be compatible with TYPO3 standards, i. e. duplicate our German language files as "de_DE", "de_AT" and "de_CH". Sure, that means a bit more effort in keeping those files up to date, but overall I think it would be the better approach.

What do you think?

[michaelkubina]

This was quite a rabbit hole...so, Typo3's documentation and code is not quite clear about this...but after much reading i would say:

No, we should not change the prefix ... the way we prefix our language files right now is correct. I belive just this function call ->getTypo3Language() is not correct here...

While its absolutely possible to use special country specific translations, it does not seem like its the standard way:

• the sites language preset, which sets the locale (e.g. de_DE) comes from here https://github.com/TYPO3/typo3/blob/main/typo3/sysext/core/Classes/Site/SiteLanguagePresets.php
• but when talking about localization and supported languages, then this list seems to be the one to look at: https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/Localization/Languages.html
  In the end this is the list, that allows for picking language packs in the backend and that determines the prefix of the language files used. So this means even Typo3's own translation files use the prefixes, we are using right now. With this new insights, no, i would not change the prefix.
• Typo3 allows for defining custom languages, having fallbacks to other labels (partially or completly) and working with <languageCode>_<countryCode> combinations, but these seem more like a "expanding the base capabilities": https://docs.typo3.org/m/typo3/reference-coreapi/13.4/en-us/ApiOverview/Localization/ManagingTranslations.html#custom-languages

So, after looking very deep into it...i believe we just have a bug. In the newTenant controller we use the SiteLanguage object (https://github.com/TYPO3/typo3/blob/13.4/typo3/sysext/core/Classes/Site/Entity/SiteLanguage.php). As we have seen the site language (= locale in the sites configuration) is not the same locale, when talking about translation files, but its derived from it. The SiteLanguage object stores a Locale object (https://github.com/TYPO3/typo3/blob/main/typo3/sysext/core/Classes/Localization/Locale.php) accesible via ->getLocale(), that we can work with in order to determine the language key via ->getLanguageCode, which would fix the translation issue when we use the new tenant controller.

TL;DR
No, our prefixes are fine, we should not change them. Typo3 does it the same way we do.
But we should change ->getTypo3Language() to ->getLocale()->getLanguageCode(), because we want to extract the language key from the webites locale.

I can write a PR for this if you see it the same way i see it.

[sebastian-meyer]

Sounds absolutely reasonable to me! I'd appreciate a pull request!
Thank you very much for diving into this issue!

[sebastian-meyer]

This is fixed with #1775. Thanks to @michaelkubina!