Multilingual publishing that keeps export markets aligned.
WPML and translation for industrial websites is a configuration exercise before it is a linguistic one: shared technical facts are held once and rendered in every language, content that varies by market is governed deliberately, and the site gives search engines clear language and regional signals.
The work covers field-level translation settings across your content model, hreflang and URL structure, a workflow your translation supplier or local teams can work within, and verification that each language renders and indexes as intended.
WPML handles the technical side of multilingual WordPress well, but configuring it for an industrial site requires deliberate decisions: what is shared and what is translated, how market variation is governed, who owns updates to technical content when the source language changes, and how language targeting is declared to search engines.
The failure mode is familiar. A specification is corrected in the source language, four other languages keep the old figure, and the discrepancy surfaces when a customer in another market orders against the wrong number. WPML and translation for industrial websites should support accurate product information rather than create a second unmanaged copy of the site.
A WPML configuration separating shared technical fields from translatable content, correct language and region targeting, a translation workflow that connects to your supplier or local teams, and controlled handling of content that differs by market.
Alongside that: a language switcher and market entry behaviour that does not trap visitors in the wrong version, translated media and document handling for datasheets and manuals published per language, and a documented process for what happens to translations when the source is updated. See multilingual industrial websites.
The decisions that matter are made per field, not per page. In an ACF-based build every field can be set to translate independently, to copy once from the default language and then diverge, or to stay synchronised so it is entered once and rendered everywhere. Part numbers, dimensions, tolerances and pricing belong in the synchronised group; headings, application copy and imagery belong in the translated one.
Getting this wrong is expensive to undo, because a field set to translate has already been duplicated across every language by the time the problem is noticed. We define the settings against the content model before translation begins. See ACF flexible content and PIM and product data, since data fed from a PIM should be synchronised rather than translated.
Language versions compete with each other when the targeting signals are left at defaults. We set the URL structure deliberately, usually language subdirectories on one domain for consolidated authority, and configure hreflang with self-referencing and return tags plus an x-default for visitors outside your declared markets.
Where a group sells the same language into several countries, targeting has to distinguish region as well as language, so a German page written for Austria is not treated as a duplicate of the German page for Germany. See hreflang for industrial B2B websites and international SEO.
We configure the technical structure translated content publishes into and work alongside your existing translation supplier or local teams, so the linguistic work stays with the people who already do it while the platform makes publishing straightforward.
In practice that means XLIFF export and import for suppliers who work in their own tools, translation memory so recurring technical phrasing stays consistent across datasheets and product pages, and a queue that shows what is translated, in progress or waiting. Where machine translation is used as a first pass, it is reviewed before publication. See machine versus human translation for industrial B2B.
Code Industrial is the industrial B2B practice of Code Barcelona, an agency building corporate websites and digital platforms since 2015. The same strategy, design and engineering team works on every industrial project, from the first scoping session through to life after launch.
Different content needs different multilingual handling. WPML and translation work starts from that content.
What comes up when setting up multilingual WordPress for export markets.
No. The translation itself sits with a specialist supplier or with your local market teams. We configure the technical structure it publishes into, including the WPML language setup, field mapping and workflow, and manage how content moves from draft to review to live across languages.
We can integrate with a supplier you already use, export and import XLIFF for their tools, or set up WPML translation management if you prefer to run it in WordPress. Sourcing the translated text stays outside our scope.
Through field-level translation settings, so shared technical data such as part numbers, dimensions, certifications and contact details is stored once and rendered identically in every language rather than re-entered per language. Only fields meant to differ, such as body copy and application examples, are set to vary.
The second mechanism is change detection: when the source language is edited, affected translations are flagged as needing update so the gap is visible in a queue rather than discovered by a customer. See multilingual industrial website architecture for the content model this depends on.
Often, yes. Incorrect language and region targeting is a common cause of country versions competing for the same rankings, and correcting hreflang and regional URL structure is usually more impactful than any content rewrite.
We audit the targeting first, since a content fix will not help while the underlying signals point search engines at the wrong version. The audit covers hreflang reciprocity, canonical conflicts, sitemap coverage per language and whether any market is being redirected away before it can be crawled. See hreflang for industrial B2B websites.
Yes. WPML field-level translation settings work directly alongside ACF flexible content, which is how most of the structured content on our builds is composed. Each field can be set to translate independently, copy once from the default language, or stay synchronised across languages.
The setting has to be made per field rather than per component, including repeaters and nested flexible content rows, which is where undocumented builds tend to go wrong. We define and record those settings before translation starts.
Language subdirectories on a single domain suit most industrial groups, because authority earned by technical content accrues to one domain and the estate stays operationally simple. Country domains are worth the overhead where a market needs a distinct legal entity, a separate brand or independent hosting, and they mean building visibility separately for each one.
The choice is difficult to reverse, so we treat it as an architecture decision taken early with the SEO and IT stakeholders together. See multilingual industrial websites.
Documents are modelled as translatable media attached to the product or resource record, so a visitor is offered the version for their language where it exists and a clearly labelled fallback where it does not. Language, revision and issue date are held as fields rather than encoded in filenames.
That structure matters because industrial document estates grow quickly and are frequently linked from customer and distributor sites. Stable URLs and a documented fallback rule prevent the dead links that follow an uncontrolled document library. See technical documentation portals.
As a first pass, followed by human review, and with the technical fields excluded from it. Machine output is reasonable for descriptive and marketing copy in major European languages, and less reliable for safety instructions, regulatory wording and specialised terminology where an error carries consequences.
The configuration decision supports this directly: synchronised fields carrying specifications are never sent for translation at all, so machine translation is applied only to the copy where review is proportionate. See machine versus human translation for industrial B2B.
It adds database rows and translation lookups, and on a large multilingual catalogue that shows up in admin queries and uncached page loads before it shows up for visitors. The usual causes are string translation scanning too many files, unbounded language switcher queries, and object caching not being language-aware.
We size hosting for the number of languages and catalogue volume, configure caching per language, and review query performance as part of launch. See website performance and managed hosting.
WPML and translation connects closely with these related technology pages.
A multilingual site where markets have drifted apart, or a new build going multilingual from the start. Tell us your languages and markets and we will set out how we would approach WPML and translation.