Build apps · Your App Cloud
Build an AI translation tool
A language model prepares the first draft and a fluent reviewer decides what gets used. Your approved terms, tone notes and every edit stay in one app.
Built around a purpose
From source text to a translation someone signed off.
For people who publish the same material in more than one language, or who get messages in languages they don't read. That might be a shop with care guides and store notices, or a front desk answering customer messages.
For illustration: a California outdoor-gear shop writes its product care guides, return policy and store notices in English and needs Spanish, Vietnamese and Arabic versions. Bring a 40-term glossary, including product line names that stay in English, and 10 passages a professional translator has already translated, to test against.
A translation queue for three languages. Each entry shows the English source, the model's draft and the approved wording side by side, with the glossary terms found in the source, its status and who signed it off.
This app needs Pro: drafting with a language model inside the app, saving the glossary and every reviewer edit, and reviewer sign-in are backend capabilities. Free publishes frontend-only static apps. Model and service usage is metered separately.
Settle the glossary before any text
List each term with its approved translation per language, or mark it keep as written, like product line names and model numbers. Decide the hard pairs up front: waterproof and water-resistant promise different things, so each gets one approved word.
Write a tone note per audience
Customers get one note and staff another. For Spanish, say whether customers are addressed formally, with usted, or informally, with tú. Add what must never change, such as prices in USD and the store's phone number.
Describe an entry from request to sign-off
Tell Studio what one entry holds: source text, target language, audience, the model's draft, the reviewer's edited version, and a status of draft, in review, approved or sent back. Ask for the glossary terms found in the source to be listed beside each draft, so the reviewer can check them one by one.
Grade drafts against human translations
Run the 10 test passages for each language in the preview and put every draft beside the translator's version. Note wrong terms, changed numbers and shifts in tone. Fix the glossary or the tone note rather than the draft, then run them again.
Give each language a named reviewer
The reviewer reads source and draft side by side, edits in place and approves. Safety warnings and the return policy get a second sign-off. When reviewers fix the same term twice, turn it into a glossary entry.
Scope the first version
What a first version includes.
Translation entries
One record per piece of text, with the source, target language, audience, due date and status, so a requester can see where an entry stands. A sensitive mark holds an entry for a second sign-off.
Glossary by language
Each term with its approved translation or a keep-as-written mark, a usage note and who approved it. A view lists any term with two translations in one language, so its owner picks one.
Tone notes
One short note per audience and language covering form of address, reading level and words to avoid. Each draft request carries the note for that entry's audience.
Side-by-side review
Source and draft in two columns with the draft editable and glossary terms highlighted in both. Arabic entries laid out right to left.
Edit history
The model's draft, each reviewer change and the final approval, with names and dates, kept after approval so you can trace when a wording changed and who changed it.
Repeated corrections
Reviewers mark a fix they have made before, such as the same product term corrected again, and the glossary owner decides whether it becomes an entry.
Test passages
The 10 passages with their human translations. Rerun them after any change to the glossary or a tone note and compare.
Test it in the preview
Before you share it.
- Open five approved entries that contain glossary terms. Each term should use its approved translation, and anything marked keep as written, such as a product line name, should appear unchanged.
- Compare every number, price, date and phone number in a draft with the source. A notice dated 04/05 means April 5 to a US reader but May 4 to many Spanish and Vietnamese readers. Check that the date is written in a form they will read correctly.
- Open an Arabic entry on a phone and on a laptop. The text should run right to left, with numbers, product names and punctuation where an Arabic reader expects them. Ask the Arabic reviewer to confirm.
- Signed in as a requester, try to approve your own entry. If the access you describe for each collection (Pro) keeps approval with reviewers, the attempt should fail. Signed out, drafts should not be reachable at all.
- Mark the return policy as sensitive and try to approve it with one sign-off. It should stay in review until the second reviewer approves.
- Change the customer tone note and rerun the test passages. Compare the new drafts with the translator's versions before you keep the change.
Together in your app cloud
The pieces behind the possibility.
Choose the models and services that support the experience you want to create.
Language models
Reason, write, and understand
Database
Keep data and context for apps and agents
Authentication
Give the right people access
Shape the details
Make it work for your world.
- Treat a model draft as unapproved until a fluent reader signs it off. Safety warnings, contracts, and medical or legal text need a qualified translator's sign-off, and the entry should show who gave it.
- Give each language one glossary owner. Two approved translations for the same term leave reviewers guessing, so the owner settles the conflict before the term reaches a draft.
- If your terms start in a spreadsheet, importing it copies them once, and later edits to that sheet don't reach the app. Change terms in the app's glossary, or re-import on purpose and recheck a sample.
- Decide whether published translations say they were drafted with a model and reviewed by a person. If they do, word that line the same way in every language.
A little more context
Good questions.
Which languages can it translate?
Coverage and quality differ by language pair and by the models available to your app. One good pair tells you little about the next. Run your test passages for each pair in the preview and have a fluent reader grade the drafts. Add a pair to the app only after its drafts pass that review.
Can it translate incoming customer messages?
You can design it for that. Paste each message in or collect it through a form, and save its original text and language with a translation beside it. Draft replies in English, then translate them back. Someone who reads the customer's language checks each reply before it goes out. If the app sends it by email (Pro), send a test to yourself first. To sort many messages by theme, see the feedback guide below.
Can this include spoken conversations?
Live speech needs its own design: listening, speaking, turn-taking and what happens when a phrase is misheard. The Voice apps category covers those choices. This guide is for written text that a person checks before anyone relies on it, and a live conversation leaves no time for that step.
How is this different from pasting text into a chat assistant?
A chat assistant can give you a quick draft. Build an app when several people need the same glossary, tone notes and approved versions from one request to the next, a record of who changed what, and a sign-off step for sensitive entries that you design and test. That record matters when the same terms come back next month, or when a customer asks about an old notice.
Explore Pricing for plans, included capabilities, and usage details.
Keep exploring.
Your ideas, up and running
Your next idea has a home.
Build an app. Run an agent. Make it yours.
Start building