Here at TrustBearer, we’re working on reworking the underlying pieces of our software to provide services which are required for full treatment of internationalization issues from cultural sensitivity to language translation. Fitting such an infrastructure onto a vast existing system of hardcoded, interlinked modules which span multiple (programming) languages and techniques on several platforms is a challenge, but we have come a long way to eventually realizing the goal of true international support.
Issues of Internationalization
The most obvious issue of internationalization is the language in which the user interface is presented; if your audience only speaks French, or perhaps just as importantly prefers to speak French, then you need to offer a user interface in French. Secondary issues can carry much more subconscious weight, however: as individual cultures have risen and separated from one-another across the planet, even in the age of international commerce and communication that the Internet conveys, specific communities still carry important symbols, ideas, and values which are intrinsically and uniquely their own.
The meaning of colors varies from one society to another, as does the importance of iconography. For example, the dagger (†) bears similarity to the Christian cross (which it should, since that was part of the original meaning conveyed in its use) and should be used carefully, even in purely typographical meaning, to avoid unintentional religious connotations. This sort of care is often given nary a second thought by those responsible for internationalization strategy, and it’s important to address it just as evenly as one addresses language. On the subject of translation, there are many things which carry over along with the baggage of verbal communication: formality, dialect, the hints and subtleties that individual words carry both inside and outside of specific contexts, all of these come into play with deciding on a technique for providing the infrastructure with which to provide international support for a software system.
There are four fundamental systems in TrustBearer’s overall product ecosystem: the web plugin with dynamic device support, the browser, static web content, and the server. We have chosen to implement three components which satisfy the translation needs of all four pieces.
Translations are conducted using a very simple macro language inspired syntactically by TeX. It allows placement of separately translated arguments in arbitrary order (to facilitate support of languages such as German which have different or flexible word order structures) and automatic construction of quotation marks (to handle nested quotations build from separate translations substituted as in the previous remark). Because of the nature of the system, new extensions can be added but this will not complicate the writing of a translation module: the goal is to allow our customers to be able to modify these to substitute their own language if they see fit.
Static Web Content
The exact same translation module drives a compile-time tool to create static versions of web pages, style sheets, and so forth which support individual cultures. This step occurs automatically using pkgBuilder, the tool used throughout TrustBearer for building all systems we produce. The result is a collection of HTML files, one for each culture which is supported. Customers are then free to select from the available languages to deploy, and to use their webserver’s rewriting capabilities to send e.g. their Norwegian users to index.no.html rather than index.en.html. This provides a balance between computation time required and flexibility offered; while TrustBearer’s clients no longer have the capability to retranslate pages without any extra work, their servers will not be constantly working to provide the latest translated version when such is very unlikely to change with any notable frequency.
The core TrustBearer server, which we simply call “the daemon,” rarely provides information directly to the user. Rather, it contains a lookup system to check incoming error attributes against a database and return a corresponding message which is meaningful to the humans who will diagnose or work around problems. For quite some time, the daemon has used the client’s language (as provided by their browser) as a means of looking up these human-readable messages. Little to no extension of this system is necessary to continue to provide error and status messages to users in the languages in which they are accustomed to communicating.
The Road Ahead
While the architecture of the internationalization system is fairly set, the work on retrofitting this into the existing system is just beginning. Over the next few months, we will be externalizing strings and incorporating the new methods of translating messages dynamically. TrustBearer’s head engineer, Eirik Herskedal, is from Norway and will be providing a pilot translation into his native tongue for us to begin testing with. The testing and quality assurance process will take the longest, but features in the translation system (for example, XXX’ing out strings for which no translation exists) will make this process smoother. After several months, we expect these features to enter beta use by our most prestigious customers. Then, with the consideration of customer feedback, these features will be added to all of our future deployments.
Software systems that work with the cultural complexities and sensitivities of their users, rather than against them, are woefully under supplied. At TrustBearer, we value the differences in our users, and wish to better cater to the multi-faceted nature of their individual societies. By starting this long work to implement internationalization features in TrustBearer products, we begin down the road of providing our system in a way that works best for you, whoever and wherever you may be.