Email from customer (I’ll keep them anonymous unless they want to chime in):
…
I have several questions and I would really appreciate it if you have time to answer some of them.
1) In your post "http://blogs.windowsclient.net/rob_relyea/archive/2009/03/25/xaml-in-net-4-update.aspx" you mention a WPF localization review. I'm really curious about the results J. Are there any plans for a different/better localization support for WPF?
RR: short term, our plan is to convert our x:Uid based localization to support XAML or BAML. This would allow a few things. A) it would allow using the technique in Silverlight XAML. B) it would enable VS or other tools to do similar things to ASP.NETs “meta:resourceKey & Tools/Generate Local Resource”. We continue to want to hear feedback from customers in this area.
2) Is beta 2 api complete regarding xaml, or will there be changes for rtm? You mention featuers like "BamlReaderAsText" and "BamlWriter", which I can't find in the beta 2 release.
RR: The API is mostly complete. There aren’t major changes post-Beta2.
BamlWriter is not shipping in .NET 4. BamlReader as text is Baml2006Reader created with Baml2006ReaderSettings.ValuesMustBeString… we affectionately call this “BRAT” mode. We have 1 major BRAT bug that we are still attempting to fix before we ship…
3) What is the current WPF localization process at Microsoft, for example for Visual Studio or Blend? Which tools do you use? (probably not locbaml ;-) )
RR: Microsoft uses its own homemade localization tool. We adapted baml localization into this tool with a plugin that we call PomBaml – both locBaml and pomBaml call into the same APIs in PresentationFramework to Extract and Merge values from/to BAML. Instead of extracting to .csv and merging from .csv, pomBaml extract to the loc database and merge from the loc database. We’ve learned a lot from the localization of Expression and VS and plan to improve the techniques to improve things for internal and external localizers of BAML.
4) BamlLocalizer needs to load assemblies. This requires me to handle the AssemblyResolve event. However, the AssemblyResolve event is not executed when my localization tool runs in the context of Visual Studio (AssemblyResolve doesn't work there). Are there any plans to change this behavior for BamlLocalizer, or any workarounds?
RR: we realize this is a major problem with our v3 (and now v4) localization story. We plan to address the assembly loading problem by moving off of the v3 BamlLocalization codepaths to use a new Microsoft.Xaml.Localization.dll codepath that will support XAML or BAML. As part of this we plan to support XAML and BAML scenarios with less assembly dependencies. We have 2 potential strategies, a plan A and plan B, that we will be doing.
We plan on demoing Microsoft.Xaml.Localization.dll at PDC…and hopefully a CTP soon.
5) You mentioned that you were working on a new UpdateUid/Checkuid (http://blogs.windowsclient.net/rob_relyea/archive/2009/08/08/x-uids-should-we-have-updateuid-to-create-fewer-of-them.aspx). Will this be part of the .net framework, or are you going to publish this somewhere?
RR: At the PDC we plan on demoing a Microsoft.Xaml.Tools.dll that includes the initial work to make x:Uid more selective…and hopefully a CTP soon.
…