Les guides de style sont des directives linguistiques centralisées qui définissent la manière dont le contenu doit être rédigé pour une langue ou une région spécifique. Ils aident à garantir que le ton, la terminologie, la mise en forme et la sortie restent cohérents entre les projets et les équipes.
Les guides de style sont téléchargés sous forme de fichiers Markdown (.md) et stockés dans une bibliothèque partagée accessible depuis le tableau de bord de la plateforme Phrase en sélectionnant Ressources dans le menu de navigation de gauche. Ils peuvent être joints et réutilisés aux projets suivants :
Lorsqu'un fichier Markdown est téléchargé ou qu'une version précédente est restaurée, Phrase génère automatiquement une version optimisée par l'IA du guide de style. Cette version est utilisée dans les flux de travaux d'IA pour améliorer les résultats de l'Agent de traduction par IA et de MT Optimize sans nécessiter d'instructions personnalisées pour chaque tâche. Le guide de style compatible avec l'IA permet aux services d'IA de Phrase d'adapter le ton et la formalité aux préférences de l'utilisateur, d'appliquer la terminologie et le libellé requis, et de suivre les conventions spécifiques à la région.
Bien que l'Agent de traduction IA prenne en compte à la fois les bases terminologiques et les guides de style, les guides de style n'imposent pas directement la terminologie issue d'une base terminologique. L'utilisation de guides de style n'entraîne aucun coût supplémentaire en unités d'IA (AIU).
Chaque guide de style s'applique à exactement une région (par exemple, en-US ou de-DE). Si plusieurs variantes ou cas d'utilisation nécessitent des règles différentes, des guides de style distincts doivent être créés.
Les organisations peuvent ajouter jusqu'à 500 guides de style.
Remarque
Les guides de style créés avant que les groupes de contenu et les règles ne soient activés pour une organisation ne sont pas liés à un groupe de contenu par défaut, les règles ne sont pas extraites automatiquement et le re-téléversement d'un fichier vers un tel guide ne déclenchera pas l'extraction des règles. Pour convertir un guide de style en règles, retéléversez le guide de style et choisissez un groupe de contenu lors du téléchargement.
Autorisations
-
Seuls les administrateurs de l'organisation de la plateforme peuvent créer, modifier, supprimer ou définir des guides de style par défaut.
-
Les utilisateurs ayant le rôle de membre de la plateforme (par exemple, les linguistes) peuvent consulter les guides de style depuis l'onglet Ressources. Ils ne peuvent effectuer aucune modification.
-
Les chefs de projet peuvent joindre des guides de style aux projets.
-
Les linguistes et les traducteurs peuvent consulter les guides de style joints dans les éditeurs TMS et Strings.
-
Les utilisateurs peuvent télécharger la dernière version d'un guide de style sous forme de fichier Markdown depuis l'onglet Ressources.
Exigences relatives aux fichiers et à la structure
-
Un guide de style au format Markdown (.md) par paramètre :
-
Taille maximale : KO
-
Les images ne sont pas prises en charge
-
Les fichiers Markdown (.md) doivent être enregistrés avec un encodage UTF-8. Les fichiers enregistrés avec un encodage UTF-16, tels que ceux enregistrés depuis le Bloc-notes en utilisant l'option « Unicode », ou les fichiers créés en copiant directement le contenu depuis Microsoft Word, peuvent utiliser un encodage incompatible. Le téléchargement d'un fichier avec un encodage incompatible entraîne l'affichage du contenu du guide de style avec un espacement incorrect ou des caractères tronqués. Avant le téléchargement, ouvrez le fichier dans un éditeur de texte tel que le Bloc-notes ou VS Code, sélectionnez Enregistrer sous, et choisissez UTF-8 comme encodage.
-
-
-
Structure recommandée :
-
Objet et portée
-
Voix et ton
-
Grammaire et règles de rédaction
-
Terminologie (termes approuvés et interdits)
-
Conventions locales
-
Normes de formatage
-
Conseils sur le type de contenu
-
Dépannage et style des erreurs (le cas échéant)
Des titres clairs et des règles structurées améliorent à la fois la lisibilité humaine et l'interprétation par l'IA.
-
Vous trouverez ci-dessous un exemple de guide de style complet et sans conflit, qui peut être adapté selon les besoins :
Paramètres régionaux : en-US
de la localisation Produit SaaS B2B – Centre d'aide et interface utilisateur
# Style Guide: EN-US – Articles du Centre d'aide ## 1. Purpose & Scope This style guide defines the writing standards for all **Help Center documentation** in **English (United States)**. It applies to: - How-to articles - Feature explanations - Troubleshooting guides - FAQ entries **Audience:** professional SaaS users in technical and business roles **Goal:** help users complete tasks quickly, confidently, and without confusion. --- ## 2. Voice & Tone Help Center content should sound: - **Clear and professional** - **Supportive and solution-focused** - **Confident, not promotional** We write as a guide helping users succeed — not as marketing copy. ### Tone principles | Do | Don’t | |---|------| | Be calm and direct | Be overly casual or chatty | | Focus on next steps | Focus only on what went wrong | | Use neutral language | Use sarcasm or humor | **Examples** - ✅ “If the connection fails, check your API token and try again.” - ❌ « Votre jeton est incorrect. Corrigez-le. » --- ## 3. Grammar & Writing Style ### 3.1 Address the reader directly Use **you** to make instructions clear. - ✅ “You can manage users from the Admin page.” - ❌ “Users can be managed from the Admin page.” --- ### 3.2 Prefer active voice Active voice is shorter and easier to follow. - ✅ “Select **Save changes**.” - ❌ “Save changes should be selected.” --- ### 3.3 Keep sentences concise - Aim for **25 words or fewer** - One main idea per sentence - Break long explanations into steps or bullets --- ### 3.4 Use plain language Avoid unnecessary complexity. - ✅ “Start a new project.” - ❌ “Initiate the creation of a new project.” --- ## 4. Terminology & Consistency ### 4.1 Use approved terms Use product and feature names exactly as defined. - Keep capitalization consistent - Do not invent synonyms for key concepts **Example** - ✅ “workspace” - ❌ “space,” “project area,” “environment” --- ### 4.2 Define uncommon acronyms Common terms (API, URL) do not need definition. Internal or uncommon acronyms should be explained on first use. - ✅ “Single Sign-On (SSO)” - ❌ “SSO” without context --- ### 4.3 US English conventions Always use **en-US spelling**. - ✅ “customize,” “behavior” - ❌ “customise,” “behaviour” --- ## 5. Formatting & Markdown Standards ### 5.1 Headings Use clear, task-based headings. - ✅ “Reset your password” - ❌ “Password resetting process overview” Heading hierarchy: - `#` Article title - `##` Main sections - `###` Subsections only when needed --- ### 5.2 Lists Use numbered lists for sequences: 1. Open **Settings** 2. Select **Billing** 3. Choose **Change plan** Use bullets for options: - Admins can manage users - Editors can update content --- ### 5.3 UI elements Format UI labels consistently: - Buttons: **bold** - Navigation paths: use arrows Exemple : Go to **Settings → Billing → Change plan**. --- ### 5.4 Links Links must describe the destination. - ✅ “See the billing guide” - ❌ “Click here” --- ## 6. Standard Article Structure Every Help Center article should follow this structure: ### 1. Résumé Start with 1–2 sentences explaining the outcome. > This article explains how to change your subscription plan. --- ### 2. Prerequisites (optional) List requirements upfront. - Admin permissions - Active subscription --- ### 3. Step-by-step instructions Steps should be: - Action-oriented - One action per step - Written as commands Exemple : 1. Go to **Settings**. 2. Select **Billing**. 3. Choose **Change plan**. --- ### 4. Expected result Tell the user what should happen. > Your new plan takes effect immediately after confirmation. --- ### 5. Next steps (optional) Provide related actions or links. - Manage invoices - Update payment method --- ## 7. Troubleshooting & Errors ### 7.1 Be reassuring - ✅ « Nous n'avons pas pu nous connecter. Veuillez réessayer. » - ❌ « Échec de la connexion. Erreur critique. » --- ### 7.2 Focus on solutions Always include what the user should do next. - Check credentials - Confirm permissions - Contact support if needed --- ### 7.3 Never blame the user Avoid language like: - “You did something wrong” - “Invalid input” (without explanation) Preferred: > « Le jeton est peut-être expiré. Générez-en un nouveau et réessayez. » --- ## 8. Do / Don’t Summary ### Do - Write task-focused, step-based content - Use consistent terminology - Keep sentences short and direct - Use descriptive headings and links - Maintain a calm, supportive tone ### Don’t - Add marketing language - Use idioms or slang - Mix terms for the same concept - Blame the user in troubleshooting - Write long paragraphs without structure --- ## Example (Preferred) To change your plan: 1. Go to **Settings → Billing** 2. Select **Change plan** 3. Choose an option and select **Confirm**
Les guides de style sont créés et gérés dans la bibliothèque partagée accessible depuis le tableau de bord de la plateforme Phrase en sélectionnant dans le menu de navigation de gauche. La page répertorie tous les guides de style disponibles dans votre organisation.
Si vous êtes connecté à Phrase TMS, Phrase Strings ou Phrase Studio, sélectionnez dans la navigation de gauche pour ouvrir la bibliothèque partagée.
Créer un guide de style
Pour créer un nouveau guide de style en tant qu'administrateur, suivez ces étapes :
-
Sur la page , sélectionnez Nouveau guide de style.
La page s'affiche.
-
Configurez , et (facultatif).
Le nom doit être unique.
-
Glissez-déposez ou sélectionnez Téléverser un fichier pour téléverser le guide de style au format Markdown (.md).
-
Cliquez sur Créer un guide de style.
Phrase génère automatiquement la version compatible avec l'IA à partir du fichier téléversé. Cela peut prendre quelques secondes.
Le nouveau guide de style est ajouté à la page .
-
Optionnellement, sélectionnez Définir par défaut.
Lors de l'association de guides de style à de nouveaux projets, Phrase suggère le guide de style par défaut si aucun guide spécifique n'est défini. La suggestion peut être remplacée.
Astuce
Supprimez toutes les règles spécifiques à une langue du guide de style par défaut.
Modifier ou supprimer des guides de style
Les guides de style peuvent être mis à jour, versionnés, partagés ou supprimés. Depuis la page , utilisez le menu à côté d'un guide de style listé pour :
-
Définir par défaut
Marquer le guide de style comme suggestion par défaut lorsqu'aucun guide spécifique n'est sélectionné dans les nouveaux projets. La suggestion par défaut peut être remplacée au niveau du projet.
-
Supprimer
La suppression d'un guide de style ne modifie pas rétroactivement les travaux terminés ou en cours. Seule la dernière version d'un guide de style peut être jointe aux nouveaux projets.
Astuce
Avant de supprimer un guide de style, vérifiez :
-
S'il est toujours joint à des projets ou des modèles actifs
-
S'il doit être conservé pour des raisons de conformité ou de référence historique
-
-
Copier le lien public
Générez un lien en lecture seule à partager avec des parties prenantes externes qui ne possèdent pas de compte Phrase.
Sur la page , sélectionnez l'icône en forme de crayon à côté d'un guide de style pour ouvrir la page et mettre à jour ses métadonnées, son fichier Markdown ou son statut par défaut.
Une description facultative des modifications peut être ajoutée avant l'enregistrement pour l'inclure dans l'historique des versions. Une nouvelle version est créée uniquement lorsque le fichier Markdown est remplacé. Cette version s'applique uniquement aux nouveaux travaux ou aux travaux qui n'ont pas encore commencé dans les projets où le guide de style est utilisé.
Gérer l'historique des versions
Les guides de style conservent un historique des versions en cas de modifications apportées aux versions existantes.
Pour afficher l'historique des versions et restaurer des versions d'un guide de style, suivez ces étapes :
-
Sur la page , cliquez sur un guide de style dans la liste pour ouvrir sa page de détails.
-
Sélectionnez Historique des versions dans le
en haut de la page de détails.
Le panneau s'affiche.
-
Sélectionnez une version antérieure répertoriée dans la section .
La version antérieure s'affiche.
-
Si nécessaire, sélectionnez Modifier à partir de cette version dans l'.
La version précédente est restaurée pour créer une nouvelle version active basée sur celle-ci.
La restauration ou la modification à partir d'une version antérieure n'écrase pas l'historique.
Une fois qu'un guide de style a été créé dans la bibliothèque, il peut être associé à des projets dans Phrase TMS, Phrase Strings et Phrase Studio.
Comportement général dans l'ensemble des produits :
-
Les guides de style sont configurés par langue cible et s'appliquent à l'ensemble du projet. Ils sont appliqués lors de la pré-traduction avec l'agent de traduction IA, ou comme étape de post-édition avec MT Optimize.
-
Lorsqu'une nouvelle version du guide de style est créée, elle ne s'applique qu'aux nouveaux travaux. Les travaux en cours continuent d'utiliser la version active au moment de la création.
-
Les fonctionnalités d'IA utilisent automatiquement le guide de style joint lorsqu'il est pris en charge. Les guides de style n'affectent pas les segments verrouillés, car MT Optimize ne les modifie pas. Par défaut, l'agent de traduction IA laisse également les segments provenant d'une mémoire de traduction (TM) inchangés, bien que cela puisse être configuré dans les paramètres de pré-traduction.
Phrase TMS
Les guides de style peuvent être joints à un projet ou à un modèle de projet.
-
Lors de la création ou de la modification d'un projet ou d'un modèle de projet, accédez à la section et sélectionnez un guide de style pour chaque paramètre cible.
Le système peut présélectionner automatiquement le guide de style le plus pertinent en fonction de la correspondance des paramètres régionaux. La présélection peut toujours être remplacée ou effacée.
Remarque
Non pris en charge dans la vue classique des modèles de projet.
-
Les modifications apportées aux modèles de projet n'affectent que les projets et travaux nouvellement créés. Les projets existants ne sont pas mis à jour rétroactivement.
-
Les guides de style joints sont visibles par les linguistes dans le volet
de l'éditeur CAT web en tant que ressource en lecture seule.
-
Les fournisseurs dans les projets partagés ne peuvent pas modifier le guide de style attribué par un acheteur.
-
Dans les scénarios de travail partagé, les fournisseurs peuvent utiliser le guide de style attribué mais ne peuvent pas modifier la configuration au niveau du projet.
-
Phrase Strings
-
Dans une page de projet, accédez à l'onglet et sélectionnez un guide de style pour chaque paramètre cible.
-
Les guides de style joints sont visibles par les traducteurs au niveau de la clé dans le menu de la barre latérale de l'éditeur de chaînes.
Phrase Studio
-
Lors de la création d'un projet, sélectionnez un guide de style pour chaque langue cible ajoutée au projet.
Le système peut présélectionner automatiquement le guide de style le plus pertinent en fonction de la correspondance des paramètres régionaux. La présélection peut toujours être remplacée ou effacée.
-
La version compatible avec l'IA du guide de style est appliquée en arrière-plan en tant qu'entrée contextuelle pour les flux de travaux de l'agent de traduction IA.
API de guide de style
Les guides de style sont également accessibles via une API publique de guide de style dédiée, distincte de l'API de Phrase TMS. Cette API prend en charge la création, la mise à jour, la récupération, la recherche et le versionnage des guides de style par programmation. Les nouvelles intégrations doivent utiliser les points de terminaison v2, POST /api/v2/styleguides et PUT /api/v2/styleguides/{id}, qui lient un guide de style à un groupe de contenu. L'API est spécifique à une région :
-
UE : https://eu.phrase.com/styleguide
-
États-Unis : https://us.phrase.com/styleguide
L'authentification nécessite l'échange d'un jeton d'API de la plateforme Phrase contre un JWT, comme décrit dans le guide d'authentification de la plateforme dans la documentation pour les développeurs.