Not doing so might cause the following test to use translations for
only one locale. This scenario happens if the previous test executes
I18n.reload!, which resets I18n.config.backend's "@translations"
instance variable.
So, the sequence could be as follows:
1. The previous tests sets `@translations = nil`
2. This test stubs `available_locales` to `[:en]`
3. `@translations` gets only translations for `en`
4. The following test doesn't find translations for Spanish and fails
There where two issues with the current implementation:
- There was a possible duplication between looking up the language name in key "locale" and in key "i18n.language.name"
- The "default" option was not being picked up, as the fallback always returned the default locale's translation, "English"
With this implementation there is only a single place to put the language name: i18n.language.name. I think this place is easier to find and understand for Crowdin translators than a "locale" key hidden in general.yml
If the translation is not found we display the language key, instead of English, which makes more sense to me too 😌
Solution based on recent comments[1] on a related I18n issue
[1] https://github.com/svenfuchs/i18n/issues/365#issuecomment-419263847
We set `I18n.locale = :en` before each test, and so creating a new card
will automatically create English translations.
So visiting the Spanish page won't show the card, since no Spanish
translation exists for it. If we visit the klingon page after doing so,
the last used locale (Spanish) will still be used, and so the test will
fail.
Specifically creating Spanish translations instead of the English ones
makes the translations visible when visiting the Spanish homepage.
* Store the last used locale in the session
* Allow home page to be identified in helpers even when containing
parameters
* Create initializer to explicitly set the available locales, the
default and the load_path
