TYPO3 Core

Georg Ringer wrote:

can you check if the patch of #87038 https://review.typo3.org/c/Packages/TYPO3.CMS/+/58979 would work for you?

I tested this in Version 10.3.0. This patch applies only to fields with 'l10n_mode' => 'exclude'.

Setting this l10n_mode would copy the (then identical) value from the source language. But it would prevent the editor to change the value in the localized record.

I mean I get what you want to do, but in general this adds quite some complexity:
What if a user changes a "language=1" news record with value "custom-de" to "language=0" (making it unique on a per-language level) - then this would need to be automatically adjusted on a per-language level. Things like "language=-1" would also be tricky to achieve.

can you explain your use case?

Benni Mack wrote:

I mean I get what you want to do, but in general this adds quite some complexity:
What if a user changes a "language=1" news record with value "custom-de" to "language=0" (making it unique on a per-language level) - then this would need to be automatically adjusted on a per-language level. Things like "language=-1" would also be tricky to achieve.

can you explain your use case?

Example:

An editor writes about the services of his web agency. He also wants to use human-readable fragments to link to the different sections on the same page.

The result should be something like https://www.awesome-agency.com/services/#fragment

• First, he configures fragments for two content elements in the english language: #concept and #typo3.
• Then, he wants to configure fragments for the german translation: no issues with the first content element, he can use #konzeption here. But when he tries to configure #typo3 for the second CE, the result will be typo30 instead.

The basic problem:

While for many text sections the corresponding fragments could be localized quite easily, brand names etc. are an issue. You could use #ueber-typo3 in my example instead.
What about a professional article with many technical terms, though? I'd consider it unpleasant to use #ueber-optionsplit, #ueber-parsefunc and so on.

But I'm now aware that the necessary changes to uniqueInPid are more complex than I initially thought. You must decide if you want to add more complexity to this part of TYPO3.

Side note:
When a content element with the fragment #example is moved to a new page, the uniqueness of this fragment will automatically be checked during the copy process. If another CE on the new page already contains the identical fragment, the fragment of the copied CE will then be changed to #example0.
I guess that this check could be performed as well when the content element's sys_language_uid is changed. The several localization modes of TYPO3 may require a more complex solution, though.

Sebastian Klein wrote in #note-6:

Benni Mack wrote:

I mean I get what you want to do, but in general this adds quite some complexity:
What if a user changes a "language=1" news record with value "custom-de" to "language=0" (making it unique on a per-language level) - then this would need to be automatically adjusted on a per-language level. Things like "language=-1" would also be tricky to achieve.

can you explain your use case?

Example:

An editor writes about the services of his web agency. He also wants to use human-readable fragments to link to the different sections on the same page.

The result should be something like https://www.awesome-agency.com/services/#fragment

• First, he configures fragments for two content elements in the english language: #concept and #typo3.
• Then, he wants to configure fragments for the german translation: no issues with the first content element, he can use #konzeption here. But when he tries to configure #typo3 for the second CE, the result will be typo30 instead.

The basic problem:

While for many text sections the corresponding fragments could be localized quite easily, brand names etc. are an issue. You could use #ueber-typo3 in my example instead.
What about a professional article with many technical terms, though? I'd consider it unpleasant to use #ueber-optionsplit, #ueber-parsefunc and so on.

But I'm now aware that the necessary changes to uniqueInPid are more complex than I initially thought. You must decide if you want to add more complexity to this part of TYPO3.

Side note:
When a content element with the fragment #example is moved to a new page, the uniqueness of this fragment will automatically be checked during the copy process. If another CE on the new page already contains the identical fragment, the fragment of the copied CE will then be changed to #example0.
I guess that this check could be performed as well when the content element's sys_language_uid is changed. The several localization modes of TYPO3 may require a more complex solution, though.

Hi Sebastian,
hi Benni,

I've exactly the same problem like Sebastian described.
My example is about a hotel website, where the customer could create rooms and they are visible as detail pages in the frontend.
Every room should have a clean unique URL ( like /en/rooms/pool-suite), but in the german translation, the room should also be called pool-suite and
with uniqueInPid, it gets converted to pool-suite0.
An Option like uniqueInPidAndLanguage would be cool, but I know, that's a lot of work and also complicate to achieve and to maintain.

@Benni Mack If there is nothing planned for this case, what would be a good solution? May you give me a good hint?
@Sebastian Kurfuerst: What was your solution?

Thanks in advance.

Cheers,
Michael