As discussed in #15304, we need to automate this process but for now,
having out-of-date versions is not ideal.
Since master targets 4.2.0, let's also update references to the last 4.1
version to 4.2.0.
Finally, let's remove mentions to versions when this is not needed. The
guides cover the features of the current version anyway.
[Juanito Fatas + Robin Dupret]
Previously, only the object and method name from the label tag were
used when looking up the translation for a label. If a value is
given for the label, this ought to be additionally used. The
following:
# form.html.erb
<%= form_for @post do |f| %>
<%= f.label :type, value: "long" %>
<% end %>
# en.yml
en:
activerecord:
attributes:
post/long: "Long-form Post"
Used to simply return "long", but now it will return "Long-form
Post".
Currently, the section called "How to store your custom translations"
has several subheadings that make no sense, such as "Translations for
ActiveRecord models." These make more sense under the "Overview of the
I18n API Features" section. I moved the "How to store..." section down
to the more appropriate sub-headings "Using Different Backends" and
"Using Different Exception Handlers" and removed the "Customize your
i18n setup" header.
Calling `to_sym` on user input opens apps up to Denial of Service attacks, via the symbol table being expanded to consume vast swathes of memory.
It is a fairly common configuration to have DNS configured such that all subdomains route to your Rails app, in which case an attacker visits `www1.foo.com`, `www2.foo.com`, and so on until something gives.
It is far less likely to have this problem with TLDs, so that change was only for consistency.
`I18n.locale=` symbolizes its argument, so passing it `params[:locale]`
allows one to DOS your application by visiting `...?locale=` URLS
repeatedly, with unique values, until the never-GCed symbols monopolize
the available memory.
In the absence of proper escaping the first link was getting messed up and remaining part of the sentence (2nd link) was not displayed in the rendered markdown on the website though it was displaying correctly in the repository markdown file.
I think it's confusing to say "Use them in views without escaping." We
use all keys in views without escaping - the escaping is done for us
automatically _unless_ we call html_safe or the key ends in _html.
This is for 3 Internationalizing your Application of i18n.md.
Missing the code as mentioned in 2.3, setting locale.
Without this, the example to add config/locales/pirate.yml will not work.
Xavier Noria