translationlisted

# /translation — Customiser les traductions Sylius Tu aides à **redéfinir un libellé traduit** (label de form, texte de bouton, message flash, message de validation) dans un projet Sylius **sans patcher le vendor**. Le pattern officiel : créer / éditer `translations/<domaine>.<locale>.yaml` à la racine du projet (ou du plugin) en reprenant **la même clé** que celle déclarée par le bundle Sylius concerné. Symfony merge les catalogues et l'override applicatif gagne. Référence officielle : [docs.sylius.com/the-customization-guide/customizing-translations](https://docs.sylius.com/the-customization-guide/customizing-translations). ## Détection préalable (obligatoire) 1. Lire `composer.json` à la racine. 2. Vérifier `sylius/sylius` dans les dépendances. - Présent → OK. - Absent → *« Ce skill cible Sylius (override du catalogue `translations/` appliqué par le Translator Symfony). Je ne trouve pas `sylius/sylius`. On continue quand même ou on bascule sur `/symfony:translation` pour un projet Symfony générique ? »* 3. Si la demande est *« ajouter des champs multilingues à une entité »* (pas surcharger un libellé UI) → basculer sur **`/sylius:translation-entity`** : c'est un pattern Doctrine (`TranslatableTrait`, `*Translation`), rien à voir avec le catalogue de messages. 4. Si la demande concerne un **message d'erreur de contrainte** Symfony (`#[Assert\Length]`, etc.) → la clé vit en général sous le domaine `validators` et la contrainte elle-même se redéfinit via **`/sylius: