Translate a Ruby on Rails app into English
Upload your <code>config/locales/*.yml</code> files and Manuce translates the values into English, swaps the root locale key (<code>fr:</code>, <code>de:</code>, <code>es:</code>…) for <code>en:</code>, checks interpolations such as <code>%{count}</code> and adapts the <code>one</code>/<code>other</code> plural forms. You get back the same YAML file, ready to drop into your project, with a report on any strings left untouched.
What it costs
For the language files of a Ruby on Rails app totalling about 3,000 words, into English:
To understand, internal use.
Ready to send, by the technical specialist.
Cross-checked. For documents that commit you.
Price for one language, original layout included. VAT not applicable — article 293 B of the French General Tax Code (CGI). The exact quote, based on your file's word count, is shown before you pay.
What changes when a Rails locale file moves to English
A Rails locale file starts with the language’s root key. The delivered file starts with en: instead; everything beneath keeps the same tree, so t('.title') lazy lookups and t('users.index.title') calls still resolve.
- Plurals. English has only two CLDR categories,
oneandother. If your source is Polish or Russian, withfewandmany, those forms collapse intoother. If it is French, note that Frenchonecovers 0 as well as 1, whereas in Englishcount: 0selectsother: ‘0 comments’. Soother: "%{count} comments"must read naturally for zero too. An explicitzero:key, if you have one, is kept and translated (‘No comments yet’). - Validation messages. Rails builds
%{attribute} %{message}, so the message must follow the attribute name: ‘Email can’t be blank’. Gender agreement markers found in Romance-language sources, such as ‘rempli(e)’, simply disappear. - Punctuation. French spacing before colons goes:
"Total :"becomes"Total:"; German „…“ or French « » quotes become English quotation marks. - Length. From French, English text usually runs 10 to 15% shorter, so buttons and form labels rarely need layout changes.
British or American English: decide before uploading
The root key produced is en:, but spelling and vocabulary should follow one variety across the whole app. Typical differences in a Rails interface:
- colour / color, organisation / organization, cancelled / canceled;
- basket / cart, postcode / ZIP code in address forms;
- Sign in versus Log in: pick one and keep it in every view and mailer.
Date formats are not translated: date.formats.default: "%d/%m/%Y" stays as it is. That suits a UK audience; for the US, change it yourself to "%m/%d/%Y", and consider %I:%M %p instead of %H:%M in time.formats. Check number.format too: many European sources use a comma as decimal separator and a space or full stop for thousands, while English expects 1,250.50.
If your app serves en-GB and en-US separately, rename the root key and file accordingly after delivery.
What Manuce returns, and what it does not do
The file returned is the one you uploaded: indentation, key order, quoting style, comments, line endings, encoding and BOM are all preserved. Only the values change, which keeps your Git diff readable line by line.
- Each translated value is compared with the source for variables and tags.
welcome_html: "Bonjour %{name}"must come back as"Hello %{name}", same placeholder, same tag. If a mismatch persists, the source value is kept and the report says so. - Not translated: keys, empty values, URLs, email addresses, numbers, colours, date formats, identifiers and anything marked as non-translatable.
- The report lists translated strings and those left as they were, with the reason.
What Manuce does not do: it only sees locale files. A string hard-coded in an ERB view or a controller, such as notice: "Profil enregistré", is not in the YAML and stays in the source language. Nor does it touch config/application.rb or your initialisers. Pricing is based on the words in the values, with keys and tags excluded; for a customer-facing interface, the Professional level, handled by the domain specialist, is the sensible choice.
Preparing your files and checking the result
Before uploading:
- Move any hard-coded strings out of views, mailers and flash messages into YAML; a tool such as the
i18n-tasksgem helps spot missing or unused keys. - Gather every relevant file: the main locale file, but also
devise.fr.ymlor similar gem files, and per-model files holdingactiverecord.models.useroractiverecord.attributes.user.email. - Make sure the YAML loads cleanly: a badly indented source file will still be badly indented.
After delivery:
- Save the file as
config/locales/en.ymland add:entoconfig.i18n.available_locales. - Set
I18n.locale = :enand render a counter with 0, 1 and 2 items to checkoneandother. - Look for concatenation in code, such as
t('label') + " :", which reintroduces foreign punctuation. - Adjust date and number formats for your chosen variety, then work through the report for any strings left untranslated.
In practice
- Collect the locale files from config/locales, including gem files such as Devise’s.
- Upload them: the quote appears at once, based on the words in the values, and a free extract shows the result.
- Choose a level and pay; a typical file is translated in minutes.
- Put en.yml in config/locales, add :en to available locales and adjust date and number formats.
- Read the report and test plurals with count set to 0, 1 and 2.
Frequently asked questions
Does the delivered file replace my source locale file?
No. It is a copy with the same structure whose root key is en:; save it as en.yml next to the original. Rails loads files placed directly in config/locales by default; subfolders must be added to the load path.
Are %{count}, %{name} and _html keys preserved?
Yes. Every translated value is checked against the source for placeholders and tags. If a mismatch persists, the source value is kept and flagged in the report, so nothing breaks at render time.
Will I get British or American English?
State the variety you want and keep it consistent: spelling, and words such as basket or cart. Date and number formats are left unchanged, so switching %d/%m/%Y to %m/%d/%Y for a US audience is up to you.
Are ActiveRecord validation messages and Devise strings translated?
Yes, provided they sit in the YAML files you upload, for example activerecord.errors.messages or Devise’s locale file. Messages hard-coded in models or controllers are not seen.
How is the price worked out?
On the exact number of words in the values, with keys and tags excluded; English is charged at the base rate (×1 coefficient). The quote appears as soon as you upload, before any payment.
The specialist in charge
This subject goes to Dédale, the technical specialist. See how it works.
The same file, into another language
Into English, other files
See also
Try it on your own file, free
A sample of your file translated at the level you choose, before any payment. You judge, then you decide.