Support contextualized L10N Catalogs

[mwpowellhtx]

The nature of this question is a bit tricky, so we will decompose the question in two parts. First, by describing how L10N catalogs are discovered today. Second, by outlining what we aim to accomplish moving forward. We will do this in two parts following the opening of the issue.

Where things may get a bit interesting is in how we rather connect the dots with culture changes, dropping the composition root approach, enhancing toward a culture changed message, along these lines. But otherwise, overall, we aim to support these elaborated use cases.

[mwpowellhtx]

There is historical precedence established by gettext, whereby localization are enumerated in by the global path Locale\<culture/>\LC_MESSAGES\<DomainName/>.mo. Subscriber .mo files are to be distributed as content under this scenario in the application relative path, i.e. ".\Locale\...". We do aim to respect this approach in the default localizer implementation.

[mwpowellhtx]

Consideration for future directions involves at least two scenarios in which we connect the dots with a domain name and its corresponding culture driven L10N assets. In both scenarios, we shall facilitate catalog resolution using the Stream oriented constructors (ctors). The first is, .mo assets may be contained in the available assembly binaries, as proper dotnet manifest Resources. The second is that .mo assets are distributed as content, however diverging from the historical LC_MESSAGES precedent. We think either of these approaches is not unreasonable to assume. This is the first consideration.

The second part of this overall use case, is to facilitate contextualized L10N scenarios. We think it not unreasonable to isolate various localization scenarios based on Window, Control, etc, as the case may be, facilitated by WPF XAML resources. Resources, we think, at the time of this writing, is perhaps the best way to convey context, but we will see what works best in the overall analysis.

We may additionally support Enum specific use cases in which we know about enumerated values and their set of DisplayAttribute enabled annotated use cases. This will require further careful consideration along similar lines, deciding what qualifies as a "DomainName", etc.

Mapping "DomainName", we think that probably class names, perhaps full names including namespace paths, are the best choice for doing so. Perhaps with character replacements for namespace delimiters, i.e. underscore ('_', rather than '.') for obvious reasons, especially when resolving WPF assembly Resources. Such an approach would extend across the range of use cases, including Window, Control, and Enum types.

The challenge assuming an approach such as this is potentially in conflict resolution, when and how we coallesce the appropriate catalog context. View, view model, properties being the preferred basis, followed by Enum, enumerated values, being the natural extension, as appropriate, all of which defaulting in the area configuring the application at the Program.cs level.

[mwpowellhtx]

Issue more or less sorted out. Should be good to go, sans some unit, integration testing. Will re-open if we encounter any semi-major snags in that area.