Bug #90653

TCA eval with uniqueInPid: allow identical value in localized content

Added by Sebastian Klein almost 2 years ago. Updated 20 days ago.

Status:
Needs Feedback
Priority:
Should have
Assignee:
-
Category:
DataHandler aka TCEmain
Target version:
-
Start date:
2020-03-05
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
11
PHP Version:
7.4
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

I use the TCA evaluation uniqueInPid in my extension to get unique URL fragment identifiers ("domain.com/page/#fragment") on the same subpage.

My goal is:

  • Get unique values on the same page and language.
  • Values in localized content elements can be identical to the source language.
  • Editors can still set a different value in localized content.

Is this possible with existing TCA? Do I miss a TCA setting which will enables this behaviour? Currently, my values in localized content elements are appended with numbers ("fragment0").

As far as I understand, uniqueInPid does not distinguish between the different languages. I could use l10n_mode with 'exclude' to just use the value from the source language, but then I'd not be able to set an individual value.

If a solution does not yet exist: what do you think about a new TCA setting like "uniqueWithinLanguage" to control the behaviour of uniqueInPid?


Related issues

Related to TYPO3 Core - Bug #84267: Unique evaluation does not work with l10n_mode=excludeClosedOliver Hader2018-03-14

Actions
Related to TYPO3 Core - Bug #87038: Unique evaluation does not work with l10n_mode=exclude after editing original record againClosedBenni Mack2018-11-29

Actions
#1

Updated by Georg Ringer almost 2 years ago

  • Related to Bug #84267: Unique evaluation does not work with l10n_mode=exclude added
#2

Updated by Georg Ringer almost 2 years ago

  • Related to Bug #87038: Unique evaluation does not work with l10n_mode=exclude after editing original record again added
#3

Updated by Georg Ringer almost 2 years ago

  • Status changed from New to Needs Feedback

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

I don't know the reason why there is no backport to 9.5 is planned (yet)

thanks

#4

Updated by Sebastian Klein almost 2 years ago

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.

#5

Updated by Benni Mack over 1 year ago

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?

#6

Updated by Sebastian Klein over 1 year ago

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.

#7

Updated by Michael Rainer 12 months ago

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

#8

Updated by Tanel Põld 20 days ago

  • TYPO3 Version changed from 9 to 11
  • PHP Version set to 7.4

Ran into the same problem...

I'll add another use case.

I'm using 'uniqueInPid' in company with 'allowLanguageSynchronization' => true.

The field is "URL segment & unique ID" for pagination. It's unique to allow multiple paginators to function separate from each other on the same page.

In many cases the translation could be the same as original but never the same as in other elements in same language.

Also available in: Atom PDF