Portefeuille multilingue : Atteindre un public mondial

Pourquoi la langue est importante

Voici un chiffre qui a changé ma façon de voir le web : 75 % des internautes préfèrent acheter des produits dans leur langue maternelle. Même lorsqu'ils comprennent l'anglais, ils font davantage confiance aux contenus rédigés dans leur propre langue. Ils restent plus longtemps. Ils s'engagent plus profondément.

Pour un portfolio, cette idée a du poids. Un responsable du recrutement à São Paulo qui scanne mon travail ne devrait pas avoir à traduire mentalement lorsqu'il évalue mes compétences. Un collaborateur potentiel à Tokyo devrait avoir l'impression que le site a été construit en pensant à lui. La langue n'est pas seulement une question de compréhension. C'est une question de respect, de confiance et de sentiment d'appartenance.

Un portfolio uniquement en anglais envoie un message involontaire : "C'est pour les anglophones d'abord, pour tous les autres ensuite". Je voulais inverser cette tendance. Je voulais que les visiteurs brésiliens, espagnols, japonais et français atterrissent sur mon site et se disent : "Oh, cette personne a compris."

Traduction vs. localisation : Une distinction essentielle

Au début de ce projet, j'ai appris quelque chose qui échappe à la plupart des gens : la traduction et la localisation ne sont pas la même chose.

La traduction convertit des mots d'une langue à une autre. C'est mécanique. "Contactez-moi" devient "Contáctame" en espagnol. Fait.

Localisation adapte l'ensemble de l'expérience à une culture spécifique. Elle tient compte du contexte, des attentes et des conventions. Un site localisé ne se contente pas d'échanger des mots. Il donne l'impression d'être indigène.

Voici où cette distinction est importante dans la technologie : un développeur brésilien qui lit un article sur les "pipelines de données" s'attend à voir "data pipelines", et non "canalizações de dados". Le terme anglais est standard dans l'industrie. Le traduire donnerait l'impression d'être maladroit, voire condescendant. De même, "dashboard" reste "dashboard" parce que c'est ainsi que les développeurs de São Paulo, Tokyo et Paris l'appellent en réalité.

La localisation consiste à savoir quand il ne faut PAS traduire. Cela signifie comprendre que les lecteurs japonais s'attendent à "Next.js" et "TypeScript" en anglais, mais à des étiquettes de navigation en japonais. Cela signifie reconnaître qu'un spécialiste du marketing français utilise "growth marketing" dans la conversation, et non "marketing de croissance".

Cette intuition a façonné l'ensemble du système. Je ne construisais pas un outil de traduction. Je construisais un moteur de localisation qui utilise la traduction de façon stratégique.

Le défi

La localisation manuelle n'est pas évolutive. Embaucher des traducteurs pour chaque article de blog, chaque mise à jour de projet et chaque modification de l'interface utilisateur créerait un goulot d'étranglement. Pire encore, cela me ralentirait suffisamment pour que j'arrête complètement de publier en plusieurs langues. Le fardeau de la maintenance l'emporterait.

J'avais besoin d'un système doté de trois propriétés :

1. Vitesse. Les nouveaux contenus doivent être localisés en quelques minutes, pas en quelques jours.
2. Intelligence. Le système doit savoir ce qu'il faut traduire et ce qu'il faut conserver.
3. Résilience. Les traductions incomplètes ne doivent jamais interrompre le site.

La solution

L'architecture combine next-intl pour un routage tenant compte des paramètres locaux et l'API de traduction de DeepL pour une traduction automatique de haute qualité. Un pipeline de traduction personnalisé gère les nuances.

L'expérience du visiteur:

Lorsque quelqu'un arrive, le système détecte la langue de son navigateur. S'il est configuré en portugais, il voit /pt-BR/blog avec un contenu portugais. Les visiteurs japonais voient /ja/projects avec du texte japonais. La structure de l'URL est propre, lisible et adaptée aux moteurs de recherche.

Si une page spécifique n'a pas encore été traduite, les visiteurs voient la version anglaise au lieu d'une erreur. Ce repli se fait silencieusement. Pas de pages cassées, pas de messages "traduction à venir". Juste du contenu.

Le flux de travail du contenu:

J'écris tout une fois en anglais. Un script de traduction traite le contenu sur DeepL, applique des règles de localisation et génère des fichiers spécifiques à la région. L'ensemble du processus est exécuté en moins de 30 secondes.

Comment fonctionne le script de traduction

Le script traite à la fois les chaînes d'interface utilisateur (boutons, navigation, messages d'erreur) et le contenu long (articles de blog, descriptions de projets, page À propos). Il préserve la structure de la page d'accueil, maintient le formatage Markdown et ne touche pas aux blocs de code.

Le processus :

1. Lire les fichiers sources en anglais (MDX ou JSON)
2. Extraire le contenu traduisible tout en préservant la structure.
3. Envoyer le texte à DeepL API avec la langue cible
4. Appliquer les règles de localisation (préserver les termes techniques, les noms de produits).
5. Rédiger des fichiers spécifiques à la langue (par exemple, post.pt-BR.mdx)

Les règles de localisation en pratique

Le système suit des règles explicites sur ce qu'il faut traduire et ce qu'il faut préserver :

Toujours traduire :

• Les étiquettes de navigation et d'interface utilisateur
• Le contenu et les descriptions des articles
• Champs de formulaire et messages d'erreur
• Appels à l'action

Toujours conserver en anglais:

• Noms de produits : Next.js, TypeScript, DeepL, Cursor
• Noms d'entreprises : Nike, Meta, Rocket Internet
• Termes techniques : API, dashboard, data pipeline, template
• Exemples de code et chemins d'accès aux fichiers

Adaptations spécifiques aux langues:

• Portugais (Brésil) : "dashboard" et non "painel", "template" et non "modelo"
• Espagnol : "marketers" et non "vendedores", "data pipelines" et non "canalizaciones de datos".
• Japonais : Noms de produits en anglais, mots d'emprunt courants en katakana.
• Français : "dashboard" et non "tableaux de bord", CTAs naturels comme "Contactez-moi".

Ces règles produisent des traductions qui paraissent naturelles aux lecteurs avertis de chaque localité. Le contenu se lit comme s'il avait été écrit pour eux, et non traduit pour eux.

Résultats

Pour les visiteurs:

• Contenu disponible en 5 langues dès le premier jour
• Détection automatique de la langue en fonction des paramètres du navigateur
• Expérience cohérente sur toutes les pages et dans toutes les langues
• Pas d'impasses, de pages cassées ou de messages "contenu non disponible".

Pour les moteurs de recherche:

• URL uniques et indexables pour chaque langue (/en/blog, /ja/blog, /pt-BR/blog)
• Balises hreflang appropriées pour une indexation précise de la langue
• Meilleure visibilité dans les résultats de recherche locaux dans plusieurs pays

Pour une maintenance continue:

• Nouveau contenu localisé en moins de 30 secondes
• Une seule source de vérité en anglais
• Pas de gestion manuelle des fichiers par langue
• Publication en toute sécurité pendant que les traductions sont en cours

Ce que j'ai appris

La création de ce système m'a appris que la localisation est une décision liée au produit, et pas seulement une décision technique. Chaque choix de ce qu'il faut traduire (et de ce qu'il ne faut pas traduire) reflète une compréhension du public.

La plus grande leçon : respecte l'expertise de tes utilisateurs. Un développeur au Japon n'a pas besoin que "TypeScript" soit traduit en japonais. Il a besoin que le contenu qui l'entoure lui paraisse naturel dans sa langue. Trouver cet équilibre est la différence entre un site qui semble traduit et un site qui semble natif.

Ce portefeuille atteint désormais un public mondial sans avoir à gérer des bases de code distinctes pour chaque langue. Plus important encore, il montre aux visiteurs que leur langue et leur contexte comptent pour moi. Dans un domaine où tous les portfolios se ressemblent, c'est important.

Note sur les traductions

Les traductions de ce site sont générées à l'aide de l'API de DeepL, puis révisées et affinées en fonction des directives de localisation décrites ci-dessus. La traduction automatisée est un point de départ, pas un produit fini.

Si tu remarques quelque chose qui se lit mal dans ta langue ou si tu as des suggestions d'amélioration, je serais heureux de recevoir tes commentaires par le biais du formulaire de contact. La localisation est un processus continu, et les locuteurs natifs saisissent des nuances qui échappent à l'automatisation.