Nouveautés
L’interface parle anglais
La langue des menus appartient à la personne, la langue des contenus appartient au projet. On peut travailler en anglais et publier en français — ou l’inverse.
L’application était en français, écrit en dur dans les composants. Assumé : un outil monolingue, pour une équipe française. Puis il a fallu ouvrir, et une question est tombée tout de suite — laquelle des deux langues, exactement ? Celle des menus, ou celle des posts ?
Deux réglages, parce que ce sont deux choses
La langue de l’interface appartient à la personne. La langue des contenus appartient au projet.
La première se choisit dans votre compte : « Langue de l’interface », avec une précision utile juste en dessous — « Menus, messages et courriels. La langue des contenus générés se règle par projet. » Le choix est enregistré sur le compte, pas dans le navigateur : vous le retrouvez ailleurs, et les courriels que l’application vous envoie le suivent.
La seconde se règle dans les réglages du projet, « Langue des contenus », parmi trente-huit langues — les sept les plus courantes d’abord, puis les autres langues d’Europe. Son sous-titre est également sans ambiguïté : « Imposée à toutes les générations, quelle que soit la langue de l’interface. En changer ne traduit pas les contenus existants. »
Une agence peut donc travailler en anglais sur un projet qui publie en français, et sur un autre qui publie en espagnol, sans que les deux se contaminent.
Le texte français est la clé
La traduction obéit à une décision fondatrice : le texte français est lui-même l’identifiant. Il n’y a pas de catalogue français, parce qu’il n’y a pas de clé à inventer — rien d’abstrait à retrouver trois écrans plus loin pour savoir ce qui s’affiche. Ce qu’on écrit est ce qu’on lit.
Le catalogue anglais, lui, existe : vingt-trois fichiers, un par zone de l’application, où chaque texte français pointe vers sa traduction. Les pluriels ont leur fonction — le français met zéro et un au singulier, l’anglais non. Les textes ambigus portent un contexte : « Modifié » n’est pas la même chose dans l’historique d’un post et sur un badge de provenance.
Un test qui refuse de laisser passer
C’est la partie qui tient l’ensemble. À chaque pnpm test, un contrôle relit le code source, collecte tous les appels de traduction et exige : une traduction anglaise pour chacun, aucune entrée inutilisée dans le catalogue, les mêmes paramètres des deux côtés, aucun gabarit dynamique en guise de texte source, et aucune traduction contradictoire du même texte.
Concrètement : changer une phrase française sans toucher à sa traduction casse la construction. On ne peut pas oublier.
Anglais américain, jusqu’aux dates
Choisir « anglais », ce n’est pas seulement traduire des mots. Toutes les dates, heures et nombres passent par la locale : fr-FR d’un côté, en-US de l’autre. Donc le mois avant le jour, et une horloge sur douze heures. « jeu. 24 sept. · 12 h 30 » devient « Thu, Sep 24 · 12:30 PM ». C’est un choix, pris le 17 septembre 2026 : l’anglais du produit est américain, pas britannique.
Côté serveur, la langue se déduit dans l’ordre : le contexte de la requête, puis le compte, puis l’en-tête envoyé par l’application, puis celui du navigateur. Et une tâche planifiée qui écrit à toute une équipe écrit à chacun dans sa langue — un courriel de relance n’est pas traduit à la volée, il est composé une fois par destinataire.
La langue des contenus, imposée par le serveur
Le point le plus important est invisible. Les routes IA d’un projet ne font pas confiance à la langue envoyée par le navigateur : elles lisent celle du projet en base et l’imposent au brief, au document et au profil qu’elles reçoivent. Un onglet ouvert avant le changement, un post écrit il y a trois semaines, un profil de marque encore vide : tous repartent dans la bonne langue.
Ce qui est écrit pour vous, en revanche — la justification d’une génération, une relecture, un résumé de l’assistant — suit la langue de l’interface. L’IA vous parle dans votre langue et écrit vos posts dans celle du projet.
Et les handles, tant qu’on y est
Même famille de problème : le nom d’un compte n’est pas le même sur toutes les plateformes. Le profil de marque propose donc « Un handle pour toutes les plateformes » ou « Un handle par plateforme ». Dans le second cas, chaque post affiche le handle de sa plateforme, et une plateforme sans handle propre reprend celui par défaut.
Le handle n’est pas figé au moment où le post est créé : il est résolu à l’affichage, d’après la plateforme du post. Un post décliné vers LinkedIn affiche donc le handle LinkedIn, sur ses slides comme dans son export, sans qu’aucune opération n’ait eu à le remplacer.
