Drop your .yaml file here, or click to browse
.yaml or .yml, up to 400 KB
How the YAML translator works
A YAML locale file, like the ones Rails, Symfony, and i18n gems use, has two halves that must be treated differently. The keys are lookup identifiers your code calls, so translating them breaks the app. The values are what users read, so they are the only thing that should change. This tool finds the string values in your file and replaces just those spans of text, byte for byte. Everything else, including keys, nesting, comments, anchors, list structure, and blank lines, is never touched at all, so the diff you commit is only the strings.
Comments and placeholders survive
Because only the value text is replaced, every # comment in your file comes back exactly where it was, which most YAML converters lose. Interpolation tokens are pulled out before the model sees the string and put back afterwards, so an AI cannot rename or drop them. That covers Rails-style %{name}, {{count}}, {value}, %s and %d, ${x}, and inline markup like <b>.
If a placeholder still would not come back intact, that one value is kept in the original language rather than shipped broken. A missing translation is a five second fix. A dead %{name} is a production bug.
What is left alone on purpose
- Every key, at every level of nesting, including the top locale key like
en: - Comments, blank lines, indentation, and quoting style
- Anchors (
&name), aliases (*name), and merge keys (<<) - Numbers, booleans, nulls, dates, URLs, email addresses, and code-style values
- Values under technical keys like
id,url,icon,class, andslug - Multiline block scalars (values written with
|or>) are currently left untranslated so their exact indentation can never be corrupted
Tips for locale files
- Add a glossary for product names and UI verbs so the whole file stays consistent
- Pick a specific target variant, like Latin American vs European Spanish, for the right register
- Remember to rename the top-level locale key yourself after translating, for example
en:toes:for Rails - Diff the result before committing. Only the string values should show up
Frequently asked questions
Does it translate the keys in my YAML file?
No, never. Keys are the identifiers your code looks up, so translating them would break every call site. Only string values change. Because the tool replaces just those spans of text inside your original file, keys, nesting, indentation, quoting style, and blank lines come back exactly as they were, and the diff shows only the strings.
Do my comments survive?
Yes, every # comment comes back exactly where it was. Most YAML tools parse the file and write a new one, which throws comments away. This one only replaces the value text, so comments, anchors, aliases, and merge keys are never touched at all.
What happens to placeholders like %{name} or {{count}}?
They are pulled out before the AI sees the string and put back afterwards, so the model cannot rename or drop them. That covers Rails-style %{name}, {{count}}, {value}, %s and %d, ${x}, $t(other.key), and inline markup like <b>. If a placeholder still would not survive, that single value is kept in the original language rather than shipped broken.
Does this work with Rails i18n locale files?
Yes, that is the main use case. Upload config/locales/en.yml, translate the values, and download the result. One thing stays your job: rename the top-level locale key yourself, for example en: to es:, since the tool never changes keys on principle.
Are multiline block values translated?
Values written with the | or > block style are currently left in the original language on purpose, so their exact indentation can never be corrupted. Regular quoted and unquoted values, which make up almost all of a locale file, are translated normally.
Is it free, and are my files stored?
Free, with no signup. Your file is processed in memory to produce the translation and is not kept afterwards, never used for training, and never shared.