Des tables de traduction pour localiser votre jeu, vérifiées avant la sortie.
Une ligne par clé, avec un contexte et une longueur maximale pour vos traducteurs, et une colonne par langue. Chaque traduction porte son état, les textes trop longs ou qui perdent une variable sont signalés pendant la saisie, et la table s’exporte en CSV, JSON, .po et XLIFF pour Unity, Unreal et Godot.
La table de traduction vit dans le projet
Transformez n’importe quel tableur en table de traduction, ou partez d’une table prête. Nodary déduit le rôle des colonnes de vos en-têtes, comme Key, Context, Max length, English, ou keys, en, fr à la manière de Godot, et ajoute une langue en nouvelle colonne d’un clic. La table est un document sur la même carte que les dialogues, les personnages et les systèmes d’où viennent ses textes, et se relie à eux comme n’importe quel document.
- Tapez / puis String table, ou transformez un tableur existant
- Le rôle des colonnes deviné d’après les en-têtes, puis vérifié par vous
- Coédition cellule par cellule : deux relecteurs sur des cellules différentes ne s’écrasent jamais
- Les langues qui s’écrivent de droite à gauche, comme l’arabe et l’hébreu, saisies dans ce sens
Ce que ça ne fait pas Les répliques des dialogues n’arrivent pas seules dans la table : les clés se tapent, se collent, s’importent d’un tableur ou sont ajoutées par un agent. Une table contient au plus 50 000 cellules ; un gros jeu répartit donc ses textes sur plusieurs tables.
Chaque traduction a un état et un contrôle
Une traduction est manquante, en brouillon, relue, validée, ou en « source modifiée » dès que son texte source change après coup. Rien n’est réécrit quand la source change : chaque traduction garde l’empreinte du texte pour lequel elle a été faite. Pendant la saisie, Nodary signale un texte plus long que sa limite en caractères vus par le joueur, une variable perdue ou ajoutée, un texte laissé dans la langue source et des espaces en trop au début ou à la fin.
- La progression de chaque langue, filtrée sur ce qui reste à traiter ou pose problème
- Un panneau du traducteur : source, contexte, compteur de caractères et variables à garder
- Marquer une sélection relue ou validée, ou garder les états après un changement mineur de la source
- Les variables reconnues aux formats ICU, i18next, Unity, Unreal et printf, et les balises
Ce que ça ne fait pas Pas de mémoire de traduction, pas de base terminologique, pas de traduction automatique intégrée. Les traductions viennent de vos traducteurs, ou d’un agent IA à qui vous les demandez, et le travail d’un agent arrive en brouillon.
- Contexte
- Banner when a storm forms. {seconds} counts down
- Texte source (Anglais)
- Storm in
{seconds}s. Get to the stilts.À garder{seconds}
38 caractères sur 44
- Variables : manque {seconds}
[Šţóŕɱ íñ {seconds} š. Ĝéţ ţó ţĥé šţíĺţš. ~~~~~~~~~~~~]Des fichiers pour les moteurs et les traducteurs, et un flux pour votre build
Exportez un CSV avec toutes les langues pour Godot et Unity, du JSON pour i18next et les moteurs, du gettext .po avec la clé en contexte pour Unreal et Godot, et du XLIFF 1.2 pour les outils de traduction, qui porte l’état, la limite et le contexte de chaque texte. Une langue pseudo-localisée montre dans votre interface le texte non traduit ou coupé avant toute traduction. Et quand un build ne doit attendre personne, il va chercher la table lui-même à une adresse stable, avec une clé de données en lecture seule.
- Import XLIFF 1.2 ou 2.0, .po, JSON ou CSV, retrouvé par clé, avec un aperçu
- Une traduction vide dans un fichier n’efface jamais celle de la table
- Une langue en JSON, .po ou XLIFF, ou toutes en CSV ; final=1 ne garde que les textes validés
- Une table inchangée répond 304, jusqu’à 120 requêtes par minute et par clé
Ce que ça ne fait pas Les pluriels s’écrivent en messages ICU dans une seule cellule : les entrées plurielles d’un fichier .po sont écartées à l’import. Le flux ne fait que lire ; rien n’est réécrit dans Nodary par son biais.
Les agents remplissent la table sans la réécrire
Connecté par MCP, un agent lit la table avec get_localization : la progression de chaque langue et les textes qui restent à traiter, avec leur contexte, leur limite et leurs problèmes. set_translations écrit par clé, en brouillon sauf si vous lui demandez de valider, ajoute des clés ou une colonne de langue, et dit quels textes sont trop longs ou ont perdu une variable. Les personnes qui travaillent dans la table au même moment gardent leurs cellules.
Connecter un agentVous demandezComplétez en brouillon les textes allemands manquants de la table de traduction de Saltmarrow. Gardez toutes les variables, respectez chaque longueur maximale et dites-moi lesquels posent encore problème.
search_documentsget_localizationset_translations
Questions
Comment exporter les textes d’un jeu vers Unity, Unreal ou Godot ?
Ouvrez le menu Exporter de la table. Le CSV porte toutes les langues, une colonne de clés puis une colonne par langue, comme les lisent Godot et Unity ; le gettext .po porte une langue avec la clé en contexte, pour Unreal et Godot ; le JSON donne une langue en fichier plat clé-texte pour i18next et les moteurs. L’import se fait ensuite dans votre moteur, avec ses propres outils de localisation.
Nodary traduit-il les textes à ma place ?
Non. Il n’y a ni mémoire de traduction ni service de traduction automatique intégré. Vos traducteurs travaillent dans la table, ou dans leur propre outil grâce au XLIFF, et un agent IA que vous connectez peut aussi écrire des traductions, qui arrivent en brouillon pour qu’une personne les relise.
Que devient une traduction quand le texte source change ?
Chaque traduction garde l’empreinte de la source pour laquelle elle a été écrite. Quand la source change, ses traductions passent en « source modifiée » et rien n’est réécrit. Si la modification est mineure, « Changement de source mineur » garde leur état tel quel.
Notre build peut-il récupérer les textes tout seul ?
Oui. Chaque membre peut créer dans son profil une clé de données en lecture seule, pour tout l’espace ou un seul projet, et le bouton Flux de données de la table en donne les adresses. Un build récupère une langue en JSON, .po ou XLIFF, ou toutes en CSV, et final=1 écarte tout ce qui n’est pas encore validé.
Quelles variables et balises le contrôle reconnaît-il ?
Les messages ICU, pluriels et sélections compris, {name} et {0} tels que les écrivent Unity et Unreal, {{name}} d’i18next, les formes printf comme %s, %d et %1$s, et les balises comme <b> ou <color=#f00>. La longueur compte les caractères que voit le joueur : une lettre accentuée ou un emoji compte pour un, et les balises ne comptent pas.
Les traducteurs peuvent-ils renvoyer leurs fichiers ?
Oui. Importez du XLIFF 1.2 ou 2.0, du gettext .po, du JSON ou du CSV, jusqu’à 8 Mo. Les traductions sont retrouvées par clé, les clés absentes de la table sont listées sans être ajoutées, un aperçu montre chaque changement avant de l’appliquer, et une traduction faite d’après une source plus ancienne arrive en « source modifiée ».
Mettez vos textes à côté de votre jeu.
Commencez gratuitement, tapez / puis String table, et collez vos premières clés. Sans carte bancaire, rien à installer.
Gratuit pour deux membres et dix documents. Sans carte bancaire.