Le piège de la traduction : ce que la construction d'un site multilingue m'a appris sur le respect
Je pensais qu'ajouter cinq langues à mon portfolio serait un défi technique. Cela s'est avéré être une leçon d'empathie.
En grandissant au Brésil, j'ai appris l'anglais en regardant des séries américaines avec des sous-titres. Je me souviens des traductions maladroites. "Cool" devenait "legal." L'argot était aplati en portugais de manuel scolaire. Les mots étaient corrects. La sensation était fausse.
Vingt ans plus tard, j'ai créé un script de traduction pour mon portfolio. En moins d'une heure, il a converti "Next.js dashboard" en "painel do Next.js."
J'ai grimacé. Aucun développeur brésilien ne dit "painel." On dit simplement dashboard.
Je faisais la même chose que ces traducteurs de sous-titres. Convertir des mots au lieu d'adapter le sens.
Pourquoi c'est important
Les recherches montrent que 75% des internautes préfèrent le contenu dans leur langue maternelle, même quand ils comprennent l'anglais. Ce n'est pas une question de compréhension. C'est une question de confiance. La sensation de "ceci a été fait pour quelqu'un comme moi."
Pour un portfolio, cette sensation compte. Quand un responsable d'embauche à Tokyo arrive sur mon site, je veux qu'il évalue mon travail, pas qu'il traduise dans sa tête. Quand quelqu'un à Paris lit mes projets, je veux qu'il pense aux idées, pas à la langue.
Un portfolio uniquement en anglais envoie un message : "C'est pour les anglophones d'abord, tous les autres ensuite." Je voulais inverser ça.
Ce que la communauté de localisation m'a appris
Cette erreur de "dashboard" m'a envoyé dans le terrier de la localisation. J'ai lu des articles d'ingénieurs i18n, fouillé dans les discussions GitHub, et étudié comment les grandes entreprises tech gèrent la traduction.
Le pattern était cohérent dans toutes les sources.
Les audiences techniques partagent un vocabulaire qui traverse les frontières. Les développeurs brésiliens disent "data pipeline," pas "canalização de dados." Les ingénieurs japonais gardent "TypeScript" comme TypeScript. Les marketers français utilisent "growth marketing," pas l'équivalent du dictionnaire.
Ces termes ont été appris en anglais. Ils sont discutés en anglais. Les traduire crée de la confusion, pas de la clarté.
Mon script était trop minutieux. Il traduisait des choses qui devraient rester en anglais.
Traduction versus localisation
Cette distinction est devenue l'insight central du projet.
La traduction convertit les mots. La localisation adapte les expériences.
Un site traduit dit "painel de controle" parce que le dictionnaire le dit. Un site localisé dit "dashboard" parce que c'est ce que les développeurs brésiliens disent vraiment.
Un site traduit convertit chaque terme. Un site localisé sait quand s'arrêter. Un développeur au Japon a besoin de navigation en japonais mais s'attend à des termes techniques en anglais. Cet équilibre fait que le contenu semble natif plutôt que traduit.
J'ai réécrit mon approche. Les labels de navigation se traduisent. Les noms de produits restent en anglais. Les termes techniques restent en anglais. Le contenu explicatif se traduit naturellement.
Les règles que j'ai construites
Après avoir corrigé suffisamment d'erreurs, des patterns ont émergé. Je les ai documentés :
Garder en anglais : Les noms de produits comme Next.js, TypeScript, Claude. Les termes de l'industrie comme dashboard, data pipeline, growth marketing, e-commerce. Les sections de compétences et les noms de certifications.
Traduire : Les éléments de navigation, les labels de formulaires, le contenu narratif, les titres de sections.
Adaptations spécifiques par langue :
Pour le portugais, utiliser "dashboard" pas "painel," utiliser "template" pas "modelo." Les développeurs brésiliens ont appris ces termes en anglais et les utilisent quotidiennement.
Pour l'espagnol, utiliser "dashboard" pas "cuadros de mando," utiliser "marketers" pas "vendedores," utiliser "data pipelines" pas "canalizaciones de datos."
Pour le japonais, garder les noms de produits en anglais (Next.js, pas ネクストジェイエス). Le katakana fonctionne pour les emprunts courants comme ダッシュボード (dashboard).
Pour le français, utiliser "dashboard" pas "tableaux de bord," utiliser "marketers" pas "spécialistes du marketing."
Ces règles vivent maintenant dans la documentation de mon projet. Chaque fois que je traduis du contenu, je les vérifie.
Le déclic
La première fois que j'ai chargé mon site en japonais, quelque chose a changé.
Je ne parle pas japonais. Je ne peux pas le lire au-delà de quelques caractères. Mais c'était là : mon portfolio, mes projets, dans une langue que je ne connais pas.
La navigation disait "プロジェクト" (projets). Le corps du texte coulait en japonais. Mais "Next.js" restait "Next.js." "TypeScript" restait "TypeScript." L'équilibre semblait juste.
Du contenu écrit pour chaque audience, pas traduit vers eux. Cette distinction capture tout ce que j'ai appris.
Le coût de ne pas faire ça
La plupart des portfolios que je vois sont uniquement en anglais. C'est bien. L'anglais est la lingua franca de la tech.
Mais quand quelqu'un arrive sur ton site et doit faire un travail de traduction mentale, tu as ajouté de la friction. Ils peuvent partir plus vite. Ils peuvent comprendre moins. Ils peuvent faire moins confiance. Cette charge cognitive est invisible mais réelle.
Un site multilingue dit : "J'ai pensé à toi. J'ai fait ça pour toi. Ton contexte compte."
Dans un domaine où chaque portfolio tourne sur les mêmes frameworks et montre des projets similaires, cette considération se démarque.
La partie technique, brièvement
Le système utilise next-intl pour le routing et l'API de DeepL pour la traduction initiale. J'ai écrit des scripts qui traitent les fichiers MDX, préservent le frontmatter, et appliquent les règles de localisation. Tout le pipeline s'exécute en moins de 30 secondes.
Mais la traduction automatique n'est que la première étape. Après que DeepL génère la version initiale, je demande à Claude de réviser chaque traduction selon les meilleures pratiques de localisation. Claude identifie les termes qui doivent rester en anglais, corrige les formulations maladroites, et s'assure que le vocabulaire technique correspond à ce que les développeurs utilisent vraiment dans chaque langue.
Cette combinaison de vitesse et de qualité compte. Si la localisation prenait des heures de travail manuel, j'arrêterais de le faire.
Pour les détails techniques, voir la page du projet. Ce post parle du voyage.
Ce que j'ai appris
J'ai commencé en pensant à la portée. Plus de langues, plus de visiteurs, meilleur SEO. Ces choses sont vraies, mais ce n'est pas le point.
La vraie leçon était l'empathie. Construire pour une audience globale m'a forcé à penser à des gens dont je ne partage pas le contexte.
Pour le portugais, j'avais un avantage. Je suis locuteur natif. Je peux repérer les maladresses immédiatement. Pour le japonais et le français, j'ai dû me fier à ce que la communauté de localisation a documenté. Ce que les articles de blog et les guides de style disent sur la façon dont les audiences techniques communiquent vraiment.
Cette dépendance à la connaissance externe est humiliante. Tu ne peux pas supposer que tes paramètres par défaut sont universels. Tu dois rencontrer les gens là où ils sont.
Une invitation permanente
Les traductions sur ce site ne sont pas parfaites. La traduction automatique est un point de départ. Les locuteurs natifs captent des nuances que les algorithmes ratent.
Si tu lis quelque chose en portugais, espagnol, japonais ou français qui sonne faux, dis-le-moi via le formulaire de contact. Je l'apprécierais.
La localisation n'est jamais terminée. C'est une conversation continue entre celui qui construit et l'audience. Construire pour une audience globale signifie rester ouvert aux retours de personnes qui connaissent leur contexte mieux que tu ne le connaîtras jamais.