Reach a worldwide audience by building a world-ready app

Play Reach a worldwide audience by building a world-ready app

The Discussion

  • User profile image

    There were a couple of questions at the end of the session regarding fallback and sparse localization. I just wanted to clarify some things in this regard.

    As Kip Knox explained, the developer can specify whatever language is the (ultimate) fallback for the app. Visual Studio sets a value by default, but you can change it to whatever you want to use in your app for the ultimate fallback.

    But there's a bit more to understand about how fallback works. Note that I said "ultimate fallback" above. The system can handle fallback between regional variants of a language automatically; the ultimate fallback is needed only when nothing is available in any regional variant for a language.

    The application resources get tagged (e.g. by folder naming "en-US", "fr-CA", etc.) to indicate what conditions they ideally apply to. The user's settings determine a runtime context. If the user specifies multiple languages, then that becomes a priority fallback list. At runtime, the resource infrastructure compares the available assets with the runtime context -- the user's preference list -- and comes up with the best match. But as noted above, this does not have to be an exact match.

    So, for instance, suppose your app has strings for fr-CA and en-US with en-US as the default, but the user's language preferences are for fr-FR: the best match for that user in this case will be the fr-CA strings. The ultimate fallback of en-US is not needed in this case because there is a better match.

    It's like the user said they use fr-FR, but then the system automatically builds up a fallback chain when that app runs as follows:

    • fr-FR
    • fr
    • fr-*
    • en-US

    In other words, if there is a string for fr-FR, that's the best match; if there's a string tagged fr, then that's the next best match; if neither of those are available but there's a string for any other French variant (fr-CA, or fr-CH or fr-BE...), then that's the next best match. But if none of those are available, then the system resorts to the app's declared fallback, en-US.

    One other point to note is that, when tagging your assets, you don't have to specify a regional variant of a language. For example, you could declare a set of strings to be "en" instead of "en-US" (or "en-GB", etc.); or "fr" instead of "fr-FR" (or "fr-CA", etc.) Note: make sure that the fallback you specify in the solution properties dialog uses the same tag as you use on your resource files: if you use a region-neutral tag such as "fr" for the resources, then set the tag in the dialog in the same way.

    Because the system will score other regional variants of a language higher than other languages (e.g. "en-US" is a better match for "en-GB" than "fr-FR"), you can do sparse localizations. For example, suppose you have 100 strings in your app and want to provide localization for fr-FR and fr-CA; and suppose that only 10 of those strings are actually different for fr-FR versus fr-CA. The system will work if you decided to include strings for all 100 resources for fr-CA but only the 10 that are different for fr-FR. In this scenario, if the user's preference is for fr-FR, then for those 10 strings the fr-FR versions will be selected at runtime, and the fr-CA versions will automatically be selected for the other 90. And this will happen regardless of what language was specified as the fallback language in the solution properties. If the fallback was specified as en-US and there were another 3 strings that aren't in either fr-FR or fr-CA, then only in the case of those 3 strings would the fr-FR or fr-CA user see English..

    One last point: whatever the ultimate fallback language is for the app, the system expects that there will be an actual string asset for 100% of the virtual string resources in the app. Any other language can be partially localized, however.

Add Your 2 Cents