# General Translation Knowledge Base: General Translation ou Mobility : lequel choisir ? URL: https://generaltranslation.com/fr/kb/general-translation-vs-mobility.mdx Docs index: https://generaltranslation.com/llms.txt Description: Mobility stocke les attributs traduits de vos modèles dans votre base de données. General Translation produit ces traductions via son API, en s’appuyant sur votre glossaire et vos instructions personnalisées. Utilisez les deux pour traduire vos fiches produits, articles et autres contenus de base de données sans renoncer à vos modèles Rails. Category: Internationalisation Last updated: 2026-10-16 Authors: Kevin Wu, Jackie Chen Published: 2026-10-16 Mobility est une gem Ruby qui sert à traduire les données de votre base : vous déclarez `translates :title` sur un modèle, et `post.title` renvoie le titre dans le paramètre régional courant, lu depuis le backend de stockage de votre choix. Elle stocke et récupère les traductions, mais leur rédaction incombe à vos rédacteurs, à vos traducteurs ou à un service tiers. General Translation les fournit via son API HTTP. Mobility conserve les attributs traduits dans votre base de données existante, prêts à être exploités avec les requêtes et méthodes de modèle que vous utilisez déjà. ## Les points forts de Mobility * **Plusieurs options de stockage.** Le backend `key_value` par défaut [conserve toutes les traductions dans deux tables partagées](https://github.com/shioyama/mobility/wiki/KeyValue-Backend) (l'une pour les chaînes, l'autre pour le texte). Le backend `table` utilise une table de traduction par modèle (l'approche de Globalize), `column` utilise des colonnes suffixées comme `title_en` et `title_es`, `serialized` les regroupe dans une seule colonne de texte, et sur PostgreSQL, `json`, `jsonb`, `hstore` et `container` (une colonne jsonb par modèle) les stockent nativement. Vous pouvez également écrire votre propre backend. * **Une seule API pour tous les backends.** Les lectures et écritures suivent `I18n.locale`, et les plugins (solutions de repli, accesseurs par paramètre régional comme `post.title_es`, suivi des modifications, mise en cache et vérifications de présence) [fonctionnent de la même manière quel que soit le backend choisi](https://github.com/shioyama/mobility#backends). * **Requêtes.** [`Post.i18n.where(title: "...")`](https://github.com/shioyama/mobility#querying) génère les jointures pour le paramètre régional courant : vous pouvez ainsi effectuer des recherches dans les attributs traduits sans savoir comment ils sont stockés. * **Prise en charge des ORM.** Mobility [fonctionne avec Active Record 7.0 et versions ultérieures ainsi qu'avec Sequel](https://github.com/shioyama/mobility#installation), et son wiki propose un guide de migration depuis Globalize. * **Gratuit.** Mobility est distribué sous licence MIT ; la [version actuelle est la 1.3.2](https://rubygems.org/gems/mobility). ## Ce que Mobility vous laisse gérer Voici un article dont le titre et le contenu sont en anglais, qui utilise le backend `key_value` sur SQLite, avec un contenu de secours de l'espagnol vers l'anglais pour le titre uniquement : ```ruby title="app/models/post.rb" class Post < ApplicationRecord extend Mobility translates :title, type: :string, fallbacks: { es: :en } translates :body, type: :text end ``` ```ruby post = Post.create!(title: "Spring sale", body: "Everything is 20% off this week.") I18n.with_locale(:es) { post.title } # => "Spring sale" (en anglais, via le contenu de secours) I18n.with_locale(:es) { post.body } # => nil I18n.with_locale(:ja) { post.title } # => nil ``` C'est le comportement attendu d'une couche de stockage : Mobility a enregistré les valeurs en anglais, et tous les autres paramètres régionaux restent vides jusqu'à ce que quelqu'un les renseigne. Avec un contenu de secours, les lecteurs hispanophones voient l'anglais ; sans contenu de secours, ils ne voient rien. Pour du contenu qui évolue chaque jour, comme des fiches produits, des articles ou des pages d'aide, quelqu'un doit traduire chaque enregistrement nouveau ou modifié dans chaque langue, puis l'enregistrer sous le bon paramètre régional. ## Remplir les attributs Mobility avec General Translation L'endpoint de traduction à l’exécution de General Translation, `POST https://api.gtx.dev/v2/translate`, traduit des chaînes à la demande. Il attend, en guise de jeton bearer, une clé API de projet disposant de l’autorisation **traduction à l’exécution**, ainsi qu’un corps comprenant un objet `requests` indexé par vos propres identifiants (chaque entrée contenant une chaîne de caractères `source` et, de façon facultative, des `metadata` telles qu’une note `context`), ainsi que `sourceLocale`, `targetLocale` et un objet `metadata` de premier niveau (qui peut être vide). La réponse est indexée par ces mêmes identifiants. Une petite méthode Ruby suffit : ```ruby title="app/services/gt_translate.rb" require "net/http" require "json" # Traduit un hash { field => text } avec l’API de traduction à l’exécution de General Translation. # Renvoie toutes les traductions demandées, ou lève une exception avant toute écriture en base de données. def gt_translate(fields, from:, to:, context: nil) uri = URI("https://api.gtx.dev/v2/translate") requests = fields.to_h do |field, text| [field.to_s, { source: text, metadata: { dataFormat: "STRING", context: context }.compact }] end request = Net::HTTP::Post.new(uri) request["Authorization"] = "Bearer #{ENV.fetch("GT_API_KEY")}" # clé de projet disposant de l’autorisation Runtime translation request["Content-Type"] = "application/json" request["gt-api-version"] = "2026-03-06.v1" request.body = { requests:, sourceLocale: from.to_s, targetLocale: to.to_s, metadata: {} }.to_json response = Net::HTTP.start(uri.host, uri.port, use_ssl: true, open_timeout: 5, read_timeout: 30) { |http| http.request(request) } raise "Translation request failed (#{response.code})" unless response.is_a?(Net::HTTPSuccess) results = JSON.parse(response.body) requests.keys.to_h do |field| result = results.fetch(field) unless result["success"] == true && result["translation"].is_a?(String) raise "Translation incomplete for #{field}" end [field, result.fetch("translation")] end end ``` Pour une traduction ponctuelle de l'article ci-dessus, lisez ses attributs en anglais, puis enregistrez le résultat complet en espagnol : ```ruby source = Mobility.with_locale(:en) do { title: post.title(fallback: false), body: post.body(fallback: false) } end translated = gt_translate(source, from: :en, to: :es, context: "Blog post for an online shoe store") Mobility.with_locale(:es) { post.update!(translated) } ``` L’utilitaire vérifie que chaque champ demandé dispose bien d’une traduction avant de mettre à jour l’article. Les validations habituelles de votre modèle restent applicables. (Consultez la [référence de l’endpoint](/docs/platform/openapi/reference/translation/translate-content) pour connaître les champs de requête et de réponse.) General Translation va plus loin qu’un simple appel de traduction automatique : l’endpoint traduit en s’appuyant sur le [glossaire et les instructions personnalisées](/docs/platform/dashboard/guides/defining-context-for-translations) de votre projet, afin que les noms de produits et le ton restent cohérents avec le reste de votre produit. La note de contexte lui indique que le texte est destiné à un magasin de chaussures, et la terminologie partagée assure la cohérence de ces descriptions de produits avec votre application et votre site marketing. Conservez la clé API côté serveur. Pour une automatisation continue, intégrez la traduction à votre workflow de publication de contenu existant et respectez les [limites de débit](/docs/platform/openapi/overview#api-basics) de l’API. Dans cet exemple, le résultat est enregistré directement dans le modèle. Si vos éditeurs valident le contenu avant publication, enregistrez le résultat en suivant le même processus de brouillon et de publication que pour l’article source. ## Mobility et General Translation en un coup d’œil | Fonctionnalité | Mobility | General Translation | | ------------------------------------------------- | -------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | Description | Gem Ruby pour stocker les attributs de modèle traduits | Plateforme de traduction dotée d’une API HTTP, d’une CLI, de bibliothèques pour JavaScript et Python, et d’un tableau de bord | | Stocke les traductions dans votre base de données | Oui, avec huit backends de stockage | Fournit les traductions à ces mêmes attributs de modèle | | Produit des traductions | Non | Oui, via `POST /v2/translate` | | Intégration Ruby | Attributs de modèle et accesseurs par paramètre régional | API HTTP appelée depuis Ruby | | Cohérence de la terminologie et du ton | À la charge de vos traducteurs | Glossaire et instructions personnalisées appliqués à chaque requête | | Coût | Gratuit, licence MIT | [Facturation à l’usage](https://generaltranslation.com/pricing) | ## Quand Mobility suffit à lui seul Utilisez Mobility seul si vos traductions sont déjà rédigées par des personnes : des éditeurs qui saisissent chaque langue dans un formulaire d'administration, une agence de traduction, ou des contenus qui doivent être traduits manuellement, comme les textes juridiques. Il suffit également si vous prenez en charge deux ou trois langues et que vos enregistrements changent rarement. Ajoutez General Translation lorsque le contenu arrive plus vite qu'il ne peut être traduit manuellement (annonces publiées par les utilisateurs, articles d'assistance, catalogue de plusieurs milliers de produits, etc.) et que vous souhaitez que chaque nouvel enregistrement soit disponible dans toutes les langues dès son enregistrement. ## Points clés * Mobility stocke et récupère les attributs traduits des modèles sur huit backends, avec prise en charge des solutions de repli et des requêtes. Il ne produit pas lui-même de traductions. * Une application Rails appelle l'endpoint `POST /v2/translate` de General Translation et enregistre les attributs traduits via Mobility. * General Translation applique votre glossaire, vos instructions personnalisées et le contexte propre à chaque contenu, sans toucher à vos modèles ni à votre workflow de publication existants. ## Related questions - [General Translation ou Rails I18n : avez-vous besoin des deux ?](https://generaltranslation.com/fr/kb/general-translation-vs-rails-i18n.mdx): Rails I18n recherche les messages et formate les dates et les nombres. General Translation produit les traductions, les tient à jour au fil de l’évolution de votre texte anglais et offre à votre équipe un tableau de bord pour la relecture. Utilisez les deux pour livrer des catalogues Rails traduits à chaque version. - [General Translation ou i18n-tasks : lequel choisir ?](https://generaltranslation.com/fr/kb/general-translation-vs-i18n-tasks.mdx): i18n-tasks est une gem Ruby qui détecte les clés Rails I18n manquantes ou inutilisées, fait le ménage dans les fichiers de paramètres régionaux et peut compléter les clés manquantes via Google Translate, DeepL, OpenAI, Yandex ou watsonx. General Translation traduit des fichiers de paramètres régionaux entiers en s’appuyant sur votre glossaire, vos instructions personnalisées et la relecture dans le tableau de bord. Les deux outils remplissent des rôles différents, et de nombreuses équipes peuvent les utiliser ensemble. - [Alternatives à Google Translate : General Translation vs Google Translate](https://generaltranslation.com/fr/kb/general-translation-vs-google-translate.mdx): Google Translate permet de traduire rapidement un texte ponctuel, mais pour livrer un produit dans une autre langue, il faut aussi traduire chaque chaîne de caractères dans son contexte, garantir la cohérence des termes, gérer correctement les variables et les formes plurielles, prévoir une relecture et mettre en place un processus de livraison. General Translation comprend le contexte de chaque chaîne de caractères dans votre code et automatise l’ensemble du workflow de localisation, du code à la relecture, jusqu’à chaque livraison. - [General Translation vs i18next, react-intl et next-intl : quelle bibliothèque d’i18n choisir ?](https://generaltranslation.com/fr/kb/general-translation-vs-i18n-libraries.mdx): Les bibliothèques open source comme i18next, react-intl et next-intl ne traduisent rien. Elles affichent les traductions que vous leur fournissez dans un fichier de catalogue par langue, rédigées par vous, vos traducteurs ou un service tiers. Les bibliothèques de General Translation sont elles aussi open source et remplissent le même rôle, mais General Translation se charge en plus de la traduction, en s’appuyant sur votre code comme contexte. - [Pourquoi utiliser General Translation plutôt qu’un TMS (Smartling, Lokalise, Phrase, Crowdin ou Transifex) ?](https://generaltranslation.com/fr/kb/general-translation-vs-tms.mdx): Un système de gestion de la traduction (TMS) comme Smartling, Lokalise, Phrase, Crowdin ou Transifex coordonne les traducteurs, mais les ingénieurs doivent toujours extraire les chaînes, les envoyer, attendre les traductions, puis les réintégrer dans le produit. General Translation traduit le contenu directement dans votre code, avec son contexte, fournit toutes les langues à chaque livraison et repose sur des bibliothèques open source, sans dépendance à un fournisseur. ## Previous and next questions - Previous question: [General Translation ou Locize : lequel choisir ?](https://generaltranslation.com/fr/kb/general-translation-vs-locize.mdx) - Next question: [General Translation ou nestjs-i18n : lequel choisir ?](https://generaltranslation.com/fr/kb/general-translation-vs-nestjs-i18n.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/fr/kb/sitemap.md) for every article.