How do other international GUIs handle this ??
I have only looked into this to research possible automatic translation solutions, so I can't say authoritatively, but can only offer a subjective impression based on that research. The short answer, is that they handle it in a hit or miss way. But a longer answer might help meditate on some of the issues involved... The difficult cases seem to be "terms of art", that is, words with special meaning in GIS. Such special meanings are often different than as used in other applications, even broadly generic applications such as those in the Microsoft Office suite. You can't just see what Microsoft does and copy that. Manifold looked into doing that. Going back 20 years Microsoft has a huge corpus of full translations for the Microsoft Office suite and other of their applications that have been fully translated into astonishingly many languages. In theory, those could be harvested automatically and applied to Manifold's translation glossary. That's fair game, as while you can't copy somebody else's application, it's perfectly legitimate to observe that they use the word "Ebene" in German to mean "layer" and do the same. But that approach is not as effective as AI-powered automatic translation, the main reasons being a) the specific meanings found in GIS and b) the many internal contradictions in various Microsoft translations in use, and c) it's easier to let the Internet-wide AI's do the work for you of harvesting what Microsoft has translated, along with billions of other translations. Back to specific meanings in GIS: A classic "term of art" in Manifold is selection as used to mean something similar to but different from SELECT in SQL. It's not an exact match to how other applications use the word "select" in their GUIs. Another example case in Manifold is the word "area", which is used to refer to one of the three basic vector objects. In English the word has two main meanings, referring to a specific region or demarked place, and also referring to the 2D size of some region, usually expressed in areal units such as square meters. Different languages often have different words for those two meanings, so which is picked depends on the context of use. Other GIS GUIs tend to have their own nomenclatures. Those usually overlap to a great degree to Manifold's but are different in some cases, like "polygon" instead of "area", or which simply do not have equivalent capabilities such as selection in Manifold. The various GIS packages all have their own issues with translations. Many of them simply haven't translated most of their interfaces to very many languages, and it's common practice to leave the hard parts untranslated, in English. What they all (including Manifold) seem to have ended up doing is a mishmash of individual translations where the specific terms chosen were up to the individual translator who took the lead in doing a given language. Of all the GIS packages that have been translated that I've looked at, the best translations seem to be Esri's. They've spent a lot of money on human translation. Unfortunately, Esri also has such a very high proportion of uniquely goofy and archaic terms, such as "feature set" and "arc", that automatic scans of Esri translations are not as effective as modern AI translations. However, even with Esri you see a lot of variability and internal inconsistency, same as with the world leader in a wide range of translated applications, Microsoft. You can see how that comes about, because if you've ever run a big language translation project you can see how when you commission translations from three or four different translators who are totally fluent in English, very knowledgeable in database, programming, applications, and GIS, and who are native language speakers in the target language, well, they often will come up with very different translations for the same words. Manifold has done some trial translations like that. Those were done using contracted workers from gig sites, but despite the low outlay of cash the result was nonetheless useful and significantly better quality than expected, and it provided data points as to where variability most often occurred. As you might expect, variability tended to be higher for words and phrases that were "terms of art" unique to Manifold or which were more context dependent, like selection or "area". It's interesting to note that similar variability (except with wildly greater variability) seems to occur with similar words when using AI powered translation engines. That's one reason a while back I posted a note asking how people felt about changing "area" to "polygon". That is because there are some reasons to believe that choosing different terms within Manifold in an attempt to reduce contextual ambiguity could reduce the variability and improve the quality of translations, especially AI translations. As with many things in computing, it's clear that AI powered translations will become the dominant technology. But as with seemingly everything else about AI there's the big quality paradox to deal with. That paradox is that given enough training effort it is straightforward to create an AI solution that produces results that mostly give very good results, often to the 95% or even 98% level. But getting an AI that doesn't generate 2% errors seems to require a thousand times more effort, so much so that it would have been better not to use the AI. People who have spent days debugging AI-written code that is so plausible it is very difficult to find the lies it tells know what I mean. Such errors don't matter in image-generation AIs, where if 2% of the pixels are "wrong" that won't be noticeable so long as the 98% of them are right, in that faces don't have missing eyes, etc. But in GIS you can't have an AI that gets 2% of the SQL or scripts wrong, or results in geoprocessing that gets 2% of the parcels or parcel attributes or JOIN wrong in a tax application. In automated translations you don't want to have an AI that mistranslates top level command names wrong 2% of the time. In fact, when it comes to GUI translations the current AIs seem to get 10% to 20% of them wrong in the case of Manifold commands. In AI powered translation experiments, Manifold has tried a variety of tactics, such as less ambiguous English terminology. What seems to work best is special training, such as the use of custom word, phrase, and context glossaries, to constrain and guide the AI in its "automatic" translation. In each such case the creation of such custom glossaries to where the AI result is as good as a manual translation has required more work than simply doing a manual translation. Besides the experience gained with AIs and GUIs, doing such experiments is not a loss even when they are less efficient than manual translations for the GUI, because they help guide the really hard part of translating a product, which nobody, not even Esri, seems to have done thoroughly and systematically: translating thousands of pages of documentation. That's far harder than translating the GUI. But if you create a good glossary with, say, a thousand terms in it, you can end up with an AI that does a pretty decent job. [That still leaves the illustrations in a heavily-illustrated documentation set like Manifold's, which would require fully localized versions of Manifold for screenshots...] Even without a glossary the latest AIs, like DeepL, seem to have gotten much better at translating Manifold user documentation on the fly into European languages that use the Latin alphabet. It is completely realistic to use DeepL to learn and use 9 in any of the languages DeepL supports. Sometimes what DeepL comes up with is laughably wrong, but overall it conveys the gist and almost always the key details well enough that you can use 9 very productively based on DeepL translations. I think very quickly, within the next year or two, the holy grail of decent, on-the-fly translations of online documentation will be realistic, at least for major world languages. Besides the above, Manifold is continuing work to help better translations, including: * Additions to the existing localization strings, to cover those many strings used internally that currently are not localized, where English words are hard-wired into the code. Anybody who's done a big localization knows what I mean. * Ongoing improvements to the Quick Start guide, a shorter set of topics that are more easily translated, to make it more compact. * Moving screenshots to more language neutral illustrations (a very long term project...). * Continuing research on AI powered translations, hopefully one day resulting in automated AI powered translations of the GUI, so you could enter a default.ui.tx and out pops a decent localization. * Better planning for highly non-Latin writing systems. * Planning any future architectural changes/improvements with automated translation in mind. Unfortunately, what's really hard about translation is that part of GIS is where most GIS worldwide is done: using Asian languages with highly non-Latin alphabets. It would help if the tactics and strategies in support of automatic translation helped get better non-Latin translations as well. The above are all big challenges, of course, but at least these days the tools we have to help are getting very much better very rapidly.
|