Change Details

Since we are autogenerating the combinations like “ab, ac” etc. for backlink markers, we want to display a warning, when users enter them in the config settings. See epic for details. We are aware of two situations that are particularly relevant here: 1. There are alphabets that actually contain such duplicates. E.g. [hsb](https://gerrit.wikimedia.org/r/c/mediawiki/extensions/cldr/+/1081994/18/CldrMain/CldrMainHsb.php) actually contains all of "CH", "C", "H", "DŹ", "D", and "Ź" as individual characters. 2. We don't want admins to manually enter anything beyond the basic alphabet, [as it was done with the old message](https://de.wikipedia.org/wiki/Special:Diff/180315347). We don't know yet what the most correct solution for situation 1 is. It should be possible to have different solutions for the two. In situation 2 **everything** is a duplicate after the basic alphabet while the duplicates in situation 1 are sprinkled around randomly. Open questions: * Do we want the validation (only) client-side as part of the CommunityConfiguration page, or raise it as an error in other places as well? * The renderer could keep track of previous labels and simply skip duplicates. We could signal this to all users with the existing error reporting system in Cite (i.e. rendered as part of the article). * As above, but instead of skipping labels the renderer stops using the bogus alphabet and falls back to the default a…z. * We let the special page fail so the admin cannot save a bogus alphabet in the first place. This solves the issue in some situations, but not when an alphabet is provided manually via the `$wg…` configuration. However, that might be totally acceptable for all use-cases we care about. * …?

Since we are autogenerating the combinations like “ab, ac” etc. for backlink markers, we want to display a warning, when users enter them in the config settings. See epic for details. We are aware of two situations that are particularly relevant here: 1. There are alphabets that actually contain such duplicates. E.g. [hsb](https://gerrit.wikimedia.org/r/c/mediawiki/extensions/cldr/+/1081994/18/CldrMain/CldrMainHsb.php) actually contains all of "CH", "C", "H", "DŹ", "D", and "Ź" as individual characters. 2. We don't want admins to manually enter anything beyond the basic alphabet, [as it was done with the old message](https://de.wikipedia.org/wiki/Special:Diff/180315347). We don't know yet what the most correct solution for situation 1 is. It should be possible to have different solutions for the two. In situation 2 **everything** is a duplicate after the basic alphabet while the duplicates in situation 1 are sprinkled around randomly. A superb idea came up [here](https://www.figma.com/design/Waj127iiav7sRHENkkZkc2/Backlinks-Special-Page-UI?node-id=0-1&p=f&t=8nJ3FMGapDnYWOpR-0#-1): We treat the 1st character as special and match it against the remaining string. When it appears again it's clear that the admin tried to continue the sequence manually. Open questions: * Do we want the validation (only) client-side as part of the CommunityConfiguration page, or raise it as an error in other places as well? * The renderer could keep track of previous labels and simply skip duplicates. We could signal this to all users with the existing error reporting system in Cite (i.e. rendered as part of the article). * As above, but instead of skipping labels the renderer stops using the bogus alphabet and falls back to the default a…z. * We let the special page fail so the admin cannot save a bogus alphabet in the first place. This solves the issue in some situations, but not when an alphabet is provided manually via the `$wg…` configuration. However, that might be totally acceptable for all use-cases we care about. * …?

Since we are autogenerating the combinations like “ab, ac” etc. for backlink markers, we want to display a warning, when users enter them in the config settings. See epic for details. We are aware of two situations that are particularly relevant here: 1. There are alphabets that actually contain such duplicates. E.g. [hsb](https://gerrit.wikimedia.org/r/c/mediawiki/extensions/cldr/+/1081994/18/CldrMain/CldrMainHsb.php) actually contains all of "CH", "C", "H", "DŹ", "D", and "Ź" as individual characters. 2. We don't want admins to manually enter anything beyond the basic alphabet, [as it was done with the old message](https://de.wikipedia.org/wiki/Special:Diff/180315347). We don't know yet what the most correct solution for situation 1 is. It should be possible to have different solutions for the two. In situation 2 **everything** is a duplicate after the basic alphabet while the duplicates in situation 1 are sprinkled around randomly. A superb idea came up [here](https://www.figma.com/design/Waj127iiav7sRHENkkZkc2/Backlinks-Special-Page-UI?node-id=0-1&p=f&t=8nJ3FMGapDnYWOpR-0#-1): We treat the 1st character as special and match it against the remaining string. When it appears again it's clear that the admin tried to continue the sequence manually. Open questions: * Do we want the validation (only) client-side as part of the CommunityConfiguration page, or raise it as an error in other places as well? * The renderer could keep track of previous labels and simply skip duplicates. We could signal this to all users with the existing error reporting system in Cite (i.e. rendered as part of the article). * As above, but instead of skipping labels the renderer stops using the bogus alphabet and falls back to the default a…z. * We let the special page fail so the admin cannot save a bogus alphabet in the first place. This solves the issue in some situations, but not when an alphabet is provided manually via the `$wg…` configuration. However, that might be totally acceptable for all use-cases we care about. * …?