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. 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.