Wpf: Proposal for localization support

[wjk]

I was reading through the various issues around localization support for WPF apps. After reviewing the PBT code, as well as other sources such as XliffTasks, I am going to suggest the following approach to tackle this surprisingly difficult problem:

• Change PBT to support multiple language tags in the UICulture property; today it supports only one. (This value will presumably become a semicolon-separated list. If there is only one value in the list, there should be no change to the behavior.) Each language tag in the list will get its own culture-specific .g.resources file. These will be compiled into satellite assemblies using the normal MSBuild mechanism,
• Add a target to Microsoft.WinFx.targets that iterates through the GeneratedBaml items and uses System.Windows.Markup.Localizer.BamlLocalizer to apply the localized text to them. A custom task will have to be written to accomplish this. This should occur before the SatteliteResourceGeneration target is invoked, so that the modified BAML files can be picked up and included in the *.g.resources file automatically.

Localized Content Specification Format

The main issue I have yet to solve with this proposal is what file format we should use to specify the localized content that will be substituted into the generated BAML files. XLIFF is certainly a good choice, but it is also rather verbose and not really conducive to hand-editing. However, if we use the same technique that XliffTasks does, there would be no need to edit the XLIFF files for a single-language application; ther would only be XLIFF files for the foreign languages. As with XliffTasks, there would be a task that can be optionally run that sychronizes the content of these files with the content of the XAML.

Challenges

• How would the build find the appropriate XLIFF file(s) given a XAML item? Presumably, the localization files would be stored in a subdirectory next to the original XAML file, as with XliffTasks. I'm not quite good enough at MSBuild to create a robust solution to this problem.
• How would we avoid cluttering the localization files with properties that _could_ be localized (per the LocalizationAttribute), but don't _need_ to be localized for this project? One way we could do this is assume that if a localizable property was not specified in the XAML, then it doesn't need translation. We could also go by the value of the Localization.Attributes and Localization.Comments attributes; if the property in question is not specified in either, we might want to omit it from the XLIFF file.
• The BamlLocalizer class has not yet been open-sourced. We would need to wait for that to happen before I could start work on this task.

Any input is appreciated. If/when we get this spec finalized, I'd be happy to start on a PR. Thanks so much!

[vatsan-madhavan]

/cc @ryalanms

[ryalanms]

@wjk: This is an excellent proposal that aligns somewhat with our internal plan and many of our existing work items. I'll follow up.

In the very short term, I'll work on open sourcing the locbaml tool. We may have to place the locbaml source in the wpf samples repo temporarily, until identifying a good place for it. Thanks.

[ryalanms]

https://github.com/Microsoft/WPF-Samples/pull/84

[ryalanms]

Port LocBaml WPF application localization tool to .NET core #85