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

<FormatMessage> less error prone #54

Open
beckend opened this issue Apr 7, 2016 · 4 comments
Open

<FormatMessage> less error prone #54

beckend opened this issue Apr 7, 2016 · 4 comments

Comments

@beckend
Copy link

beckend commented Apr 7, 2016

It kinda sucks to have a failing application when you translate with FormatMessage and a path does not exist on a certain locale, can you not simply return path string "as-is" when a path is not found, and warn in the console that the path does not exist?

And another case when you translate
<FormatMessage locale='language_which_is_not_yet_loaded' path='some/path'>
You also get a failing application, possible to do a try catch in FormatMessage in components to make it simply return path string if error does occur and then warn you in console?

@kborchers
Copy link
Collaborator

Thanks for the feedback! I want to try to better understand your use cases and also pull in @rxaviers who is the expert on the Globalize side of this project.

In your first case, my gut tells me that this type of issue should be handled in your application rather than in react-globalize (actually Globalize since that functionality is just passed through). If I understand correctly, if you are doing a simple pluralization where your app translates something like "You own no books" where "no books" would be replaced by one of (one book, two books, a few books, many books) or what ever options you like for a particular locale based on a count.

Are you saying you would prefer your application continue working and display something like "You own some/path/that/can/not/be/found"? That seems like a bad user experience as opposed to using some default text that makes more sense and somehow handling the error on the application side.

In your second case, I would again suggest that displaying some default text in your application until the locale is loaded would be a much better user experience than displaying a path in your content and failing silently with warning.

If I am misunderstanding, please give more detail and also if @rxaviers has different thoughts or input I am happy to defer to his expertise in globalization.

@beckend
Copy link
Author

beckend commented Apr 8, 2016

I understand that's there are different approaches to this, but sometimes a working page with one fallback "warning" string is better than a full failing page.

I would like to link and qoute from react intl v2:
formatjs/formatjs#162

Automatic Translation Fallbacks

Another great benefit to come out of this approach is automatic fallback to the default message if a translation is missing or something goes wrong when formatting the translated message. A major pain- point we faced at Yahoo which every app experienced was not wanting to wait for new translations to be > finished before deploying, or placeholders like {name} getting translated to {nombre} accidentally.

Message formatting in v2 now follows this algorithm:

Try to format the translated message
If that fails, try to format the default message
If either the translated or default message was formatted, return it.
Otherwise, fallback to the unformatted message or its id.

One compromise I would think of is having globalize to have a setting for the fallback feature if they want to use it.

@kborchers
Copy link
Collaborator

I do think this makes sense and am not sure if Globalize has this feature but I would agree that it would be a good feature to add (option to return unformatted message possibly with some flag letting the app know the translation failed). Again, I defer to @rxaviers as to whether or not this is already possible and if it is, let me know and we can add to react-globalize and if not but Globalize is open to adding it, we should transition this issue to the https://github.com/jquery/globalize repo.

@rxaviers
Copy link
Member

rxaviers commented Apr 8, 2016

Replying you is on my TODO list. In the meantime, this could be of interest: rxaviers/globalize-webpack-plugin#25 and globalizejs/globalize#575.

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

No branches or pull requests

3 participants