Subscribe to this thread
Home - General / All posts - German localization file for v9.0.181.0

6,410 post(s)
#04-Mar-24 16:43

The old german localization is completely out of date. I didn't manage to follow the rapid development cycles.

And then I found changes in the "builder..." section, that didn't allow an update but needed a new start due to changes in parameters that I could not track.

I decided to skip the builder from localization completely. I guess the creators of queries need to use the english help system anyway. Feel free to add what you want.

As german translations tend to use much more characters than english I used an exel document to compare default and german texts with some additional columns that flag translations likely to exceed the length of the controls. I manually checked f6r some but you probably will find errors and bumpy translations. I add this excel file here.

There is a second worksheet ready for exported as unicode text.


Do you really want to ruin economy only to save the planet?


7,433 post(s)
#04-Mar-24 18:01

Thanks Klaus!



6,410 post(s)
#14-Mar-24 07:50

Please excuse me, I notice mistakes when using the localization. The most important one must be corrected immediately:

A name with an empty string does not lead to the default text as intended in the query builder. Therefore, here is a version of the file in which the corresponding lines are deleted so that the original texts appear.


Do you really want to ruin economy only to save the planet?


7,433 post(s)
#14-Mar-24 12:43




6,410 post(s)
#19-Mar-24 09:47

A question for the German-speaking users:

Manifold follows the philosophy that the user interface should feel natural to the MS Office user.

MS-Access uses the term 'Verknüpfung' for both 'Join' and 'Link'. Since these terms occur side by side in Mfd9 UI, we have to use them differently from MS-Access, preferably with the same word roots as a noun and a verb. What is your preference?


  1. einbinden/Einbindung
  2. verbinden/Verbindung
  3. verkoppeln/Kopplung
  4. verknüpfen/Verknüpfung


  1. verknüpfen/Verknüpfung
  2. verbinden/Verbindung

My preference is 1. + 1.

How do other popular databases handle this?

Do you really want to ruin economy only to save the planet?

Bernd Raab66 post(s)
#19-Mar-24 10:31

Hi Klaus,

I prefer the same 1.+1.

thank you for your efforts

448 post(s)
#19-Mar-24 10:56

Another vote for 1 + 1 here, for me that's the most unambiguous combination.

Thanks for all you work on this, Klaus.


7,433 post(s)
#20-Mar-24 06:02

When translating "join" that's a question for other languages in addition to German. The issue is that JOIN is a technical word in SQL, which like key words in other English-based languages such as C++ or C# is not translated.

So it's an open issue whether to translate "Join" as in the name of the Join dialog or just leave it in English because it implements an SQL join.


6,410 post(s)
#21-Mar-24 19:01

I took this in consideration too. In a similar case I have used the English 'layer' in the German GUI in older versions. This is used by other GIS and CAD software as well. In this version it is translated as 'Ebene' but still not consistent throughout all items.

There may be other terms, that should better stick to English. How do other international GUIs handle this ??

Do you really want to ruin economy only to save the planet?


7,433 post(s)
#22-Mar-24 07:22

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.

Manifold User Community Use Agreement Copyright (C) 2007-2021 Manifold Software Limited. All rights reserved.