For most documentation teams, the question of language comes up at the moment a translation is needed. A new market opens. A customer requires the manuals in their language. The team contracts a translation provider, sends across the source documents, receives the translated versions, and publishes them. The work feels like a mechanical exchange — input English, output French, German, Japanese, or whatever the target may be.
This works well enough for some kinds of content. For GIS documentation, it often produces translated documents that are technically correct and practically inadequate. The reason is that translation and localisation are not the same thing, and GIS work happens to be one of the domains where the difference matters most. A translated document that has not been localised will be readable to a native speaker of the target language, and will still feel subtly wrong to a user actually trying to do their work.
What translation does, and what it stops short of
Translation, at its most basic, converts words from one language to another while preserving the meaning of the source. A competent translator does this fluently, capturing nuance and idiom rather than producing the wooden literal versions that automatic tools sometimes produce. The output reads as if it had been written in the target language, not as if it had been mechanically converted from somewhere else.
That is the floor. Translation can stop there, and many translation projects do. The translated documentation is readable, the user can follow it, and the company has met its commitment to provide content in the local language. By the measure of “did we translate the documents,” the project succeeded.
The measure that matters more, especially in GIS, is “does the documentation actually work for users in this market.” That measure asks more than translation alone can deliver. It asks about the assumptions baked into the source material, the conventions of the local profession, the regulatory and standards environment that the local user is operating within, and the units, examples, and references that the user expects to see in their own work.
Why GIS is unusually affected by this
Geospatial work is shaped, more than most domains, by national and regional context. The reference data is national. The standards bodies are national or regional. The legal frameworks for what you can do with spatial data are national. The professional conventions — how a planning application is structured, what a cadastral record contains, how addresses are formatted — vary by country, often substantially.
This means a GIS documentation that takes its examples, references, and assumed context from one country and translates them into another country’s language is doing only half the work. The reader, who is fluent in the language of the translation, opens the documentation and immediately sees that the examples do not look like the data they work with, that the references are to standards they do not use, that the regulatory context is foreign to them. The documentation is in their language. It is not for them.
A few specific places where this shows up:
Coordinate systems. The British National Grid is meaningful to a UK user and meaningless to a Spanish one, who works with a different national grid. A documentation that uses BNG examples translated into Spanish is harder to use, in practice, than the original English version would have been, because the Spanish reader cannot map the examples onto their actual data.
Address formats. Address structures vary by country in ways that affect every operation involving addresses. A documentation example built around a UK postcode does not translate cleanly into a country with a different postcode system, or no postcode at all. The example needs to be re-anchored in a format the local user actually encounters.
Data sources. Authoritative spatial datasets are national. Ordnance Survey for the UK, IGN for France, OS Norge for Norway, Geoscience Australia, and so on. A documentation that walks through how to load Ordnance Survey data is not made useful for a French audience by translating the prose into French. The data source itself has to change.
Regulatory references. GIS work in many countries is shaped by regulatory frameworks — planning law, environmental protection, data protection, accessibility requirements. These frameworks are usually national. Documentation that references them needs not just translation but adaptation, because the equivalent framework in the target country may have a different scope, different terminology, or different applicability.
Standards bodies. While organisations like the OGC produce international standards, the way those standards are adopted and supplemented varies by country. The documentation needs to reference the locally relevant adoption, not just the international parent.
Units and conventions. Metric and imperial. Comma and decimal point separators. Date formats. Currency. These are small details that compound. A documentation that has been translated but not localised in these details quietly signals to the reader, line by line, that this was not really written for them.
What proper localisation actually involves
Done properly, localisation is a meaningful project. It involves several activities beyond translation.
It involves a content review of the source material with the target market in mind. Which examples need replacing? Which references need substituting? Which assumptions in the source content need to be made explicit, or revisited, for the target audience?
It involves working with someone who knows the local market. Not just a translator, but a subject-matter expert in the local geospatial context. The right person is rare, but they exist — a local GIS professional with an interest in writing, or a translator with a geospatial background. The investment in finding them pays back in documentation that genuinely works for the market.
It involves restructuring, where the original content structure does not fit the local context. A “Getting Started” guide built around a particular national workflow may need to be rebuilt entirely for a different national context, not just translated. This is more work than translation, and it is the work that turns a translated product into a localised one.
It involves ongoing maintenance. Localised content is not a one-off project. Each release of the software requires the localised documentation to be updated, in ways that preserve the local adaptations rather than reverting to translated versions of the new English. This is a real cost. It is also the cost of treating localisation seriously rather than as a checkbox.
The middle path that sometimes works
Full localisation, with all of the above, is expensive. For some markets — large customer bases, strategic importance, regulatory necessity — the investment is justified. For others, the company will not bear the full cost, and a middle path is the practical answer.
That middle path is to translate the bulk of the documentation faithfully, while localising the parts that matter most. The Quick Start guide is fully localised, with local examples and local data sources. The reference sections are translated more directly, because they describe the software’s behaviour rather than the user’s workflow. The conceptual sections are partially localised, with the underlying concepts preserved and the examples adapted.
This is not as good as full localisation, but it is meaningfully better than pure translation, at a fraction of the cost. The choice of which sections to fully localise can be guided by where the markets are most affected by national context — typically the introductory material, the workflow guides, and anything involving authoritative data.
The version that does not work
For comparison, the version that does not work is the one that gets shipped most often. The source documentation, written in English with British or American assumptions baked into it, is translated word-for-word into the target language. The examples remain British or American. The data sources remain British or American. The regulatory references, where they appear, remain British or American. The reader is asked to do a substantial amount of mental translation themselves, on top of the linguistic translation that has already been done.
This is the version that satisfies the contractual obligation to provide documentation in the local language while quietly failing the user. It is also the version that produces support tickets at higher rates, lower adoption in the local market, and the perception that the software was not really built for users outside the source country.
The short version
Translation converts the words. Localisation adapts the content. The two are different, and for GIS documentation the difference matters more than it does for most kinds of software. Reference data, regulatory frameworks, coordinate systems, address conventions, standards bodies, units — all of these are national or regional, and all of them appear throughout typical GIS documentation. A faithful translation that has not been localised is readable in the target language and still not really for the target user. Proper localisation costs more than translation. It is also the difference between documentation that meets a contractual requirement and documentation that actually helps users do their work.
