globalizejs
<FormatMessage> less error prone
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?
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.
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: https://github.com/yahoo/react-intl/issues/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.
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.
Replying you is on my TODO list. In the meantime, this could be of interest: https://github.com/rxaviers/globalize-webpack-plugin/issues/25 and https://github.com/jquery/globalize/issues/575.
