18 December 2008

Building Multilingual WPF Applications

Heads up - this blog has now moved to a new site. You can find this particular post at http://tech-and-arts.com/tech/building-multilingual-wpf-applications/.


Daniel said...

Hello, I just stumbled upon your blog post while searching for something else. I'm sorry to say, but the XML syntax you are proposing is *very* bad practice:

[?xml version="1.0" encoding="utf-8" ?]


Here's a much more standard-compliant alternative, for which a Schema/DTD/RelaxNG/etc. specification can be defined:

[?xml version="1.0" encoding="utf-8" ?]

[LangName code="EN"]English[/LangName]

[LangName code="AR"]العربية[/LangName]

[LangName code="DE"]Deutsch[/LangName]

[LangName code="EL"]Ελληνικά[/LangName]

[LangName code="ES"]Español[/LangName]

[LangName code="FR"]Français[/LangName]

[LangName code="IT"]Italiano[/LangName]

[LangName code="JP"]日本語[/LangName]

[LangName code="KO"]한국어[/LangName]

[LangName code="RU"]Русский[/LangName]

[LangName code="SV"]Svenska[/LangName]


I hope it helps, Regards, Daniel

Daniel McGaughran said...

Hi Daniel, thanks for your feedback.

I understand that specifying the language code in an attribute (instead of being part of the element name) would be cleaner and more robust when the XML is shared between multiple components or separate applications.

If I'm guessing rightly, the main problem of using the existing syntax is that the schema would need to change with every new language added. A secondary issue is that extracting the language code elegantly requires regular expressions instead of accessing an attribute - hence the talk of being "standard-compliant".

In this example (a personal project where I'm doing a lot of learning through practice), I didn't see putting language codes into attributes as such a priority because:
=> The XML is stored inside the application as an embedded resource, so is not open to being easily corrupted by users or external systems - therefore I don't believe it is as crucial to define XML schemas for such strict validation.
=> The XML is consumed by only one component - the application in which it resides. Conveniently, the application roughly knows what to expect in the XML, so doesn't need a schema to strictly enforce this.
=> The XML itself is never sent outside the application (e.g. to file or another software component). It exists purely as a means of storing data to be loaded into memory on startup and converted into the appropriate internal data structure.

Having said that, it is possible that the XML would need to be refactored in the future to use attributes to store the language code, depending on what the scenario is. In other applications it may very well be necessary. In general, my preference is to refactor as needed when more details become known, rather than to spend too much effort up-front fortune-telling (analysis paralysis) or over-engineering when there is a likelihood of receiving little or no pay-off.

Your feedback is very helpful. In the post I tried to convey that these exact details as I implemented them would not necessarily be the best way of doing things in another particular project, but the general idea would be a helpful option to meet the goals stated.

Kind regards,