Tool to help software developers create internationalized programs more rapidly, accurately and cheaply
Original Publication Date: 2009-Apr-01
Included in the Prior Art Database: 2009-Apr-01
This article describes a way to improve the current state of software tools used to develop "globalized" software, i.e. software that supports different languages and locales. It shows a way to accelerate the process by giving the original code-developer early access to tools that provide language-translation, rather than leaving everything to a post-processing stage after code-development is complete.
Tool to help software developers create internationalized programs more rapidly , accurately and cheaply
Current software tends to be written in one language, typically English, by developers who will create text-messages and other textual information such as labels for buttons, window-titles etc in that same language. The current global market demands that programs be able to display this information in the language most suitable for the end-user, so a process known as Globalization (G11N) must be done. An important feature of G11N is that IBM* maintains databases of messages which have already been internationalized, and the translators (who are not the original developers) make use of this database to reduce duplication of effort. This database is not readily accessible by developers.
Developers writing new code will separate-out the text-strings that will need translation into a separate resource-file (and these may hold plain text, XML, etc).
Developers have no way to know in advance about any alternative messages, which have the same or similar meaning, which have already been translated into other languages.
So the "problem" is that the G11N process as applied to new code is inefficient, fundamentally due to lack of integration of existing resources into current development processes.
Drawbacks with existing G11N process
The existing G11N process is suitable for pre-existing code, but is sub-optimal for new code for the following reasons:
1) Many new messages in the new code will be essentially identical to messages in other already-internationalized programs. Effort will later be expended by the translators deciding whether each new message is "identical in meaning" to any of the pre-existing internationalized messages already in their repository. Where a translator is not sure whether the "new" message is identical to an existing message, the decision may be made to translate it as-is in order to be sure of not changing the meaning. Where there WAS an identical-meaning message already translated, this will result in duplicated hence wasted effort.
2) The same text may have 2 or more different translations; e.g. the string "Hydraulic ram" could easily be translated into "Water-loving sheep" by someone fluent in the target foreign language, but who has no engineering-domain knowledge and fails to realise that this refers to a mechanical component. Similarly, does "Enter" mean "Press the Enter key", or "Enter the room" in a virtual-reality context? Domain knowledge is crucial to accuracy. For this reason it is desirable to allow the developer to take a greater part in translation decisions than is done at present.
3) If problems are revealed after the post-development translation they have to go back to the developer to be corrected.This can be rather cumbersome; it would be better to provide an instant guide to the developer that tells him immediately what requirements there a...