X.Net makes xIUA available as free Open Source. We do, however, provide internationalization consulting services. This is where we intend to make our money. We can provide expertise, if needed, for help with xIUA, ICU or other internationalization issues.
Even though we designed xIUA so that it can be used unchanged, it is intended to be incorporated into your application code. This makes it very different from most software especially in terms of support. To solve the support problem, we designed most of the code to be fairly simple and straightforward. If you find code that is not clear, let us know, we intend to expand the documentation and improve the internal comments.
Since we use this code to help implement ICU for our clients we had to develop it anyway. Why deny it to others who are comfortable with ICU development and have no problems integrating it into their own code? We have found that helping others generally comes back to help you. One user may implement xIUA and not use our services but they may recommend us to someone else who needs them. It is no loss to us if someone uses the code and not our services because, in all likelihood, they would not have used our services in the first place.
We have found that many clients have staffs with few internationalization engineers. To truly make globalized software work all developers and support staff must program to a set of standards that ensures that the applications will continue to be enabled for easy localization. To be successful at his task, a set of development tools and standards must be developed that the staff is comfortable using. There is no one right way. Standards are often based on the individual company corporate culture.
xIUA allows a client to provide a set of tailored interfaces that cover the common functions used by most programmers in a simple easy to remember interface. On the other hand, it leaves the way open for programmers to use ICU application interfaces directly for fuller and richer functionality.
Based on our experience we find that many clients like the setlocale style interface. You set the locale to a desired locale and all of the locale-based functions use that locale until the locale is changed. However they need a locale manager that is thread safe. For many applications it is more than just a convenience. It is almost impossible to change almost every API in an application to carry the locale information. So how can an application call ICU with the current locale in a sub function if the locale is not passed? xIUA uses thread locale storage for multi-threaded applications and a static pointer for non-threaded applications. It has structures for thread specific and locale specific values. So it not only tracks locales but character sets, time zones and other values.
In the process of installing Unicode support, many client prefer to migrate from a code page environment to Unicode. They want to be able to change the code first and make sure that it all still works, then update the core and databases to Unicode and and then the client workstations. In the case of Web servers they may not have any choice since many users have not upgraded to Unicode based browsers such as IE 5.x or Netscape 6.0. Even if the application is fully Unicode, if it is truly cross platform, different platforms implement Unicode differently. They may use UTF-16, UTF-32 or UTF-8.
xIUA solves this problem by providing a set of functions that work identically in UTF-16, UTF-32, UTF-8 and code page. There were two approaches to this type of support, dynamic and static. We chose to implement the dynamic approach because it serves both functions and users can strip out unwanted code more easily than adding it to a static design. It was designed to be used either way you can either call a function that expects the data to be in the current locale format or call a function that expects the data in an explicit format.
Parallel functionality for different function is provided in two different ways. Very complex functions like collation are implemented by converting to UTF-16 and calling the ICU functions. Other functions like strtok are implemented separately for the four different data types. The code page versions of the code support multi-bytes character sets. In this case they also offer the added advantage of being thread save which most strtok implementations are not. xIUA also provides an alternate implementation of the ICU UTF-16 u_strtok_r until the current bugs are fixed.
Applications also need consistency. For example, systems are difficult to debug if each collation call uses different parameters. Also if you had to change the parameters to upgrade from ICU 1.6 to the new collation in ICU 1.8 is would have been easier to change in one or two places rather than change the code every place you used collation. This is why many clients wrapper the more complex operations. For simple operations like u_strcmp they may call ICU directly but for more complex operation they want a strcoll like operation that is not only configured to the house standards but uses the locale manager. This style of programming allows the internationalization engineers who understand the implications of the collation parameters to set the standards for the general programming staff who can use familiar functions.
Some xIUA function wrappering replaces the ICU wrapper functions. For example, the string converter functions were developed first for use with ICU 1.4. The next release of ICU will probably fix the major problem with the ICU supplied functions. The ICU functions do not have a consistent way of adding string null terminators. xIUA uses the same approach that is implemented in ICU 2.0. While this code might not have been written if we had started with ICU 2.0, the functions still integrate better into the overall xICU design and offer some minor performance and functional advantages. Some clients might want to remove the xIUA code if they use ICU 2.0. This is the advantage of xIUA in that it can be tailored to the specific installation.
The other thing that xIUA offers is specialized functions. Some functions such as xiua_AcceptLanguage are dependent on internal ICU code changes that X.Net has contributed to ICU. Others like xiua_strtoupperInplace are special separate implementations that are designed to be used only when you cannot use the proper ICU based case shifting. If you are converting an application that uses strftime date/time formats you may want a function that will produce ICU date formatting strings. This involves retrieving the internal ICU data formats from the current locale resource bundle to interpret some of the strftime parameters. It makes no sense for everyone to develop his or her own version of this code. It also does not make sense to incorporate every possible user function into ICU.
We also did not incorporate all of the ICU related code we have developed into xIUA. For other functions you may need, contact info@xnetinc.com.
The test program as important as the other features. In not only validates that xIUA is working, but it can be used to test you changes before you integrate them into you one code. It also can be used to test ICU calls and test new releases of ICU.