Where do I find activerecord and date translations for whatever language I'm trying to add to my site?
Rails comes equipped with an I18n framework / API, which like most such frameworks involves defining a message catalog for each supported language. In the case of Rails, catalogs are YAML files under config/locales.
Rails defines standard keys for general ActiveRecord validation messages, but only comes with English translations by default. An alternative to providing translations from scratch yourself is to install the rails-i18n gem (svenfuchs/rails-i18n), which comes bundled with translations for many supported languages. These include both default ActiveRecord messages and assorted other things such as date and currency formats, days of the week, etc. You can mix and match the translations in rails-i18n with your own custom translations of course by adding your own locale files.
Note: The contributors to rails-i18n have done a great job, but not all locales have the full set of ActiveRecord messages, so in some cases you will have to provide your own (or consider contributing a pull request to the project).
EDIT:
The pre-defined catalogs that come with rails-i18n are installed with the gem. Running bundle info rails-i18n will show you the local install path; the locale files are in rails/locale if you want. Rails should find these automatically with further effort. So, in rails console:
foobar> I18n.locale = :tr
=> :tr
foobar> I18n.t 'time.pm'
=> "öğleden sonra"
You can extend or override the defaults by creating a custom locale file in your app's config/locales directory. The I18n search path will check config/locales before moving onto the default, so you only need to supply new or changed translations in your custom locale file.
Related
I have a React/Rails application which I am setting up i18n translations. Using rails-i18n and i18n.js gems. I have en.yml and es.yml files for english and spanish. The translations seem to work well for this application. I am able to get the translations rendered in the in the view. However, there is a second React/Redux application which makes api calls to this same backend. Is it possible to use the translations I already have in Rails? If so, what is the best way to set the translations?
Let's say I have a really simple rails app that runs on one 1 app server and supports one language (en_US).
The i18n gem works great and provides all translations as read from my en.yml file. Woohoo.
But let's say I scale my app and it now supports the following -
Enterprise versions of the app, so it runs on several app (and db) servers
Multiple languages other than en_US (e.g. ja_JP, ms_MY, en_GB, etc..)
I'm now supporting multiple instances of the app, each with several *.yml files that are starting to pile up. Plus, the app is getting more complex so each YML file is getting huge because there are a lot of translations.
Is there a clean way to move these YML files and i18n translations out of the core app? I'm envisioning an HTTP that functions as an "i18n service". Every time an app starts up it queries the i18n service and gets all the translations it needs for particular locale.
Is this a scalable way to approach this? Anyone have any experience in using a different design pattern?
Thanks!
You can break one large yml file into several ones, and even distribute files in subdirectories.
For instance your localization tree might look like this:
locales/
models/
user_en.yml
user_jp.yml
product_en.yml
product_jp.yml
pages/
index_en.yml
index_jp.yml
en.yml
jp.yml
To include all yml files from this tree, modify you application.rb accordingly:
config.i18n.load_path += Dir[File.join(Rails.root, 'config', 'locales', '**', '*.{rb,yml}')]
I'm trying to use I18n locales for a multisite application and wondering whether it's at all possible to load some extra translation locale files after the rails app has initialized?
I'm already using the excellent Globalize gem for ActiveRecord model translations, but I essentially want to be able to load the locales for a given site from it's own folder. I'm therefore trying to use something along the following lines in my site loader code:
I18n.load_path = File.join(site.path, 'locales')
Where the site.path variable relates to the current site's configuration & asset directory.
I don't want to rely on adding an i18n initializer to glob through the sites directory for locales for 2 reasons:
I can't guarantee a different site won't use the same translatable string, and I don't want them overwriting each other.
I don't want to have to restart the application each time a new site has been added.
If it helps, my logic to doing it this way allows for some sites to be multi language, and some not, and allows me to be lazy about whether a site is multi-language or not because if I can do the above successfully, I can use I18n.available_locales to determine whether or not to show the lanuage switcher in the admin app etc.
I'm using http://guides.rubyonrails.org/i18n.html for localization. Looks like that the only solution for updating localization is to update yml files. May be there are some solutions or gems which adds ability to update localization via application. For example we can include some gem and update localization files from our app. Is there some solutions for that?
Shameless plug for my own product here, but check out http://www.localeapp.com for a solution that works with YAML files out of the box.
Take a look at Globalize 3. It stores the translation/localization data in the database. There's also a gem to hook it up with ActiveAdmin.
Also, while you're at it, don't miss the rails-i18n gem mentioned in the guide. It translates Rails itself into many languages, so you don't have to do it yourself.
There is a great railscast to manage i18n through Redis.
For example, I think the gems such as haml doesn't need a file in config/initializers/, while devise needs a config/initializers/devise.rb.
Why do some gems not need an initializer file and some do? Can they all be made to be without one or all require one? What's the rule?
Some gems need more configuration than others, usually when the functionality is related to an account or needs to be manually configured to work with your specific rails apps (like hoptoad_notifier and devise), other gems provide or add in more general functionality in your rails apps, often these will work without any configuration but do have some flexibility and can be customized with an initialiser (like haml and will_paginate).