Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

PeterCon_MSFT

PeterCon_MSFT PeterCon_​MSFT

Niner since 2011

  • Build world-ready Metro style apps using XAML

    There were some questions about fallback among regional variants. E.g., the app has strings for en-US and de-DE with de-DE as the ultimate fallback; but the user's preference is for en-AU. In this case, the en-US strings will be used. The system will look at the user's preference and infer a fallback chain that allows for regional variants. So, in the above example, it will assume a fallback chain as follows:

    • en-AU  (user's first choice, but not available in the app)
    • en        (region-neutral asset -- not available in this app)
    • en-*      (any other regional variant -- will pick up en-US in the app)
    • de-DE   (app's ultimate fallback)

    Note that, as explained by Tim Heuer, you don't have to declare the resources using a specific regional variant language tag. You can, instead, use a region-neutral tag like "en". And you can use any combination of specific-regional variants as well as a region-neutral variant.

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

    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.

  • Tools for building Metro style apps

    @Athanasios:Pacific Daylight Time (UTC - 7).

  • Platform for Metro style apps

    @Ian2: If you click on the video div in the page, you won't be able to view full screen. But notice the links just below that allow you to stream WMV or MP4: these will play in a separate player on your machine, such as WMP or Zune, which would allow you to go full screen.