kotovalexarian-likes-github/rails--rails
1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00
Code Releases Activity

Prefer I18n over i18n when referencing internationalization

Browse source
This commit is contained in:
Paarth Madan 2022-01-26 16:42:30 -05:00
parent e2865d5f45
commit 83b9ad270a
1 changed files with 3 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
guides/source/i18n.md
View file

@ -9,7 +9,7 @@ The process of "internationalization" usually means to abstract all strings and
So, in the process of _internationalizing_ your Rails application you have to:
* Ensure you have support for i18n.
* Ensure you have support for I18n.
* Tell Rails where to find locale dictionaries.
* Tell Rails how to set, preserve, and switch locales.
@ -48,7 +48,7 @@ To localize store and update _content_ in your application (e.g. translate blog
Thus, the Ruby I18n gem is split into two parts:
* The public API of the i18n framework - a Ruby module with public methods that define how the library works
* The public API of the I18n framework - a Ruby module with public methods that define how the library works
* A default backend (which is intentionally named _Simple_ backend) that implements these methods
As a user you should always only access the public methods on the I18n module, but it is useful to know about the capabilities of the backend.
@ -135,7 +135,7 @@ I18n.available_locales = [:en, :pt]
I18n.default_locale = :pt
```
Note that appending directly to `I18n.load_path` instead of to the application's configured i18n will _not_ override translations from external gems.
Note that appending directly to `I18n.load_path` instead of to the application's configured I18n will _not_ override translations from external gems.
### Managing the Locale across Requests