Lot of us have worked in the past on localization of windows forms and web forms and HTML content. One thing that comes to our help to support localization are RESX files, which makes life simpler for developers language experts and Project Manager to ensure the quality of process to perform localization. Let me also thank examples available on internet to help in this area. What about localization of XML and XSL?.
During localizing XML, xml element tag names should not be localized and xml element value needs to be localized. In the same way attribute names should not be localized and attribute values needs to be localized. Adds to complexity whether all xml element values need to localized event if the user never sees them? what is the best way to communicate the same to the language translation expert? How to make sure that language expert modify things that need to modified and not the things that should remain intact?
So I started looking at advantages of using RESX files and .Net for localization and how to achieve the same advantages for localization of XML and XSL
- They are independent of code
- RESX file contains identifier, value and comments
- They can be organized either as one file or multiple files depending on the project need.
- Developers can build them using Visual studio they make it simpler to enforce constraint that identifiers need to be unique.
- Language specialist can use special tools that would take the RESX file and display the tentative user control to language experts
- RESX files have comments that can also be used effectively for change tracking.
- .Net provides satellite assembly support to handle them effectively.
- Support for Fallback language in absence of language string for a specific identifier
The initial approach to XSL was create a XML file with all text contents termed as Language XML. This file was based on schema that supported content node with elements identifier,value and comment. The identifier element maps the value element with the need of XSL and the value element contain language specific strings and the comment element is for tracking and other usage. There shall be one XML file per each language . With this approach XSL needs to contain the identifier and not the test contents and we called this Generic XSL. While implementation, we assumed that the XSL would load XML files based on the language content needed. The language expert shall work with the language XML which contains no code. we decided to build a prototype to test this.
Before localization the prototype performed the following Content XML + XSL =>HTML Report/XML data. For localization purposes, we modified the same as Content XML + Generic XSL + Language XML = HTML Report/XML data. The localized prototype was slower than the previous prototype and there was no fall back language support in this approach. It became more trickier and slower when multiple XSL and multiple XML were part of the process create output. We tried approach that would take us close to IBM strategy with some tricks
In addition with the observation that RESX file was in XML format, we decided to language XML in RES format so that developer can populate the same using Visual studio and the language specialist treats this similar to any other RESX file. We build an utility to perform Generic XSL + Language XML(RESX) = Language XSL. This utility performs the operation in compile time or pre-packaging time so there is no effect on the runtime performance. This also allowed the developer to organize the RESX files the way they want. We have Fallback language support also.
Then the prototype equation translated in to Content XML + Language XSL = Language HTML Report/Data. We found the performance to the same as the original prototype and all the stakeholders developer, tester and language specialist were happier.