# General Translation Knowledge Base: General Translation o Mobility: quale scegliere? URL: https://generaltranslation.com/it/kb/general-translation-vs-mobility.mdx Docs index: https://generaltranslation.com/llms.txt Description: Mobility salva nel tuo database gli attributi tradotti dei modelli. General Translation genera queste traduzioni tramite la sua API, usando il tuo Glossario e i tuoi prompt personalizzati. Usali insieme per tradurre schede prodotto, post e altri contenuti del database senza rinunciare ai tuoi modelli Rails. Category: Internazionalizzazione Last updated: 2026-10-16 Authors: Kevin Wu, Jackie Chen Published: 2026-10-16 Mobility è una gem Ruby per tradurre i dati del tuo database: dichiari `translates :title` su un modello e `post.title` restituisce il titolo nell'impostazione regionale corrente, letto dal backend di archiviazione che preferisci. Mobility salva e recupera le traduzioni, ma scriverle spetta ai tuoi redattori, ai traduttori o a un servizio esterno. General Translation le fornisce tramite la sua API HTTP. Mobility conserva gli attributi tradotti nel database che già utilizzi, pronti per le stesse query e gli stessi metodi dei modelli che usi oggi. ## Cosa fa bene Mobility * **Scelta dell'archiviazione.** Il backend predefinito `key_value` [conserva tutte le traduzioni in due tabelle condivise](https://github.com/shioyama/mobility/wiki/KeyValue-Backend) (una per le stringhe, una per il testo). Il backend `table` usa una tabella di traduzione per ogni modello (l'approccio di Globalize), `column` usa colonne con suffisso come `title_en` e `title_es`, `serialized` le salva in un'unica colonna di testo e, su PostgreSQL, `json`, `jsonb`, `hstore` e `container` (una colonna jsonb per modello) le memorizzano in modo nativo. Puoi anche scrivere un backend personalizzato. * **Un'unica API per tutti i backend.** Letture e scritture seguono `I18n.locale` e i plugin (fallback, accessor per impostazione regionale come `post.title_es`, dirty tracking, caching e controlli di presenza) [funzionano allo stesso modo con qualunque backend tu scelga](https://github.com/shioyama/mobility#backends). * **Query.** [`Post.i18n.where(title: "...")`](https://github.com/shioyama/mobility#querying) genera le join per l'impostazione regionale corrente, così puoi cercare negli attributi tradotti senza sapere come sono memorizzati. * **Supporto ORM.** [Funziona con Active Record 7.0 e versioni successive e con Sequel](https://github.com/shioyama/mobility#installation), e la sua wiki include una guida per migrare da Globalize. * **Gratuito.** È distribuito con licenza MIT; il [rilascio attuale è la 1.3.2](https://rubygems.org/gems/mobility). ## Cosa lascia a te Mobility Ecco un post con titolo e corpo in inglese, che utilizza il backend `key_value` su SQLite, con un fallback dallo spagnolo all'inglese solo per il titolo: ```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" (in inglese, tramite il fallback) I18n.with_locale(:es) { post.body } # => nil I18n.with_locale(:ja) { post.title } # => nil ``` È il comportamento corretto per un livello di archiviazione: Mobility ha salvato i valori in inglese e ogni altra impostazione regionale resta vuota finché qualcuno non la compila. Con un fallback, i lettori di lingua spagnola vedono l'inglese; senza, non vedono nulla. Per i contenuti che cambiano ogni giorno, come schede prodotto, articoli o pagine di assistenza, qualcuno deve tradurre ogni record nuovo o modificato in ciascuna lingua e salvarlo con l'impostazione regionale corretta. ## Compilare gli attributi di Mobility con General Translation L'endpoint di traduzione in fase di esecuzione di General Translation, `POST https://api.gtx.dev/v2/translate`, traduce le stringhe su richiesta. Accetta come bearer token una chiave API di progetto con il permesso **Runtime translation** e un corpo contenente un oggetto `requests` indicizzato in base ai tuoi ID, in cui ogni voce ha una stringa `source` e un campo `metadata` facoltativo (ad esempio una nota `context`), oltre a `sourceLocale`, `targetLocale` e un oggetto `metadata` di primo livello (che può essere vuoto). La risposta è indicizzata con gli stessi ID. Basta un piccolo metodo Ruby: ```ruby title="app/services/gt_translate.rb" require "net/http" require "json" # Traduce un hash { campo => testo } con l'API di runtime di General Translation. # Restituisce tutte le traduzioni richieste, oppure solleva un'eccezione prima di qualsiasi scrittura nel database. 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")}" # chiave di progetto con il permesso 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 ``` Per tradurre una tantum il post precedente, leggine gli attributi in inglese e salva il risultato completo in spagnolo: ```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'helper verifica che ogni campo richiesto abbia una traduzione prima di aggiornare il post. Le normali validazioni del tuo modello continuano ad applicarsi. (Consulta il [riferimento dell'endpoint](/docs/platform/openapi/reference/translation/translate-content) per i campi di richiesta e risposta.) Qui General Translation fa più di una semplice chiamata di traduzione automatica: l'endpoint traduce utilizzando il [Glossario e i prompt personalizzati](/docs/platform/dashboard/guides/defining-context-for-translations) del tuo progetto, in modo che i nomi dei prodotti e il tono siano in linea con il resto del tuo prodotto. La nota di contesto specifica che il testo è destinato a un negozio di scarpe; la terminologia condivisa mantiene le descrizioni dei prodotti coerenti con la tua app e il tuo sito di marketing. Mantieni la chiave API sul server. Per un'automazione continuativa, integra la traduzione nel flusso di lavoro di pubblicazione dei contenuti già in uso e rispetta i [limiti di frequenza](/docs/platform/openapi/overview#api-basics) dell'API. L'esempio salva direttamente nel modello. Per i contenuti che i tuoi redattori approvano prima della pubblicazione, salva il risultato seguendo lo stesso processo di bozza e pubblicazione dell'articolo sorgente. ## Mobility e General Translation a confronto | Funzionalità | Mobility | General Translation | | --------------------------------------- | ----------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | Che cos'è | Gem Ruby per archiviare gli attributi tradotti dei modelli | Piattaforma di traduzione con un'API HTTP, una CLI, librerie per JavaScript e Python e una Dashboard | | Archivia le traduzioni nel tuo database | Sì, con otto backend di archiviazione | Fornisce le traduzioni per quegli stessi attributi dei modelli | | Genera traduzioni | No | Sì, tramite `POST /v2/translate` | | Integrazione con Ruby | Attributi dei modelli e accessor per impostazione regionale | API HTTP chiamata da Ruby | | Coerenza di terminologia e tono | Affidata ai tuoi traduttori | Glossario e prompt personalizzati applicati a ogni richiesta | | Costo | Gratuito, licenza MIT | [In base all'utilizzo](https://generaltranslation.com/pricing) | ## Quando basta Mobility Usa solo Mobility se le traduzioni sono già scritte da persone: redattori che inseriscono ogni lingua in un modulo di amministrazione, un'agenzia di traduzione o contenuti, come i testi legali, che vanno tradotti a mano. Mobility è sufficiente anche se supporti due o tre lingue e i record cambiano di rado. Aggiungi General Translation quando i contenuti arrivano più in fretta di quanto le persone riescano a tradurli (ad esempio annunci degli utenti, articoli di assistenza o un catalogo con migliaia di prodotti) e vuoi che ogni nuovo record sia disponibile in tutte le lingue non appena viene salvato. ## Punti chiave * Mobility memorizza e recupera gli attributi tradotti dei modelli su otto backend, con supporto per fallback e query, ma non genera traduzioni. * Un'app Rails chiama l'endpoint `POST /v2/translate` di General Translation e salva gli attributi tradotti tramite Mobility. * General Translation applica il tuo Glossario, i prompt personalizzati e il contesto specifico dei contenuti, senza toccare i modelli e il flusso di lavoro di pubblicazione esistenti. ## Related questions - [General Translation vs. Rails I18n: servono entrambi?](https://generaltranslation.com/it/kb/general-translation-vs-rails-i18n.mdx): Rails I18n recupera i messaggi e formatta date e numeri. General Translation genera le traduzioni, le mantiene aggiornate man mano che il testo in inglese cambia e offre al tuo team una Dashboard per la revisione. Usali insieme per distribuire cataloghi Rails tradotti a ogni rilascio. - [General Translation vs. i18n-tasks: quale scegliere?](https://generaltranslation.com/it/kb/general-translation-vs-i18n-tasks.mdx): i18n-tasks è una gem Ruby che individua le chiavi Rails I18n mancanti e inutilizzate, riordina i file delle impostazioni regionali e può compilare le chiavi mancanti tramite Google Translate, DeepL, OpenAI, Yandex o watsonx. General Translation traduce interi file delle impostazioni regionali con il tuo Glossario, i prompt personalizzati e la revisione nella dashboard. Svolgono compiti diversi e molti team possono usarli entrambi. - [Alternative a Google Translate: General Translation vs. Google Translate](https://generaltranslation.com/it/kb/general-translation-vs-google-translate.mdx): Google Translate è un modo rapido per tradurre testi occasionali, ma pubblicare un prodotto in un'altra lingua richiede anche che ogni stringa sia tradotta nel suo contesto, con termini coerenti, variabili e plurali corretti, una revisione e un processo di rilascio. General Translation comprende il contesto di ogni stringa nel tuo codice e automatizza l'intero flusso di lavoro di localizzazione, dal codice alla revisione fino a ogni rilascio. - [General Translation vs. i18next, react-intl e next-intl: quale libreria i18n scegliere?](https://generaltranslation.com/it/kb/general-translation-vs-i18n-libraries.mdx): Le librerie open source come i18next, react-intl e next-intl non traducono nulla. Si limitano a visualizzare le traduzioni che fornisci in un file di catalogo per ciascuna lingua, scritte da te, dai tuoi traduttori o da un servizio esterno. Anche le librerie di General Translation sono open source e svolgono lo stesso compito, ma General Translation si occupa anche della traduzione, usando il tuo codice come contesto. - [Perché usare General Translation invece di un TMS (Smartling, Lokalise, Phrase, Crowdin o Transifex)?](https://generaltranslation.com/it/kb/general-translation-vs-tms.mdx): Un sistema di gestione delle traduzioni (TMS) come Smartling, Lokalise, Phrase, Crowdin o Transifex coordina i traduttori, ma gli sviluppatori devono comunque estrarre le stringhe, inviarle, attendere le traduzioni e reintegrarle nel prodotto. General Translation traduce i contenuti direttamente nel tuo codice insieme al loro contesto, distribuisce tutte le lingue a ogni rilascio e si basa su librerie open source, senza vendor lock-in. ## Previous and next questions - Previous question: [General Translation o Lingui: quale scegliere?](https://generaltranslation.com/it/kb/general-translation-vs-lingui.mdx) - Next question: [General Translation o Paraglide JS: quale scegliere?](https://generaltranslation.com/it/kb/general-translation-vs-paraglide.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/it/kb/sitemap.md) for every article.