Make pattern property translatable for multilingual alias support

Thanks, but this isn't enough yet.

See #2630382: "Strings to remove" option missing translation support, we need to ensure to match the config language with the entity language, as for example bulk generation can generate aliases for different languages in the same request/language.

The way this is supposed to work now is to have language conditions, so you don't create translations, you create separate patterns for each language. I'm not sure about allowing translation too, that could get very complicated and confusing.

@Berdir I understand your point, however you should take this into account: having a multilingual site with 20 languages, and 30 vocabularies, leads to 600 pattern rules...

With pattern translations, you only have 1 rule per pattern, so 30 patterns for the vocabularies.

Moreover, each rule requires a unique ID, which also lead to headaches when it comes to organize this.

And last point, the patterns page with 600 rules is not a thing that can be managed when looking for updating a specific rule...

What would be your suggestions for such a case?

@B-Prod: "...having a multilingual site with 20 languages, and 30 vocabularies, leads to 600 pattern rules...."

Not necessarilly, one pattern can be applied to multiple languages. There is "Languages" field in pattern edit form. The problem, you described, occurs in specific situation, when pattern contains some static string (not just tokens).

Make PathautoPattern $pattern property translatable

On multilingual Drupal sites, the URL alias pattern (e.g. /content/[node:title])
could not differ per language because the pattern property was defined as
type: string in the config schema, which is not translatable.

Solution

1. Schema (config/schema/pathauto_pattern.schema.yml)
   Changed pattern type from string to label,
   making it translatable via Drupal's config translation UI.
2. Service definition (pathauto.services.yml)
   Added @language_manager as a new argument to the pathauto.generator service.
3. Generator (src/PathautoGenerator.php)
   Injected LanguageManagerInterface and, in createEntityAlias(),
   added logic to fetch language-specific config overrides via
   ConfigurableLanguageManagerInterface::getLanguageConfigOverride().
   The translated pattern string is then used for token replacement and empty-token detection
   instead of the default entity value.
4. Test (tests/src/Kernel/PathautoKernelTest.php)
   Added testTranslatedPattern() which:
   • Sets a French config override: /contenu/[node:title]
   • Verifies a French node gets alias /contenu/bonjour-le-monde
   • Verifies an English node still gets alias /content/hello-world

Usage

With the config_translation module enabled, go to
Admin > Config > Search and metadata > URL aliases > Patterns,
and use the Translate operation on any pattern to provide
per-language alias patterns.

Fine, also the clone takes care of a problem when the same object could have multiple different translations in the same request.

One thing to be aware of is that locale/potx doesn't make a difference between translatable and localizable things, at least not with type: label. This means that default patterns can end up as translatable strings on localize.drupal.org and it will also end up syncing with the locale table, which can result in some confusing situations (frequently get that with metatags and webforms), but that's hardly our fault.