Fix interface when locale is something other than English #561
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Before i18n v1.1.0, i18n.fallbacks would eventually hit your default_locale. That was changed without warning and broke everything ruby-i18n/i18n#415. This restores the previous behavior by explicity falling back to English.
The translated name will, of course, come up empty, and a failed import will take down the app.
cbothner
force-pushed
the
non-english
branch
from
12ffc9f to
e86a305
Compare
Otherwise, signing in in later tests can be messed up, since the button still says "connexion"
cbothner
force-pushed
the
non-english
branch
from
918f3fc to
e339704
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
How wonderful: two bugs in one 🕷🦂
First, the
i18ngem upgrade to 1.1.0 changed the behavior of locale fallbacks, removing the default locale from the default list of fallbacks. We were relying on that, and when a tag had nodisplay_namein the current locale, we were serializingnull. The interface broke when rendering the keywords index on the catalog page and when loading the image backgrounds for category tags.Second, at some point
react-intllocale data started being exported as an ES module, (aka with a default export), instead of a baremodule.exports = ..., andaddLocaleDatastarted failing, and falling back to English. This meant that the leaf translated components were expecting English messages regardless of the locale set inIntlProvider. Of course, this was fine in English mode,and all the messages failed to load otherwise.
Needless to say, this PR adds a test that would have caught either of these bugs.