0 comments
.NET 
The final session I attended at the last day of the BUILD Conference was about building Metro Apps that target multiple languages. Windows 8 uses a preference list of UI languages that can be configured by the user. It is very similar to the list of languages in the internet browser.
The way Metro Apps are localized is very different from the current way .NET applications are localized. Instead of using satellite assemblies all resources are added to the package and a special resource manager locates the resources in the application. The nice thing about this setup is that ANY file can be localized. This means that next to having localized strings in RESW files, you can have a completely different window or user control for each or a specific language. You store them in special folders such as en-US and nl-NL.
The bad thing is that there is no generated class anymore so you cannot use data binding to get the resources, instead you either use the API or assign a x:Uid to the controls that need to be localized and at run time the resource manager will look up the value and replace the appropriate properties. This causes two things I do not like:
- No Blendability/designer experience. The work-around for this is providing a default value. E.g., <TextBlock x_Uid=”MyTextBlock” Text=”Designer text”/> and in the RESW file you would need to specify the value “Hello world” for the MyTextBlock.Text key.
- All current XAML code that was written for WPF, Silverlight or Windows Phone 7 is not compatible. So migrating Views to Metro Apps can be a lot of work. I asked if Windows Phone 7 will move towards the same approach, which in my opinion is the best way, but unfortunately the people from Microsoft were not allowed to comment on this.
So a good move in getting a better workflow for localizing Apps unfortunately not compatible (yet) with the other XAML targets.