Passer au contenu principal
L’internationalisation (i18n) est le processus qui consiste à concevoir un logiciel ou du contenu pour fonctionner avec différentes langues et différents paramètres régionaux. Ce guide explique comment structurer les fichiers, configurer la navigation et maintenir les traductions efficacement afin que vous puissiez aider vos utilisateurs à accéder à votre documentation dans leur langue préférée et améliorer votre portée à l’international.

Structure des fichiers

Organisez le contenu traduit dans des répertoires propres à chaque langue afin que votre documentation reste facile à maintenir et pour structurer votre navigation par langue. Créez un répertoire séparé pour chaque langue en utilisant les codes de langue ISO 639-1. Placez les fichiers traduits dans ces répertoires en respectant la même structure que pour votre langue par défaut.
Example file structure
Conservez les mêmes noms de fichiers et la même structure de répertoires dans toutes les langues. Cela facilite la maintenance des traductions et l’identification du contenu manquant.

Configurer le sélecteur de langue

Pour ajouter un sélecteur de langue à votre documentation, configurez le tableau languages dans la propriété navigation de votre fichier docs.json.
docs.json
Chaque entrée de langue dans le tableau languages nécessite :
  • language : code de langue ISO 639-1
  • Une structure de navigation complète
  • Les chemins d’accès aux fichiers traduits
La structure de navigation peut différer selon les langues pour s’adapter aux besoins de contenu propres à chacune.
N’utilisez pas le même chemin de page dans plusieurs locales. La duplication de chemins entre les locales entraîne un comportement indéfini. Chaque chemin de page ne doit apparaître que dans la navigation d’une seule langue.

Définir la langue par défaut

La première langue du tableau languages est automatiquement utilisée comme langue par défaut. Pour définir une autre langue comme langue par défaut, réorganisez le tableau ou ajoutez la propriété default :
docs.json
Vous pouvez également utiliser la propriété default pour modifier l’ordre :
docs.json

Documentation en une seule langue

Si vous ne souhaitez proposer qu’une seule langue sans sélecteur de langue, supprimez le champ languages de votre configuration de navigation. Définissez ensuite directement votre structure de navigation :
docs.json
Cela affiche votre documentation dans une seule langue, sans l’interface du sélecteur de langue.
Traduisez les libellés de navigation, comme les noms de groupes ou d’onglets, afin de les faire correspondre à la langue du contenu. Cela crée une expérience entièrement localisée pour vos utilisateurs.
Pour ajouter des éléments de navigation globaux qui apparaissent dans toutes les langues, configurez l’objet global dans la propriété navigation de votre fichier docs.json.
docs.json
Personnalisez le pied de page et la barre de navigation pour chaque langue afin d’afficher du contenu traduit et des liens adaptés à chaque région. Ajoutez les propriétés footer et navbar à chaque configuration de langue :
docs.json
Le footer et la navbar propres à une langue remplacent les paramètres globaux pour cette langue. Si une langue ne définit pas ces propriétés, elle hérite de la configuration globale. Vous pouvez également configurer une banner propre à une langue en suivant le même schéma.

Conserver les traductions

Veillez à ce que vos traductions restent exactes et synchronisées avec votre contenu source.

Processus de traduction

  1. Mettez à jour le contenu source dans votre langue principale.
  2. Identifiez le contenu modifié.
  3. Traduisez le contenu modifié.
  4. Relisez les traductions pour en vérifier l’exactitude.
  5. Mettez à jour les fichiers traduits.
  6. Vérifiez que la navigation et les liens fonctionnent.

Traductions automatisées

Pour des solutions de traduction automatique, configurez une automatisation pour exécuter l’agent selon un calendrier ou en réponse à des pushes vers le dépôt.

Prestataires de traduction externes

Si vous travaillez avec vos propres prestataires de traduction ou traducteurs régionaux, vous pouvez intégrer leur processus à votre documentation Mintlify à l’aide de GitHub Actions ou d’outils CI/CD similaires.
  1. Exporter le contenu source : extrayez les fichiers MDX à traduire.
  2. Envoyer aux traducteurs : transmettez les fichiers à votre prestataire de traduction.
  3. Recevoir les traductions : récupérez les fichiers MDX traduits.
  4. Importer et déployer : ajoutez les fichiers traduits aux répertoires de langue et mettez à jour la navigation.
Ce processus GitHub Actions exporte automatiquement le contenu anglais modifié pour traduction lorsque des PR sont fusionnées dans main.
.github/workflows/export-for-translation.yml
Ce processus GitHub Actions valide et importe le contenu traduit lorsqu’il est ajouté via une PR.
.github/workflows/import-translations.yml
Bonnes pratiques pour les processus de traduction externes
  • Préserver le frontmatter : assurez-vous que les traducteurs conservent le frontmatter YAML intact et ne traduisent que les valeurs de title et description.
  • Protéger les code blocks : indiquez à vos prestataires que les code blocks ne doivent pas être traduits.
  • Utiliser la mémoire de traduction : fournissez des glossaires contenant les termes techniques qui doivent rester en anglais ou avoir des traductions spécifiques.
  • Automatiser la validation : utilisez des vérifications CI pour valider la syntaxe MDX et le frontmatter avant d’intégrer les traductions.
  • Contrôle de version : suivez la version source de chaque traduction afin d’identifier le contenu obsolète.

Images et médias

Stockez les images traduites dans des répertoires propres à chaque langue.
Référencez les images à l’aide de chemins relatifs dans vos contenus traduits.
es/index.mdx

SEO pour les sites multilingues

Optimisez chaque version dans chaque langue pour les moteurs de recherche.

Metadata de la page

Incluez les metadata traduites dans le frontmatter de chaque fichier :
fr/index.mdx

Bonnes pratiques

Formats de date et de nombre

Tenez compte des formats propres à chaque langue pour les dates et les nombres.
  • Formats de date : MM/DD/YYYY (mois/jour/année) vs DD/MM/YYYY (jour/mois/année)
  • Formats de nombres : 1,000.00 vs 1.000,00
  • Symboles monétaires : $100.00 vs 100,00€
Incluez des exemples dans le format approprié pour chaque langue ou utilisez des formats universellement compréhensibles.

Maintenir la cohérence

  • Assurez une parité de contenu entre toutes les langues afin que chaque utilisateur bénéficie de la même qualité d’information.
  • Créez un glossaire de traduction pour les termes techniques.
  • Conservez la même structure de contenu dans toutes les langues.
  • Alignez le ton et le style sur ceux de votre contenu source.
  • Utilisez des branches Git pour gérer le travail de traduction séparément des mises à jour du contenu principal.

Différences de mise en page

Certaines langues nécessitent plus ou moins d’espace que l’anglais. Testez votre contenu traduit sur différentes tailles d’écran pour vous assurer que :
  • La navigation s’affiche correctement.
  • Les code blocks ne débordent pas.
  • Les tableaux et autres éléments de texte mis en forme restent lisibles.
  • Les images se redimensionnent correctement.

Encodage des caractères

Assurez-vous que votre environnement de développement et votre pipeline de déploiement prennent en charge l’UTF-8 afin d’afficher correctement tous les caractères dans les langues utilisant différents alphabets et caractères spéciaux.

Questions fréquemment posées

Non. Vous pouvez lancer une langue avec une couverture partielle et l’enrichir au fil du temps. Une approche courante consiste à traduire d’abord vos pages les plus visitées — généralement le contenu de prise en main, l’authentification et les principaux guides pratiques — et à laisser le contenu de référence moins fréquenté dans la langue par défaut jusqu’à ce que les traductions soient prêtes. Les utilisateurs préfèrent généralement un contenu partiellement traduit plutôt qu’aucune traduction.
Si un utilisateur accède à une URL traduite qui n’existe pas, il verra une erreur 404. Pour éviter cela, n’incluez que les pages traduites dans votre navigation spécifique à la langue ou maintenez la parité entre votre langue par défaut et le contenu traduit. Utiliser la même structure de fichiers dans toutes les langues facilite l’identification des traductions manquantes.
Oui. Les libellés de navigation — noms de groupes, titres d’onglets, textes d’ancrage — doivent correspondre à la langue du contenu. Un libellé « Getting started » en anglais dans une section de documentation en espagnol crée une expérience incohérente. Mintlify prend en charge les structures de navigation spécifiques à chaque langue, de sorte que chaque langue peut avoir des libellés entièrement traduits.
Ne traduisez pas le code lui-même — les noms de variables, les appels de fonctions et la syntaxe sont indépendants de la langue. Traduisez les commentaires dans les code blocks s’ils expliquent des concepts que les utilisateurs doivent comprendre. Traduisez entièrement les instructions entourant les code blocks.
Mintlify sert chaque version linguistique comme un ensemble distinct de pages statiques, donc un lecteur visitant /fr/quickstart ne charge que le contenu français de cette page — pas toutes les traductions. L’ajout de langues ne modifie ni le poids de la page ni les performances d’exécution pour les utilisateurs finaux.L’ajout de langues augmente cependant la taille de votre référentiel et le working set de votre build. Pour garder la rédaction et la CI rapides :
  • Stockez les images traduites dans des répertoires spécifiques à chaque langue afin que les locales inutilisées ne soient pas intégrées au contenu des autres locales.
  • Dans les référentiels plus volumineux, limitez mint broken-links et les autres vérifications CI aux fichiers modifiés plutôt qu’à l’ensemble de l’arborescence.