Journal des modifications

Ce qui a été livré et ce qui suit.

Prochainement Feuille de route

  • Captures d'écran en cours de revue

    Voyez où une chaîne apparaît dans l'application tout en examinant sa traduction.

  1. v0.33.4

    11 novembre 2026

    Astro : texte dans les constantes frontmatter et icônes omises du texte du bouton

    • Astro : le texte conservé dans les constantes frontmatter, comme les métadonnées d'une page ou une liste de cartes (const items = [{ title, description }]), devient t() là où il est écrit. Les listes dans les listes et les littéraux de modèle avec des valeurs sont inclus. Une constante que le frontmatter lit pour son texte est laissée telle quelle
    • Une icône avant ou après le texte d'un bouton, comme un chevron <svg>, reste en dehors du message, de sorte que le texte est traduit seul au lieu d'être dans un <Trans> avec l'icône à l'intérieur
  2. v0.33.3

    11 novembre 2026

    Un serveur MCP hébergé, avec connexion OAuth

    • Un serveur MCP hébergé sur https://uselocalize.dev/api/mcp, pour les agents qui ne peuvent pas exécuter npx. Il dispose des mêmes outils. Chaque appel transporte les fichiers dont l'outil a besoin et récupère les fichiers à écrire ; ils sont conservés dans un dossier temporaire pour cet appel et supprimés lorsqu'il répond
    • Les clients qui prennent en charge la connexion MCP se connectent avec OAuth : vous approuvez la connexion sur localize.dev et choisissez l'espace de travail. La connexion apparaît sous Clés API, et la suppression de la clé la déconnecte. D'autres envoient une clé API sous forme de jeton d'authentification ou dans un en-tête x-api-key
    • La page MCP contient la configuration pour Lovable, Bolt et v0, et le serveur est également dans le Registre MCP en tant que serveur distant
    • Le package exporte handleRemoteMessage et REMOTE_TOOLS, les outils du serveur hébergé, pour exécuter le même serveur ailleurs
  3. v0.33.2

    10 novembre 2026

    Plugins pour Claude Code et Cursor, et une inscription au registre MCP

    • Un plugin Claude Code ajoute le serveur MCP et une compétence qui indique à Claude quand localiser. Installez-le avec claude plugin marketplace add ufortstephen/localize-dev, puis claude plugin install localize-dev@uselocalize
    • Le même plugin fonctionne dans Cursor, avec une règle pour les applications qui ont un fichier localize.config.json
    • Le serveur MCP est répertorié dans le registre MCP sous le nom io.github.ufortstephen/localize-dev, afin que les clients qui lisent le registre puissent le trouver et l'installer
  4. v0.33.1

    10 novembre 2026

    Projets Create React App, Compose Multiplatform et XcodeGen

    • Les projets React, React Native et Solid qui conservent JSX dans les fichiers .js, comme le fait Create React App, font également analyser ces fichiers. Auparavant, seuls les fichiers .tsx et .jsx étaient analysés, sauf si include listait des fichiers .js
    • check signale les traductions manquantes dans les String Catalogs, strings.xml et les fichiers ARB quand le projet n'a pas de fichier source JSON. Avant, il ne le faisait que pour les catalogues .po de Django et indiquait que tout le reste était traduit
    • Les projets qui génèrent leur projet Xcode avec XcodeGen (project.yml) ou Tuist (Project.swift) sont détectés comme des applications iOS
    • Les chaînes Compose Multiplatform dans composeResources/values/ sont trouvées et traduites de la même manière que celles d'Android res/values/
    • Les fichiers dans les dossiers __tests__ et __mocks__ sont ignorés par défaut, comme les fichiers .test et .spec
  5. v0.33.0

    10 novembre 2026

    localize-dev seo, Remix et langues chargées sur le serveur

    • localize-dev seo <url> vérifie ce que les moteurs de recherche voient de chaque langue sur un site en direct ou une build locale : le sitemap, les liens hreflang qui pointent en arrière et incluent x-default, <html lang>, l'adresse canonique et og:locale
    • Les applications Remix 2 avec v3_routeConfig obtiennent une adresse par langue, de la même manière que les applications React Router.
    • Les applications React Router et Remix avec plus de trois langues chargent chaque langue dans le chargeur de la route, de sorte que le serveur affiche /fr/about en français même lorsque le français n'est pas dans le bundle. Les adresses hreflang complètes proviennent de la requête, donc siteUrl n'est pas nécessaire.
    • Sans siteUrl, l'adresse du site provient d'un fichier CNAME ou de la page d'accueil dans package.json, et sur Netlify, Render et Railway de l'adresse que l'hôte donne à la build, comme c'était déjà le cas sur Vercel.
    • Les pages Qwik City obtiennent <html lang> et dir pour la langue de leur adresse, définis dans entry.ssr.tsx.
    • Lorsque les langues se chargent à la demande, le menu des langues les liste toutes, pas seulement celles qui ont été chargées jusqu'à présent.
    • check ne signale plus les noms de classe ou les clés dans les exemples de code écrits sous forme de chaînes, les éléments centrés (left-1/2 avec -translate-x-1/2) comme des problèmes de droite à gauche, ou les polices dont les sous-ensembles couvrent le script.
  6. v0.32.1

    10 novembre 2026

    Django, ERB et Blade : balises de modèle entre les attributs

    • Une balise de modèle entre les attributs d'une balise, telle qu'un bloc if qui ajoute aria-current, ne fait plus que la vérification signale le reste de la balise comme du texte. Un titre ou une étiquette aria-label à l'intérieur du bloc est trouvé et traduit
    • Un lien rejoint le message d'une phrase uniquement lorsque des mots se trouvent juste à côté. Auparavant, un séparateur tel que · ou du texte ailleurs dans le bloc transformait un lien isolé en message
    • Les options sans attribut de valeur sont laissées seules, car leur texte est ce que le formulaire soumet
    • vérifie les rapports d'entrées vides et floues dans les catalogues .po d'un projet Django lorsqu'il n'a pas de catalogue anglais, ce qui est la configuration de la plupart des projets Django. Auparavant, il indiquait que tout était traduit
    • doNotTranslate dans localize.config.json répertorie les noms et abréviations à conserver tels quels, tels que Metron ou TPB. Le texte composé uniquement de ceux-ci, de chiffres et de symboles n'est ni extrait ni signalé par la vérification
  7. v0.32.0

    10 novembre 2026

    Une adresse par langue dans React Router

    • Les applications React Router (mode framework) obtiennent une adresse par langue (/es/about). routes.ts passe ses routes via withLanguageRoutes, qui ajoute une copie de chacune sous chaque langue, donc aucun fichier de route ne change
    • Le serveur rend chaque page dans la langue de son adresse, avec des liens hreflang, une adresse canonique et og:locale. Le menu de langue ouvre la même page dans la nouvelle langue, et les liens sans langue conservent la langue de la page
    • Une route sitemap.xml construite à partir des routes de l'application, de sorte que les nouvelles pages soient listées sans exécution, et une route robots.txt, lorsque l'application n'en a aucune
    • Le module i18n se trouve dans app/ et est importé depuis app/root.tsx. Auparavant, la configuration ne pouvait pas trouver le fichier d'entrée d'une application React Router
    • la vérification ne s'arrête plus avec une erreur sur une liste de classes qui a une variante sans classe après, comme cn(active && 'hover:', 'ml-2')
  8. v0.31.0

    10 novembre 2026

    SvelteKit 3, Qwik City et chaque langue sur les sites statiques SvelteKit

    • SvelteKit 3 fonctionne : il n'a pas de $lib, donc les fichiers générés importent depuis #lib lorsque l'application le déclare. Une mise en page racine avec des props typés, comme l'écrit npx sv create, est également configurée.
    • Dans SvelteKit, les liens vers les pages de l'application conservent la langue de la page sur laquelle ils se trouvent, ainsi /es/about pointe vers /es/ plutôt que /.
    • Les builds statiques de SvelteKit (adapter-static) écrivent les pages de chaque langue : le build s'exécute à l'adresse indiquée dans siteUrl, il les trouve donc via les liens hreflang.
    • Les applications Qwik City obtiennent un composant LanguageHead dans root.tsx avec des liens hreflang et og:locale, une route sitemap.xml et une route robots.txt lorsque l'application n'en a aucune.
    • Le sitemap Astro utilise les mêmes adresses que les pages (/about/ dans un build statique), il correspond donc à leurs liens canoniques.
  9. v0.30.0

    10 novembre 2026

    Un sitemap pour les sites statiques

    • Les sites HTML statiques avec htmlPages et siteUrl obtiennent un sitemap.xml qui liste chaque page, celles traduites dans chaque langue avec des liens hreflang entre elles. Il est réécrit à chaque exécution, mais un sitemap que le site possède déjà est conservé tel quel
    • Un robots.txt qui pointe vers le sitemap, lorsque le site n'en a pas
    • Deux formulations sur le site allemand, issues d'une revue de ses traductions
  10. v0.29.0

    10 novembre 2026

    Chaque langue dans les résultats de recherche, pour Astro et SvelteKit

    • Les applications SvelteKit obtiennent une adresse par langue (/es/about) via un hook de réacheminement, de sorte que les routes n'ont pas besoin de dossier [lang]. Chaque page obtient des liens hreflang, une adresse canonique et og:locale, et le menu de langue accède à la même page dans la nouvelle langue. Cela nécessite SvelteKit 2.3 ou une version ultérieure
    • Les mises en page Astro obtiennent un composant I18nHead dans leur <head>, avec des liens hreflang, une adresse canonique et og:locale pour la page
    • Les deux obtiennent un sitemap.xml qui liste chaque page dans chaque langue. Il est construit à partir du dossier pages ou routes, de sorte que les nouvelles pages apparaissent sans relancer localize. Un robots.txt est ajouté lorsque l'application n'en a aucun
  11. v0.28.0

    10 novembre 2026

    Chaque langue dans les résultats de recherche

    • Les applications Next.js App Router obtiennent une adresse canonique et og:locale pour l'URL de chaque langue, ajoutées via generateMetadata dans la mise en page racine. Les propres métadonnées d'une mise en page sont conservées et leurs valeurs l'emportent
    • Un sitemap.ts qui liste chaque page avec une adresse fixe dans chaque langue, avec des alternatives hreflang, et un robots.ts qui y pointe. Ils sont écrits uniquement lorsque l'application n'en a aucun des deux, et vous pouvez les modifier
    • Les moteurs de recherche ont besoin d'adresses complètes : elles proviennent de siteUrl dans localize.config.json, ou de VERCEL_PROJECT_PRODUCTION_URL sur Vercel
    • Les applications configurées auparavant obtiennent tout cela lors de leur prochaine exécution
  12. v0.27.0

    9 novembre 2026

    Localisez au fur et à mesure de l'écriture

    • init --agent configure les agents de codage : le serveur MCP pour Claude Code et Cursor, un hook après édition qui indique à Claude Code quel texte il a laissé non traduit dans le fichier qu'il vient d'éditer, et des instructions dans AGENTS.md et une règle Cursor.
    • check et run prennent --files, --changed et --staged, donc vérifier les fichiers que vous avez touchés prend environ une seconde ; init --agent --pre-commit ajoute cette vérification au hook git.
    • Le serveur MCP demande aux agents de localiser les fichiers qu'ils modifient, et son outil de vérification prend des chemins.
    • La page d'utilisation indique où les chaînes ont été traduites : pendant l'écriture, en CI ou depuis la CLI.
  13. v0.26.6

    9 novembre 2026

    Les corrections faites dans la pull request restent

    • Quand la branche de base avance et que la pull request est reconstruite, les modifications qu'on y a faites sont conservées. Les fichiers de langue sont fusionnés clé par clé, et une traduction modifiée des deux côtés garde la version de la personne
    • Un fichier que la nouvelle proposition a aussi modifié prend la version de la proposition, et l'exécution nomme ces fichiers pour que la modification puisse être refaite
    • Le site écrit les nombres et les prix comme chaque langue : 10.000 en allemand, 10 000 en français
  14. v0.26.5

    4 novembre 2026

    De droite à gauche dès le premier rendu dans les applications Next.js

    • Les apps Next.js reçoivent <html dir> selon la langue : l'arabe, l'hébreu et le persan s'affichent de droite à gauche dès le premier affichage ; les apps déjà installées le reçoivent à leur prochaine exécution
    • Une langue dont le code est aussi un mot juste après une liste (it, no) y est quand même ajoutée, et le mot reste tel quel
  15. v0.26.4

    4 novembre 2026

    Les langues dont le code est aussi un mot

    • Une nouvelle langue rejoint chaque liste générée qui ne l'a pas, même si son code est un mot ailleurs dans le fichier (it pour l'italien, no pour le norvégien)
    • Le site : l'arabe se lit de droite à gauche dès le premier chargement, et l'en-tête et ses menus suivent le sens de lecture
  16. v0.26.3

    4 novembre 2026

    Les nouvelles langues arrivent dans le menu des langues de l'app

    • Une langue ajoutée après l'installation rejoint les listes générées par localize.dev : le menu des langues, le routage, les imports et les tables du sélecteur, avec son nom, son drapeau et son sens d'écriture
    • Astro et Qwik reçoivent la copie de chaque page pour la nouvelle langue, et Django son fichier .po
  17. v0.26.2

    4 novembre 2026

    Choisissez les langues au lancement

    • Lancer maintenant demande dans quelles langues traduire : une langue ajoutée rejoint le projet, est traduite dans cette exécution et ajoutée à localize.config.json dans sa pull request
    • Chaque exécution de l’Action traduit dans les langues du projet sur le tableau de bord : une langue ajoutée là n’exige plus de modifier le workflow
  18. v0.26.1

    3 novembre 2026

    Langues cibles comptées sur tout le compte

    • Les langues cibles d'un forfait sont comptées sur tous ses espaces de travail : toute langue vers laquelle vous avez traduit au cours des 30 derniers jours ou définie sur un projet. Une exécution qui dépasserait la limite s'arrête avant d'écrire quoi que ce soit et indique les langues utilisées
    • localize-dev whoami indique combien de langues cibles du forfait sont utilisées, et lesquelles
  19. v0.26.0

    3 novembre 2026

    Un serveur MCP pour les agents de codage et les traductions revues sur la pull request

    • localize-dev mcp : un serveur MCP pour les agents de codage tels que Claude Code, Cursor, Codex et GitHub Copilot, avec les outils check, localize, translate, add_language et config
    • L'outil de configuration inclut le glossaire du projet lorsqu'une clé API est définie, afin que l'agent conserve les noms et les termes tels que décidés par l'équipe
    • Les pull requests reçoivent un commentaire avec un tableau des nouvelles traductions, publié par l'application GitHub, ou par l'Action lorsque le dépôt n'utilise pas l'application
    • Les traductions modifiées dans la pull request avant sa fusion sont apprises pour les prochaines exécutions, dans tous les formats de locale et pour les pluriels, et marquées comme Modifiées sur GitHub dans la revue
  20. v0.25.0

    3 novembre 2026

    Des sélecteurs de langue pour tous les frameworks

    • La configuration ajoute un menu de langues et useLanguage() aux applications Vue, Nuxt, Svelte, Solid, Qwik, Angular, Astro, Lit et Ember, à côté du module i18n qu'elle génère
    • Rails, Django et Laravel reçoivent un menu de langues pour leurs templates qui mémorise le choix ; Flutter, iOS, Android et React Native, un menu natif
    • localize-dev/switcher : le menu sous forme d'élément personnalisé, stylé avec les mêmes variables CSS que celui de React
    • La configuration automatique ne télécharge plus le dépôt : elle aboutit donc aussi sur les grands monorepos
  21. v0.24.6

    3 novembre 2026

    Configuration automatique et Action, pour les apps d'un monorepo

    • La configuration automatique trouve l'app dans un monorepo (le dossier avec un localize.config.json) et y exécute le workflow avec working_directory
    • À la racine d'un monorepo, l'Action indique le working_directory à définir pour chaque app, au lieu de commandes cd
  22. v0.24.5

    3 novembre 2026

    Des pull requests ouvertes par la GitHub App localize.dev, et les fichiers ignorés laissés tels quels

    • La GitHub App localize.dev ouvre les pull requests de l'Action dans les dépôts connectés : aucun réglage de permissions de workflow à cocher, et les checks des pull requests s'exécutent
    • Le texte d'un module ignoré par la configuration reste tel quel, même quand un composant le lit
  23. v0.24.4

    3 novembre 2026

    Une app dans un monorepo : working_directory dans l'Action

    • Monorepos : working_directory dans l'Action localise une seule app (apps/web), et sa pull request modifie les fichiers sur place
    • mode: check dans un répertoire de travail annote chaque problème avec son chemin depuis la racine du dépôt, pour qu'il apparaisse dans le diff
  24. v0.24.3

    31 octobre 2026

    Un paquet plus facile à auditer : aucun code évalué, des fichiers lisibles et des installations sans scripts

    • Les Plural-Forms de gettext sont lus par un petit analyseur de leur propre grammaire au lieu d’être évalués comme du code
    • Le paquet npm n’est pas minifié : ce qui est publié se lit comme le code source
    • Les compilateurs de templates sont des dépendances peer optionnelles ; installés à la première utilisation sans exécuter de scripts de paquets, ou jamais avec LOCALIZE_DEV_NO_INSTALL=1
  25. v0.24.2

    31 octobre 2026

    Des mises à jour qui restent vertes : anciennes entrées lock de Vue, dépôts ne contenant que des fichiers de langue, locks de monorepos et pull requests de traduction plus claires

    • Mise à jour : les pluriels à barre de Vue et Nuxt dans un fichier lock écrit par 0.23.0 sont considérés à jour, donc check reste vert et aucune pull request ne réécrit le lock
    • check (CLI et Action) dans un dépôt qui ne contient que des fichiers de langue vérifie leurs traductions au lieu d’échouer faute de dossier src/
    • Monorepos : la première exécution de run --workspaces enregistre les messages des bibliothèques partagées dans le lock de chaque app, et la deuxième ne change plus rien
    • Une pull request qui ne fait que compléter des traductions porte un titre adapté (fill in 3 translation(s)) et liste les messages par langue
    • translate redemande un pluriel revenu sans ses formes, au lieu de laisser la langue à l’exécution suivante
  26. v0.24.1

    31 octobre 2026

    Corrections de l’Action issues de la CI : Astro, les projets à la racine du dépôt et les sites statiques ouvrent leur pull request, une exécution ne peut plus rester bloquée, et les pluriels à barre de Vue sont remplis

    • React : i18next est configuré même quand l’exécution l’importe elle-même pour les dates et les nombres, et l’app affiche ses textes au lieu des clés
    • Monorepos : check et prune comptent les clés qu’utilisent les bibliothèques du workspace d’une app, et prune --workspaces couvre chaque app et bibliothèque
    • Action : les projets dont le code est à la racine du dépôt ouvrent leur pull request (chemins sans ./), les pages Astro sont réécrites (le compilateur WASM est livré avec l’Action), et un site statique sans configuration est analysé à sa racine, comme avec la CLI
    • Action : une exécution s’arrête et échoue après timeout_minutes (30 par défaut) au lieu de rester bloquée, et un fichier dont l’analyseur ne se charge pas fait échouer l’exécution au lieu d’être ignoré
    • Vue : run remplit les pluriels à barre (only {count} copy left | …) avec toutes les formes dont la langue a besoin, et run, translate et check s’accordent sur ce qui manque ou n’est plus à jour
  27. v0.24.0

    29 octobre 2026

    Des deuxièmes exécutions qui ne changent rien, aucune requête sans nouveaux textes, et un check pour les workflows hors ligne

    • Une deuxième exécution ne reprend que les nouveaux textes : les tris et les dates des scripts Vue suivent la langue de l’app dès la première exécution, les messages %@ d’un String Catalog ne bloquent plus une exécution iOS, et les pages statiques pseudo-localisées ne sont plus analysées à nouveau
    • Aucune requête de traduction sans rien à traduire : les textes qui ont déjà leur clé et toutes leurs traductions sont ignorés, et les exécutions hors ligne indiquent qu’elles ne créent que des clés
    • Le titre et le résumé de la pull request disent ce qu’elle change, comme les dates et les nombres qui suivent désormais la langue de l’app, sans tableaux vides
    • check et prune considèrent comme utilisés le titre et la description de page que définit le module i18n généré, dans tous les frameworks
    • Action : check_only: strings ne vérifie que les textes en dur, pour les workflows qui localisent hors ligne
    • Flutter : n == 0 ? 'Rien à arroser' : '$n plantes à arroser' devient un seul message pluriel avec =0, et le texte construit avec + est listé et fait échouer check au lieu d’être ignoré
    • Les traductions sont vérifiées comme la bibliothèque i18n de l’app les lit avant d’être écrites : mêmes variables, aucune accolade en trop, toutes les formes du pluriel, un ICU valide. Une traduction invalide est redemandée, puis écartée et signalée
    • check ignore les appels à t() dans les commentaires, dans tous les langages, et les fichiers générés ne montrent plus d’exemples ressemblant à des clés ; les nouveaux catalogues gettext ont l’en-tête standard
  28. v0.23.0

    29 octobre 2026

    Rails, Django et Laravel : les phrases avec des liens restent entières, et les bibliothèques d’un monorepo compilent avec pnpm

    • Rails : une expression placée dans un argument de t() reçoit les parenthèses dont Ruby a besoin (link_to(book.title, book_path(book.id))), donc les vues compilent
    • Rails : un message qui interpole un lien ou un autre HTML reçoit une clé _html, donc le lien s’affiche au lieu d’être échappé
    • Un lien dans une phrase reste dans son message : link_to en Rails, un seul blocktranslate en Django (le {% url %} capturé avant) et {!! __() !!} avec des valeurs échappées en Laravel
    • Monorepos : une bibliothèque de composants déclare ce qu’importe son code réécrit (react-i18next) en dépendance peer et de développement, et ses fichiers deviennent des composants client quand une app Next.js les affiche
    • Ember : @glimmer/tracking et @ember/test-helpers, dont ember-intl a besoin sans les déclarer, sont ajoutés quand l’app ne les a pas
  29. v0.22.0

    29 octobre 2026

    Des apps qui compilent après la localisation : liens Svelte intacts, modules Angular avec le bon pipe, code SvelteKit qui passe la vérification de types

    • Les modèles Svelte et Vue sont maintenant analysés, de sorte qu'un espace réservé ${ … } à l'intérieur d'un attribut n'est jamais confondu avec un prix, et les attributs d'URL (href, src, action) n'en reçoivent jamais un
    • Angular : les NgModules et les composants standalone importent le pipe de traduction de la version installée de ngx-translate (TranslatePipe à partir de la 16), et un TranslateModule laissé par une exécution précédente avec ngx-translate 18 est réparé
    • SvelteKit : le code généré passe la vérification de types ; les dates prennent $locale ?? undefined, I18nT.svelte a des props typées et le layout racine suit la langue après une navigation, sans avertissement
    • package.json garde sa mise en forme : les nouvelles dépendances suivent le style des lignes voisines au lieu de réécrire tout le fichier
  30. v0.21.0

    29 octobre 2026

    Chaque requête SvelteKit dans sa propre langue, des phrases Astro entières et les numéros de version comme valeurs

    • SvelteKit affiche et traduit chaque requête dans sa propre langue : le hook la note dans event.locals, les messages du serveur la reçoivent, et rien côté serveur ne lit la langue partagée de svelte-i18n
    • Les phrases Astro autour de liens et de texte en gras restent un seul message, affiché avec les éléments de la page
    • Les numéros de version et de build dans les textes sont des valeurs, Version {version} (build {build}), pour qu’une nouvelle version ne rende pas toutes les traductions obsolètes
    • check liste une seule fois ce que run ne peut pas traduire, sous un seul avertissement
  31. v0.20.0

    29 octobre 2026

    Messages du code, descriptions de page et messages du serveur traduits partout, et rien n’est ignoré sans le dire

    • Le texte que run ne peut pas traduire est toujours listé et fait échouer check : le texte d’une fonction utilitaire dans un module, les listes de phrases et les éléments hors composants dans Solid et Qwik
    • alert, confirm, document.title et les notifications sont traduits dans Lit, Angular, Ember, React Native (Alert.alert et ses boutons), le Java d’Android et les scripts d’un site statique
    • Les descriptions de page et les titres pour les réseaux dans <meta> sont traduits avec le titre de la page dans tous les frameworks, tout comme useHead et useSeoMeta de Nuxt
    • Les messages de fail() et error() de SvelteKit et de useActionState de Next sont traduits
    • Les tables Angular lues avec computed(), les valeurs initiales de @state dans Lit et le texte lu par index (quotes[i].text) sont traduits
    • check repère le texte et les styles gauche/droite dans css`` de Lit et dans styled-components
  32. v0.19.0

    29 octobre 2026

    Les head des routes Qwik, les constantes transmises à d’autres composants, et un check qui repère ce que run ignore

    • Les head des routes Qwik City sont traduits : export const head devient une fonction de l’URL de la page, avec son titre et sa description dans la langue de cette page
    • Les constantes de textes transmises telles quelles (useState(TASKS), data={TASKS}) sont construites avec t() dans le seul composant qui les lit, en gardant leur type
    • Les constantes qui ne peuvent pas être déplacées, parce qu’elles sont comparées dans le code, sont une dépendance d’un effet ou sont lues par deux composants, sont signalées avec la raison
    • check échoue sur les textes que run a dû ignorer, avec la raison donnée par run ; la syntaxe de modèle et les autres omissions volontaires passent toujours
    • Les listes de classes avec des utilitaires d’un seul mot (border border-outline), les chemins de fichiers et les listes indexées par code de langue ne comptent plus comme du texte
  33. v0.18.0

    29 octobre 2026

    Les textes de tout champ qu’un composant affiche, les titres de page via des fonctions utilitaires, et une URL par langue à côté de votre propre proxy

    • Tout champ qu’un composant affiche compte comme texte, pas seulement label et title (ROWS.map(({ task, manual }) => …)) ; jamais les id, liens et slugs
    • Une liste aussi interrogée avec length, findIndex, some ou includes est quand même suivie, tant que ces lectures ne touchent pas ses textes
    • Les titres de page définis via un helper, export const metadata = pageMetadata({ title: … }), sont également traduits
    • Les éléments conservés en dehors des composants dans les fichiers client sont traduits avec <Trans>, qui n'a pas besoin de hook
    • Les applications avec leur propre proxy.ts obtiennent i18n-proxy.ts : un appel là-bas donne à chaque page une URL par langue
    • Les listes de classes Tailwind ne sont plus signalées comme du texte non traduit
  34. v0.17.0

    29 octobre 2026

    Pages Astro trouvées dans leur intégralité, blocs de modèles laissés intacts et vérification dans un monorepo

    • Astro : le texte après une lettre accentuée ou une apostrophe typographique est trouvé, ainsi que chaque page dont la <head> contient un <title>
    • Les mises en page Astro importent le module i18n une fois, avec t et la langue de la page depuis une seule ligne
    • Les commentaires Django, les blocs verbatim et blocktranslate, ainsi que les blocs @verbatim et @php de Blade, restent tels quels, donc une seconde exécution ne change rien
    • Les éléments Vue avec v-pre restent tels quels
    • check ne signale plus de texte traduit sur place : un titre index.html, du texte SwiftUI dans le catalogue de chaînes et blocktranslate Django
    • check --workspaces (et le mode de l'Action : check avec workspaces: true) vérifie chaque application dans un monorepo
    • Les paquets Monorepo sans interface utilisateur, comme un serveur API ou un paquet d'utilitaires, sont ignorés
  35. v0.16.0

    29 octobre 2026

    Composants serveur repérés par leurs imports, et textes déjà dans une autre langue laissés tels quels

    • Next.js : les composants en dehors de app/ se rendent comme leurs importateurs ; ceux réservés au serveur attendent le traducteur, et ceux que les deux côtés importent deviennent des composants client
    • Les applications Next.js qui installent également Svelte ou Vue sont détectées comme React, et avec Cache Components, la mise en page racine se rend par requête
    • Le <code> en ligne reste à l'intérieur de sa phrase, de sorte que la phrase est un message que les traducteurs peuvent réorganiser
    • Le texte marqué lang="…" dans une autre langue, et les listes avec une entrée par langue, restent tels qu'écrits
    • <Trans> donne à vos propres composants un enfant substitut typé, de sorte que les composants avec des enfants requis vérifient les types
    • La copie importée via des alias tsconfig comme @/lib/nav est suivie
    • translate conserve `inline code` tel quel, remplit les formes plurielles qu'une exécution antérieure a omises, et indique quand une langue revient vide
    • Les clés ne se terminent jamais comme une forme plurielle, et la vérification signale les formes plurielles manquantes pour une langue
  36. v0.15.0

    28 octobre 2026

    La copie qui passait auparavant, les titres de page et ce qui se passe après la fusion

    • Les langues régionales sont choisies dans le navigateur et Accept-Language : pt-PT atteint le pt-BR de l'application, zh-cn son zh-CN
    • Les métadonnées Next.js deviennent generateMetadata avec le traducteur de la requête ; le titre et la description de index.html d'une SPA suivent la langue
    • Monorepos : les bibliothèques de composants sont traduites avec les applications qui les utilisent, leurs messages étant fusionnés dans les fichiers de langue de ces applications
    • pluralize(word, count) du package pluralize est un pluriel ; les listes séparées par des virgules et « a, b et c » deviennent Intl.ListFormat
    • la vérification échoue sur les clés manquantes dans le fichier de langue, et signale le texte en CSS et les valeurs stockées tels quels
    • Valeur ARIA, texte de rôle et de description, titres SVG dans le HTML statique et la disposition de droite à gauche de React Native
    • Texte qui passait auparavant inaperçu : props de composants comme l'en-tête et la description, tables de correspondance, fonctions d'aide et texte importé de modules comme nav.ts
    • Les dates de date-fns, dayjs et moment suivent la langue de l'application, tout comme localeCompare et la casse majuscule/minuscule
    • Après la fusion : les tests chargent l'i18n dans leur fichier de configuration, les applications React multilingues chargent les fichiers de langue à la demande et les fichiers de langue fusionnent clé par clé
    • Remix et React Router s'hydratent sans problème ; vérifiez que les polices des drapeaux ne manquent pas de lettres de la langue cible
  37. v0.14.0

    28 octobre 2026

    Pluriels dans chaque framework, d'Angular à iOS

    • Pluriels dans Angular (un pipe pluralForm généré), Django (pluralize to blocktranslate count), Laravel (trans_choice), Android (<plurals>) et iOS (variations de String Catalog)
    • Deux comptages dans une phrase et des ordinaux dans Vue, Svelte, Astro, Lit, Ember et Angular ; deux comptages dans Flutter, Rails, Laravel et Android
    • Vue et Svelte : ce que les valeurs calculées et les fonctions retournent est traduit, et les listes passées aux composants enfants sont traduites
    • Composants de classe : le texte avant le return dans render(), les constructeurs et les méthodes statiques sont traduits
    • Pug : les balises inline à l'intérieur de balises inline deviennent des messages imbriqués
    • L'Action GitHub scanne le propre dossier de chaque framework (app/views, resources/views…) au lieu de toujours src/
  38. v0.13.0

    28 octobre 2026

    iOS, documentation Markdown, copie modifiée retraduite et la copie qui passait auparavant

    • iOS et macOS : la copie SwiftUI et UIKit va dans Localizable.xcstrings avec chaque langue ; les affectations UIKit deviennent String(localized:)
    • Le code de vue Android en Kotlin et Java (setText, label.text =) utilise des ressources de chaîne, comme les layouts et Compose
    • localize-dev traduit le contenu Markdown et MDX en une version par langue, en conservant le code, les liens et le MDX tels quels
    • Le texte modifié est ret traduit : localize.lock.json se souvient de chaque message source, et la vérification échoue si les traductions sont obsolètes
    • Les clés inutilisées sont signalées, et localize-dev prune les supprime
    • Le texte dans les constantes lues par les composants, les chaînes concaténées, les messages de setters, les notifications et alertes, ainsi que les messages de validation de zod/yup sont extraits
    • Les phrases genrées deviennent un message avec une variante par genre
    • Langues de droite à gauche : le contrôle signale les styles gauche/droite, et localize-dev rtl --fix échange les sûrs par les logiques
    • Les dates, nombres et prix suivent la langue de l'application dans les composants Vue et Svelte aussi ; plus de symboles de devise, et un paramètre pour un dollar nu
    • Les composants de classe React sont traduits via withTranslation(), et le titre propre d'un lien reste dans sa phrase
    • Les demandes pull en prévisualisation couvrent chaque application dans un monorepo et laissent les fichiers Git LFS intacts
    • Les templates Vue écrits en Pug sont traduits : texte des balises, pipé et blocs, ainsi que les attributs
    • Angular avant la version 14 conserve les phrases autour des liens intactes et les composants NgModule reçoivent le pipe translate via leur module
    • Une phrase avec deux nombres obtient un pluriel par phrase comptée, et les ordinaux (1er, 2e, 3e place) deviennent des pluriels selon les formes propres à chaque langue
    • Vue et Svelte: les constantes affichées dans le template (un titre, une liste d’onglets dans v-for ou #each) deviennent des clés, lues via ou $_()
    • Toute composante React en classe est traduite : <Translation> autour de render() quand elle n’est pas l’exportation par défaut
    • Un lien dont le titre est défini en code reste dans sa phrase ; les balises Pug #[inline] et #{values} sont traduites
  39. v0.12.0

    28 octobre 2026

    Aperçu sur votre dépôt, une vérification CI, la pseudo-localisation, et les dates et l'argent

    • Aperçu de pull request : connectez un dépôt et localize.dev localise sa branche par défaut sur le serveur (jusqu’à 200 chaînes) et ouvre une pull request sans workflow, clé ou checkout
    • localize-dev check (et le mode de l’Action : check) échoue en CI si le texte est codé en dur ou si des traductions manquent, avec des annotations sur la pull request
    • --pseudo génère un pseudo-langage en-XA (ou ar-XB, écriture de droite à gauche) pour repérer le texte tronqué ou codé en dur avant la traduction ; gratuit, aussi disponible dans le playground
    • Les dates, nombres et prix codés en dur pour une seule langue (toLocaleDateString('en-US'), formatteurs Intl, `$${price}`) suivent la langue de l’app dans React, React Native et Solid
    • Le modèle signale les traductions dont il n’est pas sûr, avec sa raison ; l’onglet 'Réviser' s’ouvre pour celles-ci et 'Approuver' laisse le reste pour une personne
    • Une URL par langue pour les moteurs de recherche : Next.js obtient un proxy servant /es/… avec des liens hreflang, Nuxt prefix_except_default avec useLocaleHead
    • Un calculateur de prix par rapport aux agences de traduction
  40. v0.11.0

    28 octobre 2026

    Svelte et Angular plus anciens, formatage imbriqué et contexte de code dans la revue

    • Svelte 3 et 4 et Angular 14+ gardent également les phrases autour des liens entières, grâce à des composants générés qui n'ont pas besoin de nouvelles fonctionnalités
    • La mise en forme à l'intérieur d'un lien (texte en gras dans un lien, jusqu'à trois niveaux de profondeur) devient un message imbriqué dans Vue, Svelte, Angular et Ember
    • Onglet d'examen : Dans le code, affiche les lignes autour de l'endroit où chaque chaîne est utilisée, lues à partir de la pull request de l'exécution
    • Le terrain de jeu montre le composant généré à travers lequel un fichier localisé rend ses phrases
    • Les messages Ember du terrain de jeu et des guides utilisent des espaces réservés ICU, comme la CLI
    • Phrase et Lokalise apparaissent avec leurs propres logos
  41. v0.10.0

    28 octobre 2026

    Les phrases avec des liens restent entières partout, et les routes dynamiques Astro

    • Svelte 5, Angular 17+, Ember, Solid et Qwik conservent une phrase autour d'un lien ou d'un texte en gras comme un seul message, rendu par un composant généré (ou rich() dans Solid et Qwik), afin que les traducteurs puissent déplacer le lien
    • Rails : un link_to à l'intérieur d'une phrase devient un message _html avec le lien interpolé ; le texte de link_to, button_to, submit et label est traduit
    • Astro: les routes dynamiques reçoivent aussi une copie par langue, conservant leurs getStaticPaths et props
    • Laravel: un middleware SetLocale choisit la langue (?locale=, un cookie lang, puis Accept-Language), enregistré dans bootstrap/app.php ou le noyau HTTP
    • Django: les packages de configuration (settings/base.py) sont trouvés, et LocaleMiddleware est ajouté même sans SessionMiddleware
    • Le playground accepte les fichiers Rails, Django, Laravel et Android, et affiche les fichiers de localisation propres à chacun
    • Les chaînes manquantes une langue (ou des formes pluriels) sont demandées à nouveau avant de tomber en arrière-plan
    • Nécessite Node.js 22 ou ultérieur; les projets sans package.json (Rails, Django, Laravel, Android, Flutter) s'exécutent via npx
  42. v0.9.0

    28 octobre 2026

    Rails, Django, Laravel, Android, Astro, Qwik, Lit, Ember et revue de traduction

    • Astro: les templates .astro deviennent des appels à t() lisant la langue depuis l'URL, avec une copie de chaque page statique par langue et <html lang dir> défini dans les mises en page
    • Les îles Astro (React, Vue, Svelte) sont localisées avec leurs pages, chacune suivant la langue de la page
    • Qwik: useTranslation() lit la langue depuis l'URL, avec une route par langue; Lit: templates html`` vers t() avec un contrôleur qui re-rend en cas de changement de langue
    • Ember: Modèles Glimmer (.hbs, .gjs/.gts) vers ember-intl’s {{t}}, avec des pluriels depuis {{if (eq n 1) …}} et une route d’application qui choisit la langue
    • Onglet de révision sur chaque projet : approuvez ou modifiez les traductions automatiques, formes plurielles incluses ; les modifications alimentent la mémoire de traduction et peuvent être validées dans la pull request ouverte
    • Notes de révision pour le prochain réviseur, qui a approuvé quoi et quand, et suggestions de glossaire issues des corrections que vous continuez d'apporter
    • Texte enrichi imbriqué : les phrases autour des liens contenant du texte en gras et similaire restent un seul message
    • Plus de modèles de pluriel : n > 1, Intl.PluralRules select(), et helpers plural(n, one, other)
    • Synchronisation Lokalise et Transifex ; GitHub Action : tms_pull apporte les traductions révisées dans la pull request, tms_push télécharge les fichiers source depuis la branche par défaut
    • Le terrain de jeu accepte les fichiers Astro
    • Rails : les vues ERB deviennent des appels t() avec config/locales YAML et count : pluriels ; les locales disponibles et un sélecteur de locale sont configurés
    • Django : les templates obtiennent les balises translate et blocktranslate, les catalogues .po sont remplis et LocaleMiddleware est activé
    • Laravel : les vues Blade deviennent des appels __() avec lang/<locale>.json indexées par le texte
    • Android : les layouts et Jetpack Compose sont déplacés vers strings.xml (stringResource, placeholders %1$s), avec la liste des langues par application
    • Vue : les phrases autour des liens et du texte en gras restent un seul message, via <i18n-t>
    • Qwik : les routes dynamiques reçoivent également une copie par langue
    • Les exécutions de la CLI (pr et pr --translate) atteignent l'onglet Révision, comme celles de l'Action
    • Réviseurs par langue, contactés par e-mail une fois par exécution lorsque les traductions arrivent ; chaque ligne de l'onglet Révision renvoie à son fichier source
    • Une installation plus petite : les compilateurs Vue, Svelte, Angular, Astro et Ember sont récupérés la première fois qu'un projet en a besoin
    • Guides par framework, avec des sorties réelles avant et après
  43. v0.8.0

    27 octobre 2026

    Angular, Flutter, Solid, et synchronisation Crowdin et Phrase

    • Angular : les templates et les templates inline deviennent le pipe ngx-translate, avec la gestion du flux de contrôle, des liaisons et des attributs aria ; provideI18n() et TranslatePipe sont intégrés
    • Flutter : les arguments de type Text() et hintText deviennent des recherches AppLocalizations avec des fichiers ARB, des pluriels ICU et des métadonnées de placeholder ; const est supprimé si nécessaire, et gen-l10n est configuré
    • Solid : JSX avec useTranslation() d'un module i18next généré dont la langue est un signal
    • localize-dev sync push et pull : fichiers source vers Crowdin ou Phrase, traductions retour dans vos fichiers de locale
    • Le terrain de jeu prend des modèles Angular (.component.html) et des fichiers Dart
  44. v0.7.0

    27 octobre 2026

    Vue, Svelte, HTML statique, React Native et fichiers de langue existants

    • localize-dev translate (et le mode de l'Action : translate) remplit les traductions manquantes dans les fichiers de locale existants : JSON, Rails YAML, gettext .po, Flutter .arb, Android strings.xml, Apple .xcstrings et .strings, extension messages.json
    • translate conserve les correspondances ICU =0 et les branches select, et crée de nouvelles langues gettext avec leurs propres règles de pluriel
    • Composants Vue monofichiers : le texte et les attributs du modèle deviennent des appels , avec vue-i18n configuré et installé
    • Svelte et SvelteKit : le balisage devient des appels $_() avec svelte-i18n, initialisé à partir de +layout ou main
    • Sites HTML statiques : marqueurs data-i18n et un i18n.js généré qui charge les fichiers de locale, avec un menu de langue optionnel
    • React Native et Expo : étiquettes d'accessibilité traduites, et une configuration i18n qui s'exécute sans API de navigateur
    • Le framework est détecté automatiquement ; remplacez-le par "framework" dans localize.config.json
    • Pluriels dans Vue (format pipe avec les règles de chaque langue) et Svelte (ICU) ; messages affichés depuis les scripts, comme les toasts et les alertes
    • Les pages SvelteKit sont rendues dans la langue du visiteur sur le serveur ; Nuxt obtient @nuxtjs/i18n ; les configurations existantes de vue-i18n et svelte-i18n sont conservées
    • HTML : les phrases avec des liens et du texte en gras restent entières, les pages fonctionnent à partir du disque, et htmlPages écrit une copie traduite par langue pour les moteurs de recherche
    • Les langues de droite à gauche définissent dir sur <html> partout ; le texte du moteur de modèles et le PHP sont laissés seuls
    • Monorepos : --workspaces localise chaque application (l'Action met à jour le fichier lockfile racine)
  45. v0.6.0

    27 octobre 2026

    Un menu de langue approprié et useLanguage()

    • localize-dev/react : un menu linguistique convivial pour le clavier et le lecteur d'écran, avec drapeaux et noms natifs
    • Personnalisez la liste, les noms, les drapeaux, la mise en page et les styles, ou remplacez des parties par des render props
    • useLanguage() renvoie la langue actuelle, son drapeau, son nom et sa direction, la liste et setLanguage()
    • Les langues de droite à gauche définissent dir sur <html> ; les sélecteurs <select> générés sont mis à niveau automatiquement
  46. v0.5.0

    27 octobre 2026

    Sélecteur de langue

    • Un <LanguageSwitcher /> généré liste chaque langue incluse dans son propre nom
    • Mémorise le choix (localStorage, ou le cookie de langue dans Next.js pour que les composants serveur suivent)
    • Les projets configurés par une version antérieure l'obtiennent lors de leur prochaine exécution, dans une pull request propre
  47. v0.4.0

    27 octobre 2026

    Pluriels, texte enrichi, composants serveur Next.js, équipes

    • Messages pluriels : une clé avec exactement les formes CLDR dont chaque langue a besoin
    • Le texte autour des liens et du formatage devient un message <Trans> que les traducteurs peuvent réorganiser
    • Next.js App Router : les composants serveur utilisent un traducteur attendu ; les composants client partagent la langue de la requête
    • Glossaire du projet : termes à ne jamais traduire, traductions préférées et une note de style
    • Espaces de travail d'équipe avec invitations et un sélecteur d'espace de travail
    • Facturation avec Stripe et e-mails d'utilisation à 80 % et 100 %
  48. v0.3.0

    26 octobre 2026

    Statistiques du projet et historique d'exécution

    • Les pages du projet affichent les chaînes traduites et remplacées, les exécutions et les traductions par langue
    • L'action GitHub signale chaque exécution : pull request, chaînes remplacées, traductions ou l'erreur
    • L'utilisation est attribuée au dépôt dont elle provient
    • Configuration étape par étape des clés d'API et des autorisations de pull request, liée aux paramètres de votre dépôt
  49. v0.2.0

    26 octobre 2026

    Fonctionne sur les applications sans i18n

    • Ajoute i18next et react-i18next lorsqu'ils sont manquants, avec le fichier de verrouillage mis à jour dans l'Action
    • Crée src/i18n.ts qui charge chaque fichier de langue et l'importe depuis votre fichier d'entrée
    • Active resolveJsonModule dans tsconfig.json et correspond à votre style de guillemets
    • Laisse les configurations i18next existantes intactes
  50. v0.1.0

    26 octobre 2026

    Première publication publique

    • Analyseur AST pour le texte JSX, les attributs autorisés et les littéraux de modèle rendus en JSX
    • Transformateur à différence minimale qui ajoute useTranslation une fois par composant
    • Modèle de traduction hébergé sur chaque plan, avec des clés API, des allocations mensuelles et un niveau gratuit
    • Nommage sémantique des clés et traduction en une seule passe, avec des vérifications de placeholders avant que quoi que ce soit ne soit écrit
    • CLI : commandes init, login, whoami, scan, run et pr, plus le mode hors ligne
    • Action GitHub qui maintient à jour une branche et une pull request par branche de base
    • Terrain de jeu web qui exécute le même moteur que la CLI