CODEWITHSUNDEEP
ruby-on-railsinternationalizationyaml
t35la
t35la

Reputation: 21

Rails i18n - Multiple locales in the same YML file

My YML files are getting out of hand and I have started organizing them. At this point I am dealing with about 50 forms and 8 languages. And those can only increase. So if I follow the recommended method of re-factoring, then I would end up with about 50 folders and 8 files in each of them. On average, each form has about 10-20 translations associated with it. So I thought I would go with this approach:

/config
  /locales
    en.yml        # will contain default English translations
    es.yml        # will contain default Spanish translations
    ......        # etc. default files for each language
    form_1.yml    # translations for form 1 and related
    form_2.yml    # translations for form 2 and related
    ..........    # etc. for the different forms
    form_50.yml   # of course, will be using actual form names and not form_1 .. form_50 :)

The language files like en.yml are obvious as to what format they would contain translations in. But a file like form_1.yml will contain the following:

en:
  first_name: First Name
  last_name: Last Name

es:
  first_name: Nombre
  last_name: Apellido

it:
  first_name: Nome
  last_name: Cognome

fr:
  first_name: Prénom
  last_name: Nom

...etc for more languages

Or, multiple languages as root in the same file. This reduces the files I need to maintain from 404 to 54 plus an advantage of looking at all the languages at the same time to catch anything missed etc. I have tested this and it works. But before I go full steam ahead with this implementation, I would like to know what the rails community thinks of this. Any pitfalls with this method.

Thanks.

Edit: Please note that when I say form, I am not just referring to the translations for the captions. It will also include help messages, errors etc. related to the form.

Upvotes: 1

Views: 1987

Answers (1)

Paul Fioravanti
Paul Fioravanti

Reputation: 16793

There's a few other questions on StackOverflow regarding how to structure YAML files for i18n, and I don't think there is a 'right' answer to your question. If it works for you, then great! I would say that any answer you get will be completely subjective, and more about i18n and translation management rather than anything specifically to do with the Rails way.

Having said that, here are a couple of off-the-cuff subjective comments about how you have your YAML files set up:

  • It seems you've split up the translations into components programmatically much like you could split up a view into partials in a Rails app. You want to edit a form translation (or set of translations), you go straight to that form file and get the job done in one hit. Great if you are the admin/translator of all the translations, and it's great that this can mean less files.

  • One potential annoyance could be if you need a translation done (or re-done) by a third party for a language you don't speak? You'd need to give them a whole bunch of files with a lot of noise to filter through (the languages not under review), rather than just the files for the base language and the files with the keys for the target language. This is assuming you're not dealing directly with files and not using some tool like Localeapp or PhraseApp.

  • Perhaps a happy medium for you could be to have a config/locales tree structure like: 

    form_1/form_1.en.yml
form_1/form_1.it.yml
form_2/form_2.en.yml
form_2/form_2.it.yml etc...

    which gets you both componentisation and separation of languages...but probably more files than you have now.

Ultimately though, I'd say the file structure that makes the most sense for your i18n workflow is the best one.

Upvotes: 2

Related Questions