# General Translation Integrations: Translating content URL: https://generaltranslation.com/en-US/docs/integrations/sanity/guides/translating-content.mdx --- title: Translating content description: How to translate Sanity documents from the document action, the tab view, or the Translations page. related: links: - /docs/integrations/sanity/guides/managing-translations - /docs/integrations/sanity/guides/querying-translations - /docs/integrations/sanity/guides/configuring-sanity --- Generate document-level or field-level translations with the General Translation plugin. Document-level translations create a document for each locale. Field-level translations add localized values to internationalized arrays in the source document. ## Translate one document [#translate-one] The **Translate** action is available on every document, but the translation tools only appear on source-language documents. On a translated document, the dialog shows a message instead. 1. Open a source-language document in Sanity Studio. 2. Click **Translate** in the document action bar. 3. Under **Translate**, select the target locales. 4. Click **Translate**. The dialog shows each locale as **Not translated**, **Translating…**, **Ready to import**, or **Imported** under **Translation Status**. While a run is outstanding, the **Translate** button stays disabled. For document-level localization, auto-refresh and auto-import are on by default, so translations that finish while the dialog is open are imported as drafts. Auto-patch and auto-publish are off by default. You can toggle each behavior, import a locale manually from its status row, or use **Import All**, **Patch References**, and **Publish Translations**. A translation that was already complete when you opened the dialog is not re-imported automatically, which preserves edits to its Sanity document. For field-level localization, import merges the translated values into `internationalizedArray*` fields on the same document. Review and publish that document in Sanity. Reference patching and the translation publishing controls apply only to document-level translations. ## Use the Translations tab [#translations-tab] If your Studio includes `TranslationsTab`, open the **General Translation** tab on a document. It provides the same workflow as the **Translate** action, kept visible inside the document editor. See [Configure Sanity](/docs/integrations/sanity/guides/configuring-sanity#translations-tab) to add the tab. ## Translate many documents [#translate-many] Use the site-wide **Translations** tool to work across all translatable documents at once. From it you can: - Generate translations for all documents (**Translate All**). - Import all ready translations (**Import All**). - Import only translations that have not been imported yet (**Import Missing**). - Patch references across translated documents (**Patch References**). - Publish translated documents whose source is published (**Publish Translations**). - Send the translations already in Sanity to General Translation (**Save Local Edits**). See [Managing translations](/docs/integrations/sanity/guides/managing-translations). ## Keep edits to translations [#preserve-edits] Editors often revise translated content after it comes back from General Translation. By default, a later translation run regenerates that content and those edits are lost. Turn on **Save local edits** to keep them. With the toggle on, each translation run first sends the translations currently in Sanity for documents that already have a General Translation source version. Content whose source text has not changed is then reused from Sanity instead of being translated again. The toggle is in the **Translations** tool, and on the document tab as **Save local edits before translating**. It is off by default. Turning it on asks for confirmation first; turning it off takes effect immediately. The plugin remembers this choice in browser storage for the current Sanity project and dataset. It takes precedence over the configured [`preserveExistingTranslations`](/docs/integrations/sanity/reference/plugin-configuration#preserve-existing-translations) default on later visits. Both localization strategies are covered. Document-level translations are read through `translation.metadata`, preferring drafts over published documents so unpublished edits count. Field-level translations are read from the source document's internationalized arrays. Locales with no existing content are skipped. Turning this on makes Sanity the source of truth. What is in Sanity replaces whatever General Translation holds for that version of the document, including a translation that has finished but has not been imported yet. Import any pending translations first. If the plugin cannot send the existing translations, the translation run still proceeds and the Studio warns that edits may be overwritten. ## Save local edits without translating [#save-local-edits] Use the **Save Local Edits** action to send the translations already in Sanity to General Translation without starting a translation run. The plugin uploads the source files it needs, then stores each locale's existing content as the translation for that version. Use this action before the toggle when a document does not yet have a General Translation source version. This is useful when adopting the plugin on a project that was translated elsewhere, so General Translation starts from the content you already have. The action is available in the **Translations** tool and on the document tab. It runs on demand and does not depend on the **Save local edits** toggle. ## Regenerate translations [#retranslate] To discard existing translations and generate them again, open **Translate All** and check **Retranslate from scratch**. The confirm button changes to **Retranslate All**. This discards edits made to translated documents in the Studio, and skips the **Save local edits** step for that run. Leave the checkbox unchecked to reuse existing translations. This option is available in the **Translate All** dialog only. The single-document **Translate** workflow always reuses existing translations and respects the **Save local edits** toggle. ## What gets translated [#what-translated] The plugin serializes documents to HTML, sends that HTML for translation, then merges the translated HTML into locale documents or internationalized-array fields, depending on `translationLevel`. It recursively processes: - String and text fields. - Portable Text blocks. - Nested objects. - Arrays. Some field types are preserved and not sent for translation by default, including references, dates, files, images, numbers, booleans, URLs, colors, code, and geopoints. See the full [default stop types](/docs/integrations/sanity/reference/plugin-configuration#stop-types). Slug fields are *not* stopped by default, so a slug's `current` value is sent for translation. Use `dedupeFields` or `skipFields` to control slug behavior. ## Handle references [#references] Document-level translations can reference other documents. The plugin looks up each referenced document's translation and rewrites the reference to point to the correct locale version, when one exists. Turn on **Auto-patch after import** to run this after each import, or use **Patch References** on demand. Auto-patch is off by default. See [Manage translations](/docs/integrations/sanity/guides/managing-translations#patch-references). ## Handle slugs and copied fields [#slugs-fields] Some fields should not be translated directly. Use field matchers to control them: - `dedupeFields` — copy the source value and append the locale to make it unique per document, such as `about` to `about-es`. Commonly used for slugs. - `ignoreFields` — copy the source value unchanged to each translated document. - `skipFields` — remove the field from translated documents entirely. See [Manage translations](/docs/integrations/sanity/guides/managing-translations#field-behavior). ## Next steps - /docs/integrations/sanity/guides/managing-translations - /docs/integrations/sanity/guides/querying-translations - /docs/integrations/sanity/guides/configuring-sanity