+86 19937104978
Author:Kangdi 06-11-2026
Pain Patch OEM Multilingual Content Localisation 2026: Why Translation Is Not Localisation
You paid for a professional translation of your English site into Arabic, Spanish, and German, the pages went live, and enquiries from those markets did not move. This page explains the difference between translation and localisation for a pain patch manufacturer: the seven elements that must change beyond the words, the six technical traps in a right-to-left language, the hreflang configuration that decides whether the versions compete with each other, and a priority order for a manufacturer with limited budget.
By the end of this page you will know the 7 elements that must change beyond language, the 6 RTL traps that break Arabic versions, the 5-market localisation checklist, and the priority order for spending a limited localisation budget.
There is one distinction that explains why translated sites underperform, and it is worth stating plainly: translation makes the page readable, and localisation makes it trustworthy. A purchasing manager in Riyadh who reads a perfectly translated page that still quotes prices in US dollars, states lead times in a format they have to convert, lists certifications without their local equivalent, and shows a phone number in a format they cannot dial will not conclude that the page is badly written. They will conclude that the supplier does not really serve their market, and they will move on without sending the enquiry.
Bottom line. The seven elements that must change are currency, units, date format, number format, certification references, contact formats, and layout direction. Five of the seven cost nothing beyond an editorial pass. The two that cost money — layout direction for Arabic and certification references for each market — are the two that most affect whether a buyer believes the supplier is serious about the region. A manufacturer that localises those seven and leaves the prose in a competent translation performs considerably better than one that pays for literary translation and changes nothing else.
Table of Contents
- The 7 elements that must change beyond the language
- The 5-market localisation checklist
- The 6 RTL traps in Arabic versions
- hreflang: the configuration that decides whether versions compete
- What must not be translated
- Localising the decision-stage pages specifically
- Cost and priority order
- How to measure whether localisation worked
- FAQ: multilingual localisation questions manufacturers ask most
- About Kangdi Medical and our language versions
1. The 7 Elements That Must Change Beyond the Language
Each element below is something a buyer checks without consciously checking it. Getting it wrong does not produce a complaint; it produces silence.
| # | Element | What changes | What a buyer notices if it does not |
|---|---|---|---|
| 1 | Currency | State prices in the local currency, or state the reference currency and the conversion convention explicitly | They have to convert manually, and they suspect the price they see is not the price they would pay |
| 2 | Units | Centimetres against inches; kilograms against pounds; Celsius against Fahrenheit where the market uses it | A patch dimension in inches reads as an imported product with no local adaptation |
| 3 | Date format | Day-month-year against month-day-year; and whether the week starts on Sunday or Monday | A date written 03/04/2026 is ambiguous to half the world, which is a real risk on a shelf-life statement |
| 4 | Number format | Decimal comma against decimal point; the thousands separator; and the numeral system for Arabic | A quantity written 5,000 in a market that uses 5.000 reads as five units, not five thousand |
| 5 | Certification references | Name the local regulator and the local equivalent where one exists, alongside the international certificate | An ISO certificate with no mention of the local authority reads as a supplier who has not registered locally |
| 6 | Contact formats | International dialling code shown, WhatsApp availability stated, and business hours in the buyer's time zone | A number without a country code is a number they will not call |
| 7 | Layout direction | Right-to-left for Arabic and Hebrew, which is a layout change rather than a text change | An Arabic page laid out left-to-right reads as machine-translated even when the Arabic is perfect |
Elements 1 through 6 are editorial. They require someone to go through the pages and change values, which is a few days of work per language. Element 7 is technical and it is where most Arabic versions fail.
2. The 5-Market Localisation Checklist
The table below gives the market-specific requirements for the five markets that matter most for a pain patch exporter. It is not exhaustive, and each market has details beyond this, but it captures what changes the perception of whether a supplier serves the market.
| Market | Language and direction | Currency convention | Certification to reference | The detail most often missed |
|---|---|---|---|---|
| EU (DE, FR, ES, IT) | Local language, left-to-right | Euro, decimal comma in DE/FR/ES/IT | CE marking under MDR, plus the national competent authority | The EU authorised representative's name and address must appear, and it is a legal requirement not a nicety |
| GCC (SA, AE, KW, QA) | Arabic, right-to-left, with English often alongside | Local currency or USD, with the convention stated | SFDA for Saudi, MoHAP or the relevant health authority for the UAE | Arabic is not optional in most GCC markets for the label, and a site with no Arabic reads as a supplier who has not done the paperwork |
| LATAM (BR, MX, AR, CL) | Portuguese for Brazil, Spanish elsewhere, left-to-right | Local currency; Brazilian real and Mexican peso are not interchangeable | ANVISA for Brazil, COFEPRIS for Mexico | Brazilian Portuguese is not European Portuguese, and using the wrong variant is noticed immediately |
| Japan | Japanese, left-to-right | Yen, with consumption tax treatment stated | PMDA, and the distinction between medical device and quasi-drug | The quasi-drug category is unfamiliar to most exporters and it changes what claims are permitted |
| South Korea | Korean, left-to-right | Korean won | MFDS, and the distinction between drug and quasi-drug | The Korean quotation and contract conventions differ, and a page written in translated formal Korean reads as distant rather than professional |
The GCC row is the one where the gap between translation and localisation is widest, because the layout direction issue compounds the language issue. A manufacturer that translates the Arabic accurately but leaves the page laid out left-to-right has produced something that looks wrong to every Arabic reader, regardless of the quality of the prose.
3. The 6 RTL Traps in Arabic Versions
Right-to-left is a layout change, not a text change, and six specific elements break when a template designed for left-to-right is reused. Each is worth checking on any Arabic page.
| # | Trap | What goes wrong | What correct looks like |
|---|---|---|---|
| 1 | Navigation and logo placement | The menu stays on the left, so the reading order starts from the wrong side | Navigation and logo mirrored; the primary menu reading right to left |
| 2 | Numbers and units | Everything is mirrored, including the digits, so a quantity reads backwards | Layout mirrored, numbers remain left-to-right within the mirrored layout — this is the rule most often broken |
| 3 | Table column order | Columns are reversed, so "dimension" appears on the right of "value" and the pairs read wrongly | Either mirror the column order consistently, or keep the table left-to-right with a clear header — but not a half-mirrored table |
| 4 | Punctuation and parentheses | Brackets and commas render at the wrong end of a phrase | Use the Unicode bidirectional marks in the template so punctuation attaches to the correct side |
| 5 | Directional icons | Arrows, back buttons, and progress indicators point the wrong way | Mirror directional icons; do not mirror non-directional ones such as a clock or a checkmark |
| 6 | Font and line height | An Arabic font chosen for Latin text renders with poor legibility, and line height is too tight for the script | A proper Arabic typeface with increased line height; Arabic glyphs are taller and need more vertical space |
Trap 2 is the one worth memorising, because it is counter-intuitive and it is the mark of a page that was properly localised rather than mechanically mirrored. In a right-to-left layout, the overall reading direction reverses, but numbers stay in their conventional left-to-right order. A quantity written "5,000" must still read as five thousand, not as the reverse. A page that mirrors the digits has applied a blanket transformation rather than understanding the language.
Trap 6 is the one that most affects perceived quality, because it is immediately visible. An Arabic page set in a Latin font looks amateur regardless of the accuracy of the translation, and the fix is a font choice rather than a content decision.
4. hreflang: The Configuration That Decides Whether Versions Compete
Multiple language versions create a technical risk: without correct configuration, the versions can compete with each other or be treated as duplicate content, which suppresses all of them.
| Element | Requirement | What breaks |
|---|---|---|
| Reciprocal declaration | Every version declares every other version, including itself | A set where one version omits another is invalid, and an invalid set is often ignored entirely |
| Region versus language | Use a region when the content genuinely differs by region; use language alone when it does not | Declaring regional variants that serve identical content creates unnecessary fragmentation |
| Default version | Declare a default for unmatched languages | Without a default, a visitor in an unlisted country may land on a version chosen arbitrarily |
| Self-reference | Each page includes itself in the set | A missing self-reference is the single most common implementation error |
| URL consistency | Every declared URL resolves, with no redirects in the chain | A declaration pointing at a redirect is treated as invalid, which can void the whole set |
The self-reference row is the most common error and the easiest to fix. A set of four language versions where three declare the other three, and one declares only the other three without itself, is an invalid set. A validator will flag it, and some engines will ignore the entire configuration rather than the single tag.
5. What Must Not Be Translated
Some elements must remain in their original form because they are identifiers rather than prose. Translating them breaks matching, which is the mechanism that lets a system recognise your entity across markets.
| Element | What to do | What not to do |
|---|---|---|
| Legal company name in Latin characters | Keep it identical on every language version, with the local-script name as an addition | Do not let a translator render the Latin name into a local form |
| Certificate numbers | Reproduce character for character | Do not reformat spacing or separators to match local convention |
| Standard names | Keep the standard designation (ISO 13485, ASTM D3330) in its original form | Do not translate a standard into the local language and drop the designation |
| Product codes and SKUs | Keep as issued | Do not localise a part number |
| Chemical and ingredient names | Use the local pharmacopoeia name alongside the INCI name | Do not replace the INCI name with a trade name |
The legal name row is the most consequential. A manufacturer that lets each market's translator create a local rendering of the company name ends up with five names across five sites, which makes cross-market entity matching impossible and creates exactly the inconsistency problem that costs citations.
6. Localising the Decision-Stage Pages Specifically
The decision-stage pages — comparison, process, and Q&A — need more than language. They need the local context that makes the answer usable.
| Page type | What localisation adds | Why it matters |
|---|---|---|
| Comparison page | Local regulatory categories for each option, and local retail price bands | A comparison that says "OTC in the US" is not useful to a buyer in the GCC, where the category is different |
| Process page | Transit times to the local port, the local customs documentation set, and the local payment convention | A generic timeline is read as a supplier who has not shipped there |
| Q&A page | The questions local buyers actually ask, which differ by market | A translated Q&A answers the questions a European buyer asks, not the ones a Gulf buyer asks |
The process page is the cheapest to localise and the one with the most effect, because a transit time to the buyer's own port is a fact they can immediately evaluate. Adding three lines — the port, the transit time, and the documentation set — converts a generic page into one that answers a local question.
7. The Glossary: The Single Document That Prevents Drift
Every localisation problem described on this page has the same root cause: the local version is produced once, the English version keeps changing, and nothing links the two. The fix is a glossary, and it is the cheapest control available.
| Glossary section | What it lists | Why the translator needs it |
|---|---|---|
| Do-not-translate list | Latin legal name, certificate numbers, standard designations, product codes, INCI names | Prevents a translator from rendering an identifier into a local form, which breaks cross-market matching |
| Approved place names | The single approved rendering of each district, county, and region for the factory and registered office | Place names are the most frequent drift point, because several transliterations are defensible and each translator picks a different one |
| Regulatory term mapping | How each market names the device class, the local authority, and the equivalent of an OTC category | A literal translation of a regulatory term is frequently wrong, and a wrong term reads as a supplier unfamiliar with the market |
| Units and formats | The unit convention for each market, the date format, and the number format | Prevents a page that converts currency but leaves dates ambiguous |
| Approved claims | The permitted indication language for each market, taken from the label rather than re-translated | A translator re-rendering a claim can widen it beyond what is permitted, which is a compliance risk rather than a style issue |
The approved claims row is the one that converts a language problem into a regulatory one. A claim translated freely can become broader than the label permits, and a broader claim on a local-language page is a compliance exposure in that market. Providing the label language as a fixed string rather than as a phrase to be rendered prevents this entirely.
The glossary is maintained alongside the canonical facts page described in the entity consistency guide, and the two documents serve the same purpose: they give everyone producing content a single reference so that the facts do not diverge. A manufacturer with both has solved most of the drift problem structurally rather than by vigilance.
8. Cost and Priority Order
Localisation budgets are limited, so the order matters. The table below is the sequence we would recommend, and it front-loads the work that costs least.
| Priority | Action | Cost | Effect |
|---|---|---|---|
| 1 | Fix the seven elements on the existing translated pages | A few days of editorial work per language | Highest — converts a readable page into a credible one at almost no cost |
| 2 | Correct the hreflang set | 1-2 hours | High — removes the risk that the versions suppress each other |
| 3 | Localise the process page per market | 2-3 hours per market | High — the cheapest page to localise and the most directly useful |
| 4 | Fix the RTL layout for Arabic | Development time, varies | High for GCC — without it the Arabic version damages credibility rather than building it |
| 5 | Create the comparison page per market | 1-2 days per market | Moderate — valuable, but the priority is below the process page |
| 6 | Rewrite (not translate) the Q&A per market | 2-3 days per market | Moderate, and it compounds over time as questions accumulate |
The first two priorities together are perhaps a week of work and they address the failures that make a translated site underperform. A manufacturer that starts at priority 5 because a comparison page feels more impressive has skipped the work that would have made the translated pages credible.
9. How to Measure Whether Localisation Worked
| Measure | Baseline | What a good change looks like |
|---|---|---|
| Enquiries per market | The three months before localisation | A rise in the markets where the seven elements were fixed |
| Bounce rate on the local version | Current | A fall, particularly on the process and product pages |
| Pages per session on the local version | Current | A rise, indicating the buyer is exploring rather than leaving |
| Enquiry quality from the market | Qualitative, from the sales team | Fewer enquiries that ask what the product even is |
| AI citation in the local language | The multi-engine grid run in that language | Appearing in answers for local-language queries, which is the clearest sign the version is treated as a real market page |
The last row is the one most manufacturers never check, and it is the most informative. Querying an assistant in Arabic, Spanish, or Japanese and seeing whether your local version is cited tells you whether the search system treats that version as a market page or merely as a translation. If it is never cited in the local language while the English version is cited for English queries, the localisation is incomplete somewhere.
10. FAQ: Multilingual Localisation Questions Manufacturers Ask Most
9.1 Do I need a native speaker or is machine translation enough?
Machine translation is enough for internal drafts and for understanding what a page says, and it is not enough for a page a buyer will make a purchasing decision on. The middle path that works for most manufacturers is machine translation followed by a native-speaker review focused on the seven elements, which costs a fraction of a full professional translation and catches the errors that matter.
9.2 Which markets should I localise first?
The market that generates the most enquiries, and the market where the gap between translation and localisation is widest. For most pain patch exporters that means fixing the existing Arabic version for the GCC first, because the layout direction issue compounds the language issue and the fix has the largest effect per hour spent.
9.3 Do I need separate pages for Spanish in Spain and Spanish in Mexico?
Only if the content genuinely differs by market — different regulatory references, different pricing, different contact details. If the content is identical, one Spanish version is sufficient and declaring regional variants that serve the same content creates fragmentation without benefit.
9.4 Is Arabic really that different from a left-to-right language?
Saying "different" understates it: the layout mirrors, the punctuation attaches differently, the numerals stay left-to-right within the mirrored layout, and the typeface needs a different family with more line height. A template that handles Latin languages correctly will not handle Arabic without specific work, which is why so many Arabic versions look machine-made even with excellent prose.
9.5 How do I stop translators from changing the company name?
Provide a translation glossary as part of the brief, listing every element that must remain in its original form: the Latin legal name, certificate numbers, standard designations, product codes, and INCI names. A translator who receives a glossary does not improvise; a translator who receives only a page does.
9.6 Does localisation help with AI citations in that language?
Yes, and it is one of the clearest signals. A local version that does the seven elements and the hreflang correctly is treated as a market page and can appear in local-language answers. A translated page with wrong units and no layout adaptation is less likely to be cited, because the systems weighting for reliability treat internal inconsistency as a negative signal.
9.7 What is the minimum viable localisation?
The seven elements on the product, specification, compliance, and process pages, plus a correct hreflang set. That is roughly one week per language for a manufacturer with four to six pages, and it addresses the failures that make a translated site underperform.
9.8 Should I keep the English version accessible in every market?
Yes. Many B2B buyers read English and prefer the original for technical specifications, and a buyer who wants the English version should not be forced into a translation. Offer the language switcher prominently and let the buyer choose.
9.9 How often does localisation need refreshing?
Whenever a fact changes in the source — a certificate renewal, a new product, a lead time change — and annually as a review. The drift pattern is that the English site gets revised and the others do not, which produces exactly the cross-market inconsistency that undermines trust.
9.10 Can Kangdi review our localisation?
Yes. Send us the URL of your English version and one local version, and we will compare them against the seven elements and report what has changed and what has not. We will also check the hreflang set and flag any invalid declaration. It takes about an hour and the output is usually a short list of five to eight specific corrections.
11. About Kangdi Medical and Our Language Versions
Henan Kangdi Medical Devices Co., Ltd has manufactured transdermal patches since 1989 at a GMP-certified facility in Zhoukou, Henan, China, and we ship to 200+ brand buyers and distributors across 40+ countries. Our language versions are maintained against a glossary so that identifiers stay identical across markets, and we review the seven elements annually.
Three steps to get your localisation review. (1) Email us with "Localisation" as the subject line and include the URLs of your English version and one local version. (2) We will compare them against the seven elements and check the hreflang configuration. (3) We will send back the specific corrections, ordered by which one most affects whether a local buyer trusts the page.
- Step 1: Email export@kangdimedical.com with "Localisation" as the subject line, including your English URL and one local URL.
- Step 2: Receive the seven-element comparison and the hreflang check within 3 business days.
- Step 3: Get the ordered correction list, starting with the elements that cost nothing to fix.
Tell us your English URL and one local URL, and we will send the localisation review within 3 business days.