System Localizer Basics

GlobalConcat System Localizer
Runtime Engine excerpt:
Client Application Programming Interface Guide

The GlobalConcat System LocalizerTM is a localization and customization process that is designed to enhance software applications by handling the details of localization and customization so that the programmers of the application can concentrate on enhancing business logic and improving technical aspects of their application to outperform the competition. This document describes the application programming interface of Runtime Engine Concatenation Engine and Application Feeder, used by client applications to assist in the presentation of information to end users.

The Runtime Engine is a software component that makes localization and customization decisions on behalf of a client application. This decision-making capability provides a tool for creating world-class presentations and interfaces in some 200 different languages and dialects, with an almost infinite number of sub-versions of any language, including the language in which the application’s interface was originally developed.

At the core of the Runtime Engine are a set of patented algorithms that have been developed over the course of a decade as a result of working with a variety of companies around the world with product lines ranging from telephony to kiosks to web sites to marketing materials. Around this core functionality, @International Services has developed a variety of interfaces and products that help applications perform globalization and localization tasks. By using the Runtime Engine, the client application’s development staff can enhance their application without needing knowledge of the vagaries and nuances of foreign languages and grammars, nor concern themselves with customer preferences for wording, menus, and other presentation data. Development resources are then freed up to focus on how to increase the product’s technical value instead of investing time in learning thousands of presentation details such as how to properly express number sets in Japanese, or whether a customer prefers to say “Store Associate” or “Customer Service”.

An existing client application will need a one-time modification to use the Runtime Engine. Once the integration is complete, localizing a client application for another language is as easy as distributing an updated configuration file. No re-compilation is necessary.

New applications created using the System Localizer methodology are more maintainable and scalable because they are architected to take advantage of the capabilities of the Runtime Engine, and once development is complete, further localizations merely require a new configuration file.

1.0    Runtime Engine Implementations

The Runtime Engine can support client applications ranging from embedded systems up to enterprise systems. There are three implementations available to a client application, depending on need.

The embedded implementation is a C-only approach in which the Runtime Engine is compiled directly into the client application either using a static C library or obfuscated source code. While J2ME implementations are under consideration, they are currently not supported.

The library implementation is the most common, with an operating system-dependent dynamic library being made available to the client application. For windows C/C++ development, the Runtime Engine Concatenation Engine appears as a DLL bound at runtime. For unix/linux flavors, it appears as a shared object library (*.so). A JNI layer is available in this model to support J2SE and J2EE environments.

The server implementation provides the most universal interface (TCP/IP), and provides the safest solution in highly dynamic enterprise environments because of application isolation. However, this solution has the highest latency per run-time transaction and may require additional hardware resources. While the client application can be anywhere in this model, the Runtime Engine Server must be on a machine with either the Windows, Solaris/SunOS, Linux, or BSD operating systems.

The Runtime Engine Core Algorithms are designed for speed, run-time efficiency, and low memory usage.

Runtime Engine Interface Architecture

Access to the core algorithms is a low-level C interface that is designed for maximum flexibility and extensibility. For those C developers who are not experts or do not have the time to learn the complex details of Runtime Engine data organization, a GlobalConcat utility is available that auto-generates wrapper code based on data contained within an extract file. This wrapper code can be delivered with each extract file, and presents a simplified C interface to the client application to enable faster integration.

The JNI interface wraps the low-level C interface to present a purely object-oriented model to the Java developer, taking advantage of the standard Java libraries. Neither micro-edition nor enterprise-edition components are required by this interface.

The Runtime Engine Server is a stand-alone application that contains the core algorithms and is accessed via sockets.

This document describes the low-level C interface, the auto-generated wrapper interface, and the JNI interface.

Design Overview

The GlobalConcat System Localizer processes are extensive; at a high level, the logical steps relevant to understanding the integration of the Runtime Engine Concatenation Engine into an existing application are as follows.

1.    Analyze the existing client application and identify presentation touch-points; these are places where a customer might hear or see localized and/or customized information. Specifically, these are the distinct places in the client application where code must be written in order to present data to an end user. Examples are telephony sentences, HTML frame data, or screen text.

2.    Assign a unique identifier to each presentation touch-point, following special naming conventions that simplify long term maintenance and facilitate globalization. This unique identifier is called a Touch-Point ID in the Runtime Engine Interface, or TPID for short. Note that in the GlobalConcat User Interface, this identifier is called a “sentence name”, or “screen entry”, depending on whether the Audio Feeder or Text Feeder is in use.

3.    Using the GlobalConcat System Localizer Design Process (not described in this document), determine the optimal presentation methodology for each presentation touch point and record this in GlobalConcat User Interface, which facilitates and manages localized and customized data related to the user experience.

4.    When the design of all presentation touch-points is completed, the GlobalConcat User Interface creates a Runtime Engine Extract File, containing proprietary rules and client-specific data related to the touch points. This is the previously mentioned configuration file that the client application will need to take advantage of the Runtime Engines capabilities.

5.    Modify the client application to call the Runtime Engine each time it needs to process or display presentation data (i.e., at each touch-point).

6.    For implementations other than the Runtime Engine Server Implementation, compile the client application and place the Runtime Engine Extract File in a known location so that it can be found during application initialization. This location should be selected to facilitate adding or updating Runtime Engine Extract Files as new languages are made available. For server implementations, configure the Runtime Engine server on its host system and place the Runtime Engine Extract File as previously mentioned.

7.    Store relevant audio files, media files, images, and any other presentation dependencies. As with the Runtime Engine Extract Files, selection should be made for maximum maintainability; future additions and/or updates are an inevitable part of any software life cycle. The naming conventions and directory structure recommended by the GlobalConcat methodology have been developed to minimize distribution errors, enable better inventory control of data, and allow reliable cleanup as presentation touch-points are removed from the client application.

8.    Test the client application and analyze diagnostics.

9.    The application is now localized and ready to ship.