Bug #90653

TCA eval with uniqueInPid: allow identical value in localized content

Added by Sebastian Klein 8 months ago. Updated 7 months ago.

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

0%

TYPO3 Version:
9
PHP Version:
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=exclude Closed 2018-03-14
Related to TYPO3 Core - Bug #87038: Unique evaluation does not work with l10n_mode=exclude after editing original record again Closed 2018-11-29

History

#1 Updated by Georg Ringer 8 months ago

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

#2 Updated by Georg Ringer 8 months 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 8 months 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 8 months 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 7 months 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 7 months 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.

Also available in: Atom PDF