Q: What is the System Localizer?
A: The System Localizer was formerly desktop software newly brought to the Web intended for use by developers plus marketers, sales people, product managers, and any other non-technical person whose decisions influence the user interface for a software application. It offers an online private database containing content decisions and notes. It enables creation, translation and personalization online, and also has the ability to export scripts for translation with appropriate context to facilitate high quality translations, and then re-import the translated data back into the database. It has the ability to create talent scripts appropriate for voice recording. It has a suite of reports and tests which can be used to verify content before it even reaches the client application software. And, at the push of a button, it extracts all the design and content decisions to create a Runtime Engine Extract File.

Q: Where can the System Localizer Runtime Engine be used?
A: The System Localizer Runtime Engine can be used on Linux, Macintosh or Windows. The Runtime Engine can be used by practically any software application, from embedded to enterprise scale, with almost any operating system and any hardware.

Q: How does the Runtime Engine interface with my application?
A: There are a variety of interfaces available. The proprietary core Runtime Engine algorithms are built in C for speed, efficiency, and portability. The low-level C interface was designed to enable embedded applications to have maximum flexibility and control; however it does require a certain level of programming expertise. Ever higher level interfaces are being developed, including the C-Session interface, Java JNI interface, RealBasic interface, .NET interface, and Service Oriented Architecture interface.

Q: How is the Runtime Engine tested?
A: The Runtime Engine Regression Test Suite was developed in conjunction with the Runtime Engine itself. With the click of a button, it regression tests the Runtime Engine using over 2700 distinct tests, validating that information will be properly served up to the application when requested.

Q: Will the Runtime Engine slow down my application?
A: The Runtime Engine was designed to replace hard-coded presentation layer logic, which, because its very nature, tends to be fast. Optimizations based on metrics and code profiling enables the Runtime Engine to be as fast as, if not faster than, an existing application’s presentation layer when bound into the application as a library. We’ve seen results where application speed actually increases as the result of using the Runtime Engine.

Q: What choices are available to integrate the Runtime Engine with my application?
A: The Runtime Engine can be integrated using a statically linked library (common in embedded systems), a dynamic/shared library, or a remote server solution on separate hardware using industry standard protocols such as RMI, DAO, EJB, SOA, TCP/IP, and more.

Q: What resources does the Runtime Engine require?
A: For core functionality, the Runtime Engine loads everything it needs from disk into memory during initialization – and what it needs to load is very small (nominal extract file size is less than one megabyte). No databases or other external servers are needed. In addition, part of the metrics available to the client application is how much heap memory the Runtime Engine has allocated during its initialization.

Q: How do you detect and prevent memory leaks?
A: Each time the Runtime Engine allocates memory, an internal counter is incremented. Then, when the memory is freed, that same counter is decremented. In this way, the Runtime Engine is aware of whether a memory leak has occurred and will inform the client application.

Q: What effect does the Runtime Engine have on code maintenance?
A: Once the Runtime Engine is integrated into the application, the amount of coding effort required to make changes to the presentation layer goes to zero, assuming that no new business functionality is added. The result of this is that an application can be made ready for release in a single linguistic language or dialect, and once distributed, additional languages, personalizations, and customizations can be added without recompiling or re-distributing software.

Q: I’m a developer. Will the Runtime Engine make me obsolete?
A: Absolutely not! Programmers are critical to the successful deployment of an application; the difference is in problem scope. Today, you as a programmer must write the code to handle linguistic and cultural variations like what conjunctions are appropriate for the fifteenth Russian number set, or how to concatenate the direct object properly in Japanese based on whether the thing being described is square (like faxes) or round (like voice mails). The Runtime Engine solves those types of problems by removing them from your application so you do not have to worry about them. The Runtime Engine enables you to do what you do best: using technology to create solutions.

Q: I’m a marketer. How does the Runtime Engine help me?
A: Today, if you want to make cosmetic changes to the application, oftentimes it is necessary to go through a laborious bureaucratic process in order to engage developmental resources, because in today’s world, developers are the ones who make code and data table changes. With , marketers can make the changes themselves via the System Localizer. The changes are then extracted and loaded into the Runtime Engine, which can make them available to your application instantly. Thus, managers, marketing, sales and even clients can make changes to the look and feel of your application without requiring any development whatsoever.

Q: What are these 14 best practices that I keep hearing about?
A: Through years of assisting software companies localize their software, @International Services determined 14 best practices of programming which, in any other context, are excellent ideas and the only way to go. However, in terms of localization, these 14 practices end up making more work for developers because as more linguistic languages are added, work-arounds and patches must be applied in order to accommodate the various rules and grammars of real-world languages. Because the Runtime Engine has the expert knowledge concerning localization, the client application is no longer constrained – the Runtime Engine has bridged the gap over these practices so that they can be used elsewhere with impunity.

Q: What types of data can the Runtime Engine handle?
A: Literally anything. The most popular request is for the Runtime Engine to return lists of audio file names or text string in various encodings, and the personalization capabilities also return picture, video, movie or Flash file names. Everything from the various encodings of text to binary files like PDF files can be returned. However, for large binary files, it is generally more efficient to store the files in some externally managed location.

Q: Will using the Runtime Engine make troubleshooting my application more difficult?
A: It’s just the opposite. In today’s world, the distinction between the client application and the presentation layer is rarely made – less so from a testing perspective. Because the presentation content is abstracted from the client application, it can be tested independently using the Runtime Engine Utility Suite, which include a report program and a diagnostic tool. Now, if your application displays something that is not correct, you can quickly and easily find out if the issue is with the content design or with the application’s rendering.

Q: How does increase the bottom line?
A: To put it simply, through division of labor. By providing product managers and marketers the ability to modify and validate content without requiring your business application, changes can be discussed, tested, and polished without developers being involved. Also, because the application no longer has code to support localization, the time it takes them to identify real bugs in the application goes down drastically, as does the chance of introducing a bug as the application is enhanced or languages added.

Q: Why can’t our developers do this themselves? Why do we need this solution?
A: In order to create a good design that will be maintainable in the long term, you need to understand the requirements up front. The more comprehensive and accurate the requirements, the better the design will be. The rules for linguistics have evolved over hundreds of years, and the resulting mish-mash of arbitrary, incoherent, and illogical rules make it exceedingly difficult to collect requirements and write an application that handles multiple languages in a low-maintenance manner. Typically, as more languages are added, the cost of development goes up exponentially. This cost manifests in the time required to modify the existing code to handle the new linguistic rules, as well as regression testing time to ensure that the new changes have not broken any existing language paths. With the System Localizer, once the first language is implemented, the development cost to add a second language is identical to the development cost to add the 200th language: zero budget.