A translated Word file can look perfect and still send readers to the wrong place: the label says “Read the application guide,” but the link opens the source-language page, a missing bookmark, or nothing at all. The fix starts with a simple distinction: link text and link destination are separate pieces of a hyperlink.
What a hyperlink contains, and why translation can break it¶
A hyperlink is a connection between user-facing content and a destination. In Word, the visible wording and the destination address are editable separately, according to Microsoft Support’s instructions for creating or editing a hyperlink. In a website, an anchor element presents link content while its href attribute holds the URL, as defined by the HTML Standard.
That separation matters during translation. A translator might change “View your account” to wording that sounds natural in the target language. The URL does not automatically need to change with it. Changing the destination is a separate localization decision that should happen only when a suitable target-language page exists and someone has verified it.
Think of a hyperlink as having two layers:
- The label: the words, image, or other content the reader selects.
- The target: the web address, file, email address, bookmark, or other location the selection opens.
A link can fail at either layer. The label might be missing or misleading even when the destination still works. The label might appear correctly while its underlying target has been removed or changed. Formatting, such as blue text or underlining, can make a string look like a link without proving that it has a working destination.
The Word Open XML documentation shows why visible text is not enough to confirm that a link survived. A hyperlink element can contain displayed text such as “Click here” while a relationship identifier points to the destination. The Open XML SDK documentation separates those pieces in its example.
A document can therefore pass a visual review and still fail a functional review. Reading the translated label tells you whether the wording is right. Activating the hyperlink tells you whether its target is right. Both checks belong in quality assurance.
The same idea applies to web localization. The HTML Standard defines href as a URL-valued attribute for an anchor or area element. An anchor without an href attribute does not create a hyperlink. Translation that preserves only the visible words while dropping the attribute has preserved the sentence, not the link.
Microsoft Support says, “After creating a link, you can edit its address, displayed text, color, and font style.” (Microsoft Support)
The practical point is that changing the displayed wording does not require changing the address. Keep those editing decisions separate, and review the destination directly instead of guessing from the label.
A safe workflow for documents and websites¶
A reliable hyperlink translation workflow begins before translation and ends with checks in the delivered file. The aim is not to preserve every source-language destination forever. The aim is to make each link’s intended behavior clear, then verify that the translated version still delivers that behavior.
1. Inventory the links before work begins¶
Record each link’s visible text, destination, and type. A practical inventory might use these columns:
| Item | What to record | Why it matters |
|---|---|---|
| Source text | The exact wording readers see | Gives the translator context and helps identify missing or duplicated links |
| Destination | The complete target address or location | Makes it possible to compare the source and translated target |
| Type | External page, internal anchor, bookmark, file, or email | Each type needs a different functional check |
| Localization decision | Keep, translate the label, or map to a localized target | Prevents accidental URL changes and clarifies approved changes |
| Final result | Tested destination and any issue found | Leaves a record of the final review |
The inventory does not need to be complicated. A spreadsheet, a document table, or a link list attached to the project can work. What matters is that the source text and destination are recorded separately. A list of labels alone cannot show whether the underlying target changed.
Check links in more than the main body. A Word document may contain links in headings, footnotes, tables, headers, footers, captions, or text boxes. A web page may include links in navigation, buttons, image elements, or reusable interface components. Include the locations your project uses rather than assuming all links sit in ordinary paragraphs.
2. Decide what the reader should see¶
Translate the visible label when the original wording needs localization. A short link label should tell the target-language reader what they will find, not merely reproduce the source wording word for word.
For example, “Click here” gives little information even before translation. A more descriptive label such as “Download the application form” makes the destination clearer, provided that the target really does contain that form. The translator should preserve the meaning and purpose of the source link, not invent a destination or promise content the target does not offer.
Context matters. A label such as “Terms” might refer to terms of service, a glossary, or conditions in a form. The inventory helps a translator understand the intended destination and choose wording that fits. If the context remains unclear, ask the content owner rather than guessing.
The label can also need a different form for accessibility or interface reasons. The Translate House HTML localization guide distinguishes markup from translatable content and notes that some attributes, including alt and title, may contain text that needs translation. That is different from changing a URL attribute because it looks like text.
3. Keep the original target unless a replacement is confirmed¶
Leaving the destination unchanged is the safe default, not an absolute rule. A source-language page may remain the correct destination for all readers, or a localized equivalent may exist. When a localized equivalent is confirmed, the content owner or localization team can map the source target to it.
A target-language URL should not be created by mechanically translating words in the source URL. URL paths, fragments, and other components can be meaningful identifiers. The HTML Standard requires the href value to be a valid URL; changing its characters without checking the result can leave the visible label intact while making the destination invalid.
A deliberate mapping should answer three questions:
- Does the localized page exist?
- Does that page provide the same information or action as the source target?
- Has someone opened the candidate URL and confirmed that it works?
If the answer to any question is no or unknown, do not silently substitute the address. Record the unresolved item for the content owner. Keeping the original destination is more transparent than pointing readers to a guessed page.
4. Protect the link structure in the translation file¶
Translation tools may show link text as editable content while keeping markup or other technical information protected. Follow the project’s file-handling rules and avoid editing structure by hand unless you know which parts are content and which parts carry the destination.
In HTML, that means preserving the anchor markup and its href while translating the user-facing content inside the anchor. The Translate House guide to translating HTML advises leaving tags intact. Its instruction, “Do not translate the actual markers,” refers to the technical markers, not to the human-readable words enclosed by them.
The Translate House localization guide says, “Do not translate the actual markers.”
For a translator, the distinction is straightforward: translate the content that readers see, not the tag names or structural markers that make the page work. A localization tool may display those markers as protected code or inline tags. Keep them in place and follow the tool’s instructions if a marker appears to need moving.
Structured interchange formats can help carry content through a localization pipeline, but the format alone cannot guarantee correct link behavior. OASIS describes XLIFF 2.1 as an XML localization interchange format intended to support exchanges between content owners, providers, and tools. OASIS identifies lossless interchange as XLIFF’s primary focus, while not claiming that every tool will preserve every hyperlink correctly. Treat the translated output as something to verify, even when the workflow uses XLIFF.
5. Review the delivered file, not only the translation workspace¶
The final file is the thing readers will use, so test links there. A project preview or translation editor may not show how a Word relationship, exported website, or converted file behaves after delivery.
Open representative links and compare their targets with the inventory. Check that external pages load, file links open the intended file, and email links address the correct recipient. For internal locations, confirm that the linked section or bookmark still exists and that the link takes the reader there.
A label can become longer in translation. That change might affect nearby layout or make a clickable area less obvious, particularly in a compact button or table cell. Review both the wording and the user’s ability to select the link. Appearance is useful evidence, but it does not replace activation.
How to handle links in Word, HTML, and localization files¶
The core rule stays the same across formats: separate the wording from the destination. The details of where the target is stored differ, so the checks should match the file type.
Word documents: check the target as well as the text¶
Word supports links to web pages, local or existing files, email addresses, and specific locations in the current or another document, according to Microsoft’s hyperlink guidance. A translated document can contain several of these types at once. Do not test one web link and assume every link type is fine.
A Word link to a web page should open the intended page. A file link should point to the correct file and location for the recipient’s setup. An email link should open a message addressed to the intended recipient. A link to a location in a document should reach the right heading, bookmark, slide, or cell reference.
Microsoft’s guidance also describes a manual repair path: right-click the link, choose Edit Hyperlink, and change its text or other properties. Use that option when a link’s displayed text survived but the target needs correction. After editing, activate the link and confirm the new destination rather than relying on the edit dialog alone.
Word files can store hyperlink text separately from the relationship that resolves to a target. The Open XML SDK reference explains that representation. As a result, copying visible words from one document into another does not prove that the original relationship came along with them.
HTML pages: protect the anchor and inspect href¶
For a web page, an anchor usually holds the user-facing text, and its href identifies the destination. The HTML Standard’s link rules define href on anchor and area elements as a URL. Without href, those elements do not create hyperlinks.
A localization review should therefore examine both pieces. Confirm that the translated anchor content is appropriate, then confirm that the href remains valid and points to the approved destination. A page can render the right words even when the anchor’s URL is missing or malformed.
Do not translate all HTML attributes as though they were ordinary prose. The Translate House guide says attributes generally should not be translated, while identifying values such as alt and title as possible exceptions. Each attribute needs a decision based on what it does. A URL is a destination, while an alt value can be text describing an image.
XLIFF and other structured files: protect what the tool protects¶
XLIFF is used to exchange localization content between people and tools. The OASIS XLIFF 2.1 standard makes lossless interchange its main focus. That focus makes the format relevant to structured localization, but it is not a promise that every workflow or tool will handle all links correctly.
Use the project’s instructions for inline codes and protected content. If a link marker is movable, preserve its relationship to the appropriate text. If a marker disappears, duplicates, or appears beside the wrong phrase, flag the segment for repair before export. Do not remove a technical marker just because it looks unfamiliar.
A reviewer may not see a raw URL in the translation editor. The source inventory provides a practical way to compare destinations outside the translated text. Where the tool offers a preview or export, use it to inspect the final rendered link. Where it does not, test the delivered file or page in the application that readers will use.
If your broader workflow also needs to preserve document layout, keep Word styles when translating covers headings, tables of contents, and formatting. For a file that starts as a PDF, PDF-to-Word back-conversion after translation explains why the editable result needs its own review.
When to keep a link, change its target, or replace it¶
Not every source link should remain untouched in every language. The right decision depends on the source target, the audience, and whether an approved equivalent exists.
| Situation | Link text | Destination | What to verify |
|---|---|---|---|
| The source page is appropriate for all language versions | Translate if useful | Keep the original target | Confirm the page opens and is still relevant |
| A verified localized page provides the same content | Translate | Map to the localized target | Open the localized page and confirm the content matches the link’s promise |
| No localized equivalent is available | Translate with clear wording | Keep the valid source target, or flag it for an owner decision | Make sure the label does not imply that a localized page exists |
| The source target is missing or invalid | Translate if the content remains useful | Repair only after the owner confirms the intended destination | Test the repaired destination |
| A link points inside the source document | Translate the label | Preserve and verify the internal target | Confirm the heading, bookmark, or other target still exists |
A localized page is not automatically a suitable replacement just because its language matches the translated text. A page may cover a different topic, omit a form, or direct readers to an action that is not available in their region. The content owner should approve the mapping when the destination affects an application, purchase, policy, or other important action.
Some teams choose to keep a link to a source-language page when no localized equivalent exists. That can be reasonable if the destination remains useful and the label does not mislead readers. Other teams may want to remove or replace a link that no longer serves its purpose. Make that decision intentionally, document it, and apply the same approach to related pages.
An unavailable target also needs careful handling. The translation team can identify and report a broken destination, but the team should not invent a replacement URL. The owner of the content or site needs to confirm the right target before the link is repaired.
Common hyperlink failures and how to prevent them¶
The most confusing failures are the ones that look correct at first glance. A few targeted checks can catch those problems before delivery.
The label survived, but the target did not¶
A copied phrase can look identical to the source while its target relationship is missing. Word’s Open XML representation keeps displayed text distinct from the relationship identifier that resolves to the destination, as shown in the Open XML SDK reference.
The visible link may retain color or underlining after editing, but those visual cues do not prove the destination exists. Activate the link in the final document. If it does not open, repair the hyperlink and test it again.
An internal link points to a name that changed¶
Internal Word links can point to a bookmark or other location within a document. A translation may change headings or restructure content, while a bookmark name stays the same, disappears, or points somewhere unexpected.
The Microsoft Office implementation notes for WordprocessingML hyperlinks explain that a hyperlink can target an internal bookmark through an anchor. The notes also describe Word’s behavior when a specified bookmark does not exist: Word’s default behavior is to navigate to the start of the document. That result can make a broken internal link appear to work, even though it fails to reach the intended section.
The same implementation notes explain that Word appends # plus the anchor value to the relationship target URL in the described case. The URL and the fragment both matter. Check the whole target, including any anchor, after document restructuring.
A URL was translated like a sentence¶
A URL can contain words, but that does not make the URL itself translatable prose. A mechanical edit can invalidate the address even if the displayed wording reads naturally. The HTML Standard requires the href value to be a valid URL, so test the destination after any change.
Keep source targets unchanged by default. Change a URL only when the team has confirmed the localized destination and checked that it offers what the label promises.
A web link lost its href¶
A page can still display anchor text after its href disappears, but the text no longer functions as a hyperlink. The HTML Standard states that anchor and area elements without href do not create hyperlinks.
Check markup-aware previews or inspect the final rendered page. If the text looks clickable but does nothing, review whether the anchor still has its destination attribute and whether that value is valid.
A tool preserved the words but changed the structure¶
A localization tool can preserve the translated sentence while mishandling inline codes or markup. XLIFF supports structured content exchange, but the OASIS XLIFF 2.1 standard does not guarantee that every tool will preserve every hyperlink correctly.
Look for missing or duplicated markers, link text separated from its link, and unexpected changes in the exported file. If the editor’s view differs from the delivered result, give the delivered result priority in functional testing.
A source link changed without an approved mapping¶
A translator may find a target-language page that seems close to the original and swap in its URL. Similar titles do not prove that the pages serve the same purpose. The replacement might omit an instruction or lead to a different form.
Add a localization decision to the link inventory and record who confirmed the mapping. If no confirmation is available, leave the existing target in place when it remains valid, or flag the link for review.
A practical checklist for link QA¶
A repeatable checklist makes link review less dependent on memory. Use the list before work begins and again after the target file or page has been assembled.
- Record every source link. Capture its visible text, destination, and type. Include links in tables, notes, page furniture, and interface elements where they appear.
- Mark the intended treatment. Decide whether the text needs translation, whether the original target should stay, and whether a localized destination needs approval.
- Protect structure during translation. Keep HTML tags and localization markers intact. Follow the file format’s instructions rather than editing unfamiliar code by guesswork.
- Compare the translated link inventory. Check that each expected link is present and that the destination has not changed without a documented reason.
- Open links in the delivered output. Test external pages, files, email links, and internal locations in the actual translated document or page.
- Repair and retest failures. Use the appropriate editing controls, confirm the correct target with the content owner, and activate the repaired link.
- Record unresolved issues. Note any destination that needs owner input or cannot be verified. Do not hide an unresolved target behind link formatting.
A final pass should test behavior as well as language. Ask whether the label tells readers what they will get, whether the target delivers it, and whether the link still works after export. A correct answer to all three questions is stronger evidence than a link that merely looks familiar.
The HTML Standard states, “The href attribute on a and area elements is not required; when those elements do not have href attributes they do not create hyperlinks.”
That distinction explains why a page can show the right words and still have no working link. Check the destination attribute or activate the link rather than treating its appearance as proof.
FAQ¶
How do I keep hyperlinks in a Word document after translation?¶
Keep the target and its relationship intact while translating the displayed text separately. Word allows the address and displayed wording to be edited as distinct properties, and the final translated file still needs a functional link check (Microsoft Support).
Should URLs be translated when localizing a website?¶
Don’t translate URL strings mechanically. Keep the original target unless a verified localized page is available, then map the link to that confirmed destination; the HTML Standard requires a valid URL in href (HTML Standard).
How can I check whether links still work in a translated document?¶
Open links in the delivered translated file and verify that they reach the intended pages or locations. Check external URLs, files, email links, bookmarks, and in-page anchors rather than relying on visible formatting alone.
How do I preserve internal links and bookmarks in a translated file?¶
Preserve the bookmark or anchor and confirm that the target still exists after editing. Word can send a reader to the start of the document when a specified bookmark is missing, so test internal links directly (Microsoft Office implementation notes).
Can hyperlink text be translated without changing its destination?¶
Yes. Word treats the displayed wording and destination address as separately editable, and HTML separates anchor content from its href destination. Translate the reader-facing label while keeping the target unchanged unless a replacement has been confirmed.