Examples of fallbacks?

[pselden]

There is mention of support for providing fallbacks -- locales: ['fr-FR', 'en'], but I'm not at all clear on how you'd actually use it.

In the one example you show of using multiple languages for messages, you're explicitly passing in messages['en-US'] to the root component messages prop, so I don't see how you could ever have fallback logic when you're explicitly not passing in the messages of the other locales.

[ericf]

Yes, this is a good point — the story around fallbacks for the message formatting is not something that we've fully flushed out. But the fallbacks will work correctly for Number and Date/Time formatting, as those end up delegating to the built-in Intl APIs

[pselden]

Would you accept a patch to add an option to make getIntlMessage return "" when the message is not found instead of throwing? This would just be a stopgap until a proper fallback solution could be fleshed out.

[StoneCypher]

@pselden and I just started chatting about this on IRC.

Might be nice to have fallback strategy configurable at create time. undefMesg: 'throw' would work as today, : {kind:'log', fallback: '['fr-FR'], default: 'foo'} would allow error messages to console, pull from French if possible, and return a fixed string if not (default to en-US and empty string if not provided respectively,) {kind:'ignore',...} would behave like 'log' but without the console behavior, and undefined would act like throw to keep old code from breaking.

Another nice thing about that approach is it's easy to extend if other behavior is needed.

[StoneCypher]

I would be willing to do this if it seemed sensible to people upstream

[ericf]

@StoneCypher I don't follow what you're suggesting.

@pselden I don't think having silent "errors" — the case of an empty string — is the right idea.

Imagine a label for a button, in English that's "Save", but you're rending the page in French and you don't have a translation for that message. If the fallback strategy was to insert "" as the button label, then you'd unknowingly be making the page unusable to the French user.

What we've recommended teams do in the past is have their build system merge the collection of translated strings with the default locale strings so that there's a value for every message ID, even if it's in a different language. In the example above, that page, rendered in French, would simply have an English "Save" label in the button.

We'd like to expand on this idea to make it easier to handle fallback string messages in apps. But I'm in favor of having explicit errors rather than "succeeding" silently which would unknowingly make the page unusable.

[StoneCypher]

@ericf I'm suggesting that the library be configurable at instantiation to let the developer choose the desired behavior, and recommending a mechanism theretowards. I'm also recommending a set of defaults which models what I believe you're suggesting as primary behavior, which I agree is correct for most cases, and which will maintain current behavior if configuration isn't added.

There are cases where you actually do want it to come back with a default string if no translation is provided. One example is the way Microsoft helps developers find translatable strings in apps: their system has a dummy language which returns text with strike-through characters over it, so that you can see visually what isn't handled yet.

[caridy]

Guys, loading the messages in fr and in en for some users just to have a fallback mechanism is not realistic for production system. as @ericf mentioned, this is suppose to happen during the build process where you have the domain of locales that your application is suppose to support, and you have all messages in all language that you can preprocess (we call this completion process) to produce a valid list of messages that are required by your application for each supported language, this will guarantee that the "save" button (from @ericf's examples) will alway have a message that can be rendered accordingly.

We will work on providing guidance and probably a set of tools to support this use-case.

[caridy]

... also, if you really want to implement a runtime fallback, u just need to create a shim for the formatMessage helper, to massage the message before propagating it into the real formatMessage implementation.

[StoneCypher]

k

[mschipperheyn]

@ericf I also don't think providing empty strings is the way to go. However, in the Java world the accepted and imho best solution is to have a flag that allows you to configure message processing so that in stead of an exception, the requested key is returned (e.g. 'ui.button.save'). Having an application fail completely just because of a missing text imho is ridiculous.

[Dakuan]

@mschipperheyn Agree completely, we are going to have to run a fork for now, see #56

[caridy]

@Dakuan, @mschipperheyn, I like the example of the "Save" button from @ericf, and a console.log just does not make the cut for us. The reality is simple, if you throw, and you provide a way for people to prevent that by implementing something custom, everyone has the ability to do what they want. But if we warn instead, what about those who want to enforce very strict rules, like we do at Yahoo?