ISO/IEC JTC1/SC22/N805 2001-05-10 Title: Market opportunities for the i18n API standard Source: Keld Simonsen, project editor Introduction The following is my estimate of what the market oportunities are for the 15435 project on an i18n (internationalization) API. I18n is most efficiently implemented as an operating system service. In this way all applications will have access to the information for the user, and if the applications use the same i18n data, the user will experience a uniform behaviour wrt. his i18n preferences. Some bigger applications, like office suites and databases, do their own i18n. Many smaller applications are not internationalized, in that they only are programmed for one language, and does not take care of other i18n issues. I will take a look of the market opportunities of the use of the i18n api standard in these areas. Operating systems. Some important operating systems in the IT world today are: 1. Microsoft Windows (NT, ME, 2000, 98, 95) 2. Unix/linux 3. Mac 4. IBM/390 5. embedded systems - no OS. i18n functionality is required in systems that interact with users, which are all of the above. However, Microsoft systems have traditionally been difficult to influence, as the company has made their own i18n specifications. These specs are in some cases (NT family) much more elaborate than what is currently provided with the draft of 15435, while for some other environments (95, 98, ME etc.) the functionality is not much different. My expectation is that the evolution path for the latter systems would be to use the extended functionality from the NT systems, and an API standard for i18n would only be used for possible inspiration. In the UNIX/Linux market, there is a good adherance to ISO standards. Other WG20 standards have been implemented in some environments, eg via the GNU C compiler and library, and many of the APIs in the current 15435 draft is implemented in this library. So there is a good chance of the API standard to be used in these environments. There are a number of other candidates for a standard i18n API in these environments, notably IBM's ICU, which may be a prime source for an update of the 15435 API. In the Mac market, the move to a POSIX based kernel in OS X would bring development in the UNIX/Linux market, with market opportunites for 15435 as outlined above. For IBM/390, there is some chance of getting the 15435 APIs implemented, or at least that the functionality will be investigated for similar implementation. I am not aware of IBM APIs that are on the level of the NT APIs wrt support for Unicode etc. In the embedded world, i18n overhead may be considered substantive, and therefore not utilized. In cases where the functionality is needed, there is scarce support, and there is a chance that 15435 will be welcome. Given that the GNU C library is used in these environments, and already has implemented many of the functions, the opportunity for 15435 is good here. Applications Bigger applications that are implemented for several platforms, often provide their own i18n functionality, as they cannot rely on an adequate or uniform set of functionality from the underlying operating system. They may also provide wrapper functions to interface to the i18n services of the OS, while implementing additional required functionalty in proprietary functions. Examples are office suites and databases. The market opportunity here for the 15435 standard is minimal here. As it is costly to build ones own i18n APIs, and associated data, and furthermore maintain this, many smaller applications have no i18n functionality, or only limited functionality. For these applications, there should be a good market opportunity for the 15435 APIs, especially in combination with the associated data base on POSIX or 14651 and 14652. Conclusion The market opportunities of the 15435 standard lies mainly in the UNIX/Linux/Max OS X world, and to some extend in the embedded world. Even here there is competition, but as many of the 15435 APIs are already implemented and employed in these environments, 15435 is very likely to have a good impact here. This is valid for system applications and GUI applications written for these environments. For bigger multi-platform applications it is however not likely to be used, as these often have their own i18n APIs. As these systems are employed of about 10 % of the users today, there is a significant opportunity for the 15435 standard, especially compared to what one could expect.