As customers take on a more active role in national language adaptation, the process should be simple, using tools they are familiar with, Daniela Engert stated in her talk at NDC TechTown. They decided to use GetText in C++ where they provide tools and procedures for their customers to provide translations.
Engert mentioned that they want their customers to be a bigger part of the whole development process. With the opportunity of their – at least optional – ultimate decision about the “language” (national or regional language, jargon, terms, script) the application communicates with them, they are increasingly less passive consumers:
We need to be aware of the needs of our customers to take part in this process, and learn to abandon some control over what we thought to be our private playground, bound only by our company culture and upbringing in our wider environment.
If we expect customers to work with us on a product that satisfies their needs and meets their expectations, we should make the whole process as simple as possible to people outside of our inner circle, Engert said. What we may perceive as “simple” and “easy” might just reflect a very particular world view, she explained:
For example, we might see an XML file with all the necessary information for the language translation process as “perfect”, albeit wordy. But customers and all the people involved at their site like end users, professional translators, or the like, will most likely perceive this as gobbledygook with arcane and obscure rules, possibly outright frightening.
There is no “blessed way” of doing it, there are rightfully no related functions in the C++ standard library, and there is no “standard” library that fulfills the needs. Instead, we have the choice of multiple libraries from both C++ and C, Engert said, so we then need to figure out which one suits us best.
There are solutions available that come with a rich enough ecosystem of tools and information sources that can guide us. Some of them are pretty specific to a subset of programming languages or communities. These are great because their gravitational pull helps defend their selection, Engert said.
Some tools are more geared to a wider audience, Engert mentioned. This is part of the landscape where you might find a solution that fits possibly all applications (and their dependencies) that you might intend to adapt to more languages than just one:
Such solutions tend to be more open to inputs from communities outside the programmers’ guild. They often have a richer tooling ecosystem and more sources for information at different levels of understanding the problems. That’s good for our customers, too.
They chose to use the GetText tools in their company, Engert said, to develop a feature in e.g. C++ with little to no translation in mind, in a language they preferred. Tools that come with GetText then extract all those strings that require translation and put them into a container text file with all the already existing translations.
Engert mentioned that they let their customers come up with translations of their own taste, using their preferred procedures and tools. Or they do it themselves if the customer chooses so. Tools build the artifacts that they incorporate into the application and deploy to the machines at the customer site (they are a company that builds machines). People can then select one more UI language when working with the machine, Engert said.
The GetText facilities became standardised this year, after a decades-long history and widespread use in the industry, Engert mentioned. They take advantage of other standards like Unicode and the information available there about how to handle languages and their peculiarities like language forms dependent on quantities, she concluded.
InfoQ interviewed Daniela Engert about doing natural language adaptation.
InfoQ: How can we involve customers in national language adaptation?
Daniela Engert: Timely involvement and short development cycles are more likely with the least possible entry barriers for people that are much less affine to the world of IT than we implicitly are. Rather choose something as simple as a text file with the least possible amount of rules to follow.
Ideally, a customer can modify such a file with any text editor at hand, with a small chance of introducing errors. And if they do, like using e.g. MS Word as their preferred tool, we can quickly undo it without loss of information. Ideally, we can give them tools that feel like all the other tools they are already familiar with.
InfoQ: What will the future bring when it comes to national language adaptation in C++?
Engert: I can see no appetite in the committee to incorporate something like that into the C++ standard library. Besides alluding to language translation in some proposals, I am not aware of any substantial efforts or even proposals to widen the target area of C++.
Many of the committee members – like myself – are volunteers with little to no support from their employers. Our resources and our energy are limited. That’s the reality of most ISO languages with no company backing. C++ was always meant to be a tool for implementing libraries, tailored to certain applications and particular needs. Let’s keep it this way. The language itself is expressive enough, powerful enough, and dynamic enough to fulfill current and future requirements.
