Foire aux questions

Non. Il fonctionne avec React et Next.js, React Native et Expo, Flutter, Angular, Vue et Nuxt, Svelte et SvelteKit, Astro, Solid, Qwik, Lit, Ember, Electron et Tauri, sites HTML simples, modèles Rails, Django et Laravel, mises en page Android, Jetpack Compose et code View, et applications iOS et macOS en SwiftUI et UIKit. Il configure la bibliothèque i18n correspondante pour chacun : react-i18next, ngx-translate, vue-i18n ou @nuxtjs/i18n, svelte-i18n, ember-intl, gen-l10n de Flutter, Rails I18n, gettext de Django, ressources de chaînes Android, ou un petit script pour les pages statiques.

Oui. localize-dev translate remplit les traductions manquantes dans les fichiers de locale que vous avez déjà, dans n'importe quelle pile : JSON (i18next, react-intl, vue-i18n, ngx-translate), Rails YAML, gettext .po, Flutter .arb, Android strings.xml, Apple String Catalogs et .strings, et messages d'extension de navigateur. Le code n'est pas touché, les traductions existantes ne sont pas modifiées, et en CI, il ouvre une pull request chaque fois que de nouvelles clés arrivent.

Seulement Node.js 22 ou plus récent pour exécuter la CLI : npx localize-dev l'exécute sans ajouter de package.json à votre projet. Ou sautez les exécutions locales et utilisez la GitHub Action, qui s'exécute sur les machines de GitHub.

Oui. localize-dev sync push télécharge vos fichiers de locale source et sync pull ramène le travail des traducteurs, afin que les traductions automatiques, la révision humaine et votre dépôt restent synchronisés.

Votre application continue de fonctionner. La sortie est la bibliothèque i18n que votre framework utilise déjà (react-i18next, vue-i18n, ngx-translate, Rails I18n, gettext, ressources de chaînes Android, catalogues de chaînes Apple…) avec des fichiers de langue simples dans votre dépôt. Il n'y a pas de runtime, de SDK ou de proxy localize.dev à supprimer.

Oui. Connectez le dépôt dans le tableau de bord et choisissez Ouvrir une demande d'extraction de prévisualisation : localize.dev localise la branche par défaut (jusqu'à 200 chaînes, une langue) et ouvre une demande d'extraction depuis localize-dev/preview. Aucun workflow, clé ou checkout requis.

Oui. npx localize-dev check (ou l'Action avec mode: check) échoue lorsqu'un changement ajoute du texte codé en dur, qu'une langue manque de traductions, ou que l'anglais a été modifié et ses traductions non refaites, chaque problème étant annoté sur la demande d'extraction. Il s'exécute sur votre machine ou votre runner, sans clé API.

Oui. Un choix comme n === 1 ? "fichier" : "fichiers" devient un message pluriel, et chaque langue obtient les formes dont elle a besoin : polonais quatre, arabe six, japonais un. Une phrase avec deux comptes ("3 fichiers dans 2 dossiers") obtient un pluriel par compte, et les ordinaux tels que 1er, 2e et 3e deviennent des ordinaux pluriels dans les formes propres à chaque langue, dans React, Next.js, Vue, Svelte, Astro, Ember, Angular et les autres frameworks JavaScript. Flutter, Rails, Django, Laravel, Android et iOS obtiennent des pluriels dans leurs propres formats (ARB, YAML, msgid_plural, trans_choice, <plurals>, variations de catalogue de chaînes) ; leurs bibliothèques n'ont pas d'ordinaux.

Il est retraduit. localize.lock.json conserve une empreinte de chaque message source, de sorte qu'un message modifié est refait dans chaque langue lors de la prochaine exécution ou demande d'extraction, et localize-dev check échoue tant qu'une traduction est obsolète. Les clés que le code n'utilise plus sont signalées, et localize-dev prune les supprime.

Oui. Le contenu de localize-dev traduit les fichiers Markdown et MDX en une copie par langue (intro.es.md ou les dossiers i18n de Docusaurus), en conservant les blocs de code, les liens, les importations MDX et les composants exactement tels qu'ils sont écrits. Seuls les documents modifiés depuis leur dernière traduction sont renvoyés.

Oui. Exécutez-le depuis la racine avec --workspaces, ou définissez workspaces: true dans la GitHub Action, et chaque application sera localisée avec ses propres fichiers de langue, en une seule pull request. Les bibliothèques partagées sans script de développement ou de démarrage sont laissées intactes. Pour localiser une seule app, définissez plutôt working_directory: apps/web dans l'Action.

Dans Next.js, SvelteKit et Nuxt, les pages sont rendues dans la langue du visiteur sur le serveur. Pour les sites HTML statiques, activez htmlPages et localize.dev écrira une copie traduite de chaque page par langue, liée avec hreflang, afin que chaque langue puisse être indexée.

Seules les chaînes en cours de traduction sont envoyées à l'API localize.dev, avec leur chemin de fichier et leur emplacement (le composant et l'élément tel qu'un bouton ou un titre) comme contexte. Les fichiers entiers ne sont jamais envoyés. La réécriture se fait localement (ou sur votre propre exécuteur CI), et les analyses et les exécutions hors ligne ne touchent jamais le réseau.

Non. La traduction s'exécute sur le modèle hébergé de localize.dev pour tous les plans, y compris le plan Gratuit. Créez une clé d'API, exécutez localize-dev login, et c'est terminé.

Non. Si votre application n'en a pas encore, la pull request en ajoute une appropriée (fichier de verrouillage inclus), crée un module qui charge chaque fichier de langue et choisit la langue, et l'intègre à votre fichier d'entrée. Les langues de droite à gauche définissent également la direction de la page. Les applications qui utilisent déjà i18next, vue-i18n ou svelte-i18n conservent leur propre configuration.

Les appels t(), et $_() existants sont laissés tels quels, et les clés déjà présentes dans en.json sont réutilisées lorsque le texte correspond (pour les textes courts comme "Post", lorsque les traductions correspondent également). Il est sûr de fonctionner sur du code semi-localisé.

Il traduit avec le contexte. Chaque chaîne atteint le modèle avec son fichier, son composant et son élément, ainsi "Post" sur un bouton devient "Veröffentlichen" en allemand et "Post" comme titre de carte devient "Beitrag", chacun avec sa propre clé ; les copies identiques ne partagent une clé que lorsque leurs traductions concordent. Votre glossaire et vos notes de style maintiennent la cohérence des termes du produit et du ton, y compris un "vous" formel ou informel par langue, et les pluriels obtiennent toutes les formes dont chaque langue a besoin. Les catalogues Laravel et Django sont indexés par le texte anglais lui-même, de sorte qu'un texte y a une traduction.

Le fichier de workflow ci-dessus et un secret de dépôt, LOCALIZEDEV_API_KEY. Il utilise le GITHUB_TOKEN intégré avec un accès en écriture aux contenus et aux pull requests, maintient une pull request par branche à jour au lieu d'en ouvrir une nouvelle à chaque push, et ignore ses propres branches et les pull requests des forks, dont le token est en lecture seule.

Ils constituent une première ébauche solide avec des espaces réservés corrects et des clés cohérentes. Pour les textes réglementés ou critiques pour la marque, assignez un réviseur par langue : ils reçoivent un e-mail lorsqu'une exécution se termine, approuvent ou corrigent chaque traduction dans l'onglet Révision, et les corrections sont intégrées à la pull request ouverte et à chaque exécution ultérieure. Les corrections récurrentes deviennent des termes du glossaire en un clic. Le modèle signale également les traductions dont il n'est pas sûr, avec sa raison, afin que les réviseurs commencent par celles-ci.

Un élément unique de copie d'interface utilisateur envoyé pour traduction. Une chaîne compte une fois, peu importe dans combien de langues elle est traduite. Traduire « Passer la commande » en 10 langues utilise 1, pas 10. La copie qui a déjà une clé n'est jamais renvoyée.

L'exécution s'arrête avant d'écrire quoi que ce soit et vous indique pourquoi, de sorte que votre code ne soit jamais réécrit à moitié. Mettez à niveau, ou attendez que la limite soit réinitialisée à la fin de votre période de 30 jours, et exécutez à nouveau. Le tableau de bord affiche la date.

Non. Les analyses et les exécutions --offline fonctionnent entièrement sur votre machine et n'appellent jamais l'API. Vous n'avez pas du tout besoin de clé pour elles.

Non. L'Action fonctionne sur tous les plans, y compris Gratuit. Ajoutez votre clé d'API comme secret de dépôt et elle ouvrira une pull request à chaque push, dans la limite de 3/5/illimité langues de votre plan.

Oui. Le terrain de jeu exécute le même moteur sur un composant ou une page que vous collez (React, Vue, Svelte, Angular, Astro, Flutter, Rails, Django, Laravel, Android, iOS ou HTML), aucun compte requis.

Supprime votre espace de travail personnel dans Tableau de bord → Paramètres. Cela supprime votre compte : votre connexion, vos liens GitHub et Google, vos membres d'équipe, et vous serez déconnecté sur tous les appareils. Si vous possédez des espaces de travail d'équipe, supprimez-les d'abord. Les chaînes utilisées durant cette période comptent toujours si vous vous inscrivez à nouveau avec le même e-mail.

Oui. Envoyez un e-mail à support@uselocalize.dev depuis l'adresse associée à votre compte, et nous vous l'enverrons. La Politique de Confidentialité indique ce que nous conservons.

Envoyez un e-mail à support@uselocalize.dev avec ce que vous avez exécuté et ce que vous avez vu. Pour les problèmes de sécurité, veuillez envoyer un e-mail plutôt que de publier les détails publiquement.