Internet Explorer 9 was released eight years ago. Besides that, we don't
really support IE8 anyway, since we show a popup to IE8 users saying
we don't support it, we haven't maintained the IE8-specific CSS file for
years, and we don't test our JavaScript against IE8.
We're reading the value from the database, but the
`ApplicationMailer.default` method is evaluated when the application is
started. So if we don't use a Proc, we'll need to restart the server
every time we change the value in the database, or else the old value
will still be used.
Using a Proc makes sure the mailer from address is evaluated at runtime,
so emails are sent using the from address currently defined in the
database.
The same situation took place using the devise mailer. Now we don't need
to check for the settings table being present because the Proc in the
devise initializer won't be evaluated before the settings table is
created and populated.
Proposal, Debate and Comment "globalize_accessors" class method were
loaded before application available locales initialization because of
graphql initializer. This will cause unexpected translation errors at
any translatable classes declared at graphql api definition (api.yml).
Doing GraphQL initialization after application initialization should
solve this issue.
Proposal, Debate and Comment "globalize_accessors" class method were
loaded before application available locales initialization because of
graphql initializer. This will cause unexpected translation errors at
any translatable classes declared at graphql api definition (api.yml).
Doing GraphQL initialization after application initialization should
solve this issue.
Rails 5 changed the initialization order, and now our initializers were
running before the `append_assets_path` initializer for each engine,
which prepended application assets to the custom assets we prepended in
the initializer.
Moving the code to the `config.after_initialize` code didn't work
either, since the paths added there were ignored by the application.
Adding another initializer to the Rails Engine is a hack, but solves the
problem.
Metrics/LineLength: Line is too long.
RSpec/InstanceVariable: Use let instead of an instance variable.
Layout/TrailingBlankLines: Final newline missing.
Style/StringLiterals: Prefer double-quoted strings.
DEPRECATION WARNING: #table_exists? currently checks both tables and
views. This behavior is deprecated and will be changed with Rails 5.1
to only check tables. Use #data_source_exists? instead.
When we were visiting a page showing the content of a record which uses
globalize and our locale was the default one and there was no
translation for the default locale, the application was crashing in some
places because there are no fallbacks for the default locale.
For example, when visiting a legislation process, the line with
`CGI.escape(title)` was crashing because `title` was `nil` for the
default locale.
We've decided to solve this issue by using any available translations as
globalize fallbacks instead of showing a 404 error or a translation
missing error because these solutions would (we thinkg) either require
modifying many places in the application or making the translatable
logic even more complex.
Initially we tried to add this solution to an initializer, but it must
be called after initializing the application so I18n.fallbacks[locale]
gets the value defined in config.i18n.fallbacks.
Also note the line:
fallbacks[locale] = I18n.fallbacks[locale] + I18n.available_locales
Doesn't mention `I18n.default_locale` because the method
`I18n.fallbacks[locale]` automatically adds the default locale.
We work with many languages using Crowdin[1]
Sometimes translators forget to fill in all the necessary plural forms of a translation (zero, one, other) and in those cases we were seing the exception InvalidPluralizationData being raised
There are a number of approches to fix this... from being more strict when approving translations, to automatically extrapolating what those plural forms should be
For now, we've gone for a simple approach to display the actual count(0,1,2,3,4, etc) instead of the whole translation
So, if the plural form of "1 comment" is missing, just a "1" will be displayed and no exceptions raised
Note: The first two specs, test what is really Rails' functionalities. However as we are monkey patching the pluralize method, I thought it was appropriate to doble check it
[1]https://crowdin.com/project/consul
