Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fallback locale does not fork #59

Closed
akolpakov opened this issue Sep 22, 2020 · 4 comments
Closed

Fallback locale does not fork #59

akolpakov opened this issue Sep 22, 2020 · 4 comments

Comments

@akolpakov
Copy link

In case if we use locale that does not presented. For example:

loadMessages({
  'en': {
    welcome: 'Hallo, heute ist der {date}',
  }
})

And we use GlobalizeProvider with localeFallback: "en"

When user is in locale sv for example, we get the following error:

[RNGlobalize] CLDR data for the selected language/locale has not been loaded!

The reason, that in the code we have:

cfg.locale = (cfg.fallback && findFallbackLocale(cfg.locale)) as string;

It means if cfg.fallback is "en", we still try to findFallbackLocale for locale sv which does not exist

We need to change it to:

cfg.locale = (cfg.fallback && findFallbackLocale(cfg.fallback)) as string;
@akolpakov akolpakov changed the title Fallback local does not fork Fallback locale does not fork Sep 22, 2020
@joshswan
Copy link
Owner

As documented in the types and the docs, localeFallback and cfg.fallback are meant to be booleans currently, simply enabling or disabling the auto-fallback behavior (e.g. en-US -> en). Changing the implementation like this would break existing code and require a major version bump. I think a separate config prop that's opt-in would be a better solution.

@akolpakov
Copy link
Author

I got you.

But how to avoid the case when user's locale does not exists in the loadMessages?

@joshswan
Copy link
Owner

Yeah I think this is a valid enhancement, just need to figure out the implementation details. Looking into implementing a new config prop defaultLocale as we speak. Will update shortly.

@joshswan
Copy link
Owner

Released v4.4.0. Setting defaultLocale="en" on GlobalizeProvider should now behave as described above (i.e. it won't throw in the event of an unknown locale and will instead use the en locale).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants