Translate Like a Pro | IDNs, URLs & International Email

Internationalizing an address is not the same as translating it. Domain names, URLs and email addresses can contain human-readable language, Unicode characters, encoded transport forms, technical separators and identity-bearing strings that must survive exactly enough for browsers, DNS, mail servers and users to agree on the same destination.

Searches for internationalized domain names, IDN localization, Punycode, Unicode URL, international email address, SMTPUTF8, email address internationalization, translate URLs and multilingual domain names describe a technical-language boundary rather than an ordinary prose problem. Unicode UTS #46 continues to define widely used IDNA compatibility processing, while RFC 6531 specifies SMTPUTF8 for internationalized email transport.

This guide explains how to display, validate, store and localize those identifiers without turning one destination into another. It covers U-labels and A-labels, IDNA processing, Punycode, Unicode normalization, visually confusable characters, mixed scripts, path and query components, visible link text, internationalized email local-parts and domains, SMTPUTF8 capability, bidi display, copy/paste, analytics, QR/link handoff, security review and end-to-end delivery testing.

This article sits inside eduKateSG’s Master Art of Translation architecture. It extends the professional localization layer without replacing existing owners for Unicode, software localization, search, security, accessibility or developer tooling.

Quick answer

Treat domain names, URLs and email addresses as structured identifiers with human-facing representations. Do not translate or normalize them as if they were ordinary sentences. Use standards-compliant IDNA and email libraries, preserve exact resource identity, render user-friendly Unicode where safe, keep machine forms available where required, and test the full resolution or delivery path.

Classify: distinguish domain, URL path, query, fragment, email local-part and display text.
Process: use standards-compliant IDNA handling rather than homemade Punycode conversions.
Protect: preserve the actual destination and mailbox identity.
Display: show Unicode forms safely where appropriate.
Validate: check protocol capability, not just ASCII patterns.
Secure: consider mixed-script and confusable-identifier risks.
Test: resolve domains, open URLs and deliver email end to end.

1. Separate display form from transport form

The form users read and the form protocols transport can differ. Internationalized domains can appear as Unicode U-labels to users while DNS-facing representations may use ASCII A-labels produced through IDNA.

Professional method. Store or derive both forms through a trusted IDNA library and keep their relationship explicit. The decision should be explicit enough that a second translator, reviewer, developer or moderator can reproduce it without inventing a new rule.

Failure mode. A team manually edits xn-- labels or assumes the visible Unicode string is identical to the DNS wire representation. A browser may display a Unicode domain while resolving an ASCII-compatible encoded form.

Verification. Round-trip the Unicode name through the same standards library used in production and compare resolution. If the check exposes uncertainty, preserve the original evidence and escalate rather than forcing a confident-looking localized answer.

2. Use IDNA processing, not translation intuition

Domain labels follow technical validity and mapping rules. Unicode UTS #46 version 18.0.0, dated 31 August 2026, defines current compatibility processing used to map and validate internationalized labels alongside IDNA2008 expectations.

Professional method. Pass user-entered domains through standards-conformant processing and report validation errors without trying to ‘fix’ the name linguistically. The decision should be explicit enough that a second translator, reviewer, developer or moderator can reproduce it without inventing a new rule.

Failure mode. A translator replaces accented characters with visually similar ASCII letters and points users at a different domain. Case mapping and certain compatibility behavior belong to the IDNA processor, not the translation style guide.

Verification. Test accepted, rejected and mapped labels against the deployed library version. If the check exposes uncertainty, preserve the original evidence and escalate rather than forcing a confident-looking localized answer.

3. Do not hand-edit Punycode

Punycode is an encoding mechanism used within the IDNA ecosystem, not a human translation format. One changed ASCII character can represent a different Unicode label.

Professional method. Generate and decode A-labels only through tested libraries. The decision should be explicit enough that a second translator, reviewer, developer or moderator can reproduce it without inventing a new rule.

Failure mode. A support agent copies part of an xn-- label and rewrites it for readability. The visible Unicode domain can be shown separately while the machine representation stays untouched.

Verification. Decode the final A-label and confirm it produces the intended U-label. If the check exposes uncertainty, preserve the original evidence and escalate rather than forcing a confident-looking localized answer.

4. Treat domains as security-sensitive identifiers

Unicode enables many scripts and therefore some visually confusable strings. Unicode UTS #39 provides current mechanisms for detecting mixed-script and whole-script confusables and publishes identifier-security profiles.

Professional method. Apply the application’s security policy to high-risk identifiers and flag suspicious script mixtures or confusables for review. The decision should be explicit enough that a second translator, reviewer, developer or moderator can reproduce it without inventing a new rule.

Failure mode. A localization layer assumes any Unicode spelling that looks right is safe. A visually similar Cyrillic character can be mistaken for a Latin character inside a domain.

Verification. Run identifier-security checks and inspect the actual code points, not only the rendered glyphs. If the check exposes uncertainty, preserve the original evidence and escalate rather than forcing a confident-looking localized answer.

5. Do not block legitimate multilingual identifiers indiscriminately

Security controls should not collapse internationalization back to ASCII-only rules. Many valid users and brands rely on non-ASCII names.

Professional method. Use explicit security profiles and risk-based checks rather than blanket rejection of all Unicode. The decision should be explicit enough that a second translator, reviewer, developer or moderator can reproduce it without inventing a new rule.

Failure mode. A global form rejects every domain containing Arabic, Devanagari or accented Latin characters. A single-script legitimate label can be permitted even while mixed-script confusable patterns receive additional scrutiny.

Verification. Maintain test cases for both legitimate internationalized names and known risky patterns. If the check exposes uncertainty, preserve the original evidence and escalate rather than forcing a confident-looking localized answer.

6. Separate hostname from URL path

A URL contains more than a domain. Hostnames follow IDNA rules, while paths, queries and fragments have different encoding and application semantics.

Professional method. Parse URLs structurally before localizing or displaying them. The decision should be explicit enough that a second translator, reviewer, developer or moderator can reproduce it without inventing a new rule.

Failure mode. A translator sends an entire URL through one text-replacement rule. A localized website can keep the same hostname but use locale-specific path slugs, or keep both fixed depending on architecture.

Verification. Parse and reconstruct the URL and confirm every component still addresses the intended resource. If the check exposes uncertainty, preserve the original evidence and escalate rather than forcing a confident-looking localized answer.

7. Define a deliberate localized-slug policy

Human-readable paths can be localized without changing the domain’s technical identity. Localized slugs may improve readability but create routing, analytics and maintenance complexity.

Professional method. Choose whether slugs are shared, translated, aliased or generated by the CMS, and keep stable content IDs beneath them. The decision should be explicit enough that a second translator, reviewer, developer or moderator can reproduce it without inventing a new rule.

Failure mode. Translators independently rewrite paths and break inbound links. A page can have a localized visible slug while redirects or alternate links preserve route continuity.

Verification. Open old and new URLs and confirm canonical routing. If the check exposes uncertainty, preserve the original evidence and escalate rather than forcing a confident-looking localized answer.

8. Localize visible link text separately from href

What users read does not need to be the literal URL. A descriptive target-language label is usually more useful than exposing a long technical address.

Professional method. Translate anchor text naturally while preserving or deliberately mapping the destination href. The decision should be explicit enough that a second translator, reviewer, developer or moderator can reproduce it without inventing a new rule.

Failure mode. The translator changes the href because the visible sentence changed. ‘Read the privacy policy’ can localize while the technical URL remains a shared route.

Verification. Click every localized link and compare destination identity. If the check exposes uncertainty, preserve the original evidence and escalate rather than forcing a confident-looking localized answer.

9. Keep query parameters and API tokens protected

URLs can contain machine identifiers, parameter names and signed values. Changing them can invalidate requests or security checks.

Professional method. Mark technical query keys and tokens non-translatable, while localizing user-facing values only when the application contract allows it. The decision should be explicit enough that a second translator, reviewer, developer or moderator can reproduce it without inventing a new rule.

Failure mode. A translator changes ?lang=en or a signed parameter because it resembles ordinary text. A localized search query value may be encoded, but the parameter key remains part of the application interface.

Verification. Replay the localized URL against the real application. If the check exposes uncertainty, preserve the original evidence and escalate rather than forcing a confident-looking localized answer.

10. Understand internationalized email has two separate parts

An email address contains a local-part before @ and a domain after it. The domain can use IDNA, while non-ASCII local-parts require SMTPUTF8 support defined by RFC 6531 and related standards.

Professional method. Validate the domain and local-part under the right standards rather than using one ASCII-only regular expression. The decision should be explicit enough that a second translator, reviewer, developer or moderator can reproduce it without inventing a new rule.

Failure mode. A form accepts Unicode domains but rejects every non-ASCII mailbox name even when the mail system supports SMTPUTF8—or accepts them when the outbound server does not. An address can have an internationalized domain only, or both an internationalized local-part and domain.

Verification. Test against the actual mail transport capability. If the check exposes uncertainty, preserve the original evidence and escalate rather than forcing a confident-looking localized answer.

11. Do not claim deliverability from syntax alone

A syntactically valid address may not exist, and an unfamiliar address may still be real. Validation libraries cannot prove mailbox ownership merely from shape.

Professional method. Use syntax/protocol checks for form acceptance and a confirmation email when actual control matters. The decision should be explicit enough that a second translator, reviewer, developer or moderator can reproduce it without inventing a new rule.

Failure mode. The UI calls an internationalized address fake because it differs from historic ASCII patterns. Successful SMTPUTF8 support still does not prove a mailbox belongs to the user.

Verification. Use a controlled confirmation workflow where product requirements need ownership evidence. If the check exposes uncertainty, preserve the original evidence and escalate rather than forcing a confident-looking localized answer.

12. Negotiate SMTPUTF8 capability correctly

RFC 6531 requires SMTP servers to advertise SMTPUTF8 before clients transmit internationalized envelope addresses or headers under that extension. A Unicode-capable application can still encounter downstream mail infrastructure without support.

Professional method. Let a standards-compliant mail stack negotiate capability and surface delivery limitations honestly. The decision should be explicit enough that a second translator, reviewer, developer or moderator can reproduce it without inventing a new rule.

Failure mode. The application stores an internationalized address but assumes every relay path can deliver it. A send attempt may need to fail or use an approved alternate address rather than silently rewriting the mailbox.

Verification. Test supported and unsupported SMTP paths in staging. If the check exposes uncertainty, preserve the original evidence and escalate rather than forcing a confident-looking localized answer.

13. Preserve email address identity during case and normalization handling

Mail systems and user expectations do not justify casually rewriting local-parts. Domain comparison and local-part semantics are governed differently, and over-normalization can change identity.

Professional method. Use mail-library rules, preserve user-entered canonical identity and create separate comparison keys only under a defined product policy. The decision should be explicit enough that a second translator, reviewer, developer or moderator can reproduce it without inventing a new rule.

Failure mode. A generic lowercase-and-normalize function rewrites every full address. The domain can be case-insensitively compared while the local-part deserves more conservative treatment.

Verification. Round-trip stored addresses through send, display and account lookup. If the check exposes uncertainty, preserve the original evidence and escalate rather than forcing a confident-looking localized answer.

14. Handle bidi display without changing the URL

URLs and email addresses combine LTR technical syntax with RTL surrounding text. Punctuation and separators can appear confusingly if directionality is not isolated.

Professional method. Apply the direction-handling principles in RTL and bidirectional localization so the identifier remains logically intact. The decision should be explicit enough that a second translator, reviewer, developer or moderator can reproduce it without inventing a new rule.

Failure mode. A team inserts visible spaces or reverses components until an Arabic screenshot looks right. An email address can be isolated as LTR content inside an RTL paragraph.

Verification. Copy/paste the displayed identifier and confirm exact logical order. If the check exposes uncertainty, preserve the original evidence and escalate rather than forcing a confident-looking localized answer.

15. Preserve copy, paste and QR handoff

Users move addresses between visual and machine channels. A pretty display is useless if copied text or encoded QR data points elsewhere.

Professional method. Keep copy targets and QR payloads tied to the canonical identifier rather than a decorative display string. The decision should be explicit enough that a second translator, reviewer, developer or moderator can reproduce it without inventing a new rule.

Failure mode. The page shows a Unicode domain but the copy button uses an outdated ASCII URL. A QR code can encode the same canonical route while nearby text is localized.

Verification. Scan, copy and paste into independent clients. If the check exposes uncertainty, preserve the original evidence and escalate rather than forcing a confident-looking localized answer.

16. Keep logs and analytics machine-stable

Operational systems need consistent identifiers across locales. If analytics records translated URLs or display names inconsistently, one resource fragments into many apparent entities.

Professional method. Log canonical IDs and normalized route identifiers, adding locale as a separate field. The decision should be explicit enough that a second translator, reviewer, developer or moderator can reproduce it without inventing a new rule.

Failure mode. Reports count one localized domain as separate products. A page_id remains stable while url_display and locale vary.

Verification. Compare cross-locale analytics aggregation. If the check exposes uncertainty, preserve the original evidence and escalate rather than forcing a confident-looking localized answer.

17. Test browser, mail and form behavior end to end

Internationalized identifiers cross many independent components. Passing one library check does not prove the whole path works.

Professional method. Combine international form testing, browser resolution, mail delivery, Unicode rendering and security checks in one regression matrix. The decision should be explicit enough that a second translator, reviewer, developer or moderator can reproduce it without inventing a new rule.

Failure mode. The signup form accepts an address that the notification service later rejects. A test account can register with an internationalized address, receive mail and click a localized URL successfully.

Verification. Run the entire user journey on supported platforms. If the check exposes uncertainty, preserve the original evidence and escalate rather than forcing a confident-looking localized answer.

A repeatable operating sequence

A robust internationalized-identifier workflow starts from exact destination identity, applies standards-based processing, then adds a safe human-readable presentation.

Parse domains, URLs and email addresses into structural components.
Use standards-compliant IDNA processing for domain labels.
Apply Unicode security checks appropriate to identifiers.
Define localized-slug and visible-link-text policy.
Protect query keys, tokens and technical fragments.
Validate email local-parts and domains under real mail-stack capabilities.
Negotiate SMTPUTF8 through the mail system.
Render bidi identifiers with correct isolation.
Keep canonical identifiers separate from display forms.
Test copy/paste, browser resolution, email delivery and links.
Log canonical identity plus locale separately.
Regression-test after Unicode, IDNA, browser or mail-stack upgrades.

Treat the sequence as a loop. Late defects often reveal an earlier mistake in identity, data modelling, context, policy, spatial design or version control. Repairing the earliest useful cause is more durable than patching one translated string.

Worked scenarios

1. Unicode domain displayed, Punycode copied

The UI shows a friendly internationalized domain but the copy button exposes an A-label. The hidden risk is users thinking two forms represent different sites.

Choose a clear display/copy policy, document the relationship and ensure both forms resolve to the same intended domain. The objective is to preserve the same underlying technical, spatial, safety or policy state while allowing the target language to become natural and usable.

2. Email form rejects a non-ASCII local-part

The organization’s outbound mail stack actually supports SMTPUTF8. The hidden risk is historic ASCII validation blocking legitimate users.

Replace the simplistic regex with standards-aware validation and run real delivery tests. The objective is to preserve the same underlying technical, spatial, safety or policy state while allowing the target language to become natural and usable.

3. Mixed-script domain resembles a trusted brand

The characters render nearly identically. The hidden risk is localization increasing spoofing exposure.

Apply Unicode identifier-security checks and product risk policy before presenting it as ordinary trusted text. The objective is to preserve the same underlying technical, spatial, safety or policy state while allowing the target language to become natural and usable.

4. Localized path translated manually

A translator changes the URL slug in prose and the route 404s. The hidden risk is visible language edits altering navigation identity.

Generate localized routes from CMS mapping and keep anchor text separate from href. The objective is to preserve the same underlying technical, spatial, safety or policy state while allowing the target language to become natural and usable.

5. RTL paragraph scrambles email punctuation visually

The address itself is correct in storage. The hidden risk is visual order fixes corrupting logical address order.

Use bidi isolation around the identifier and confirm copy/paste fidelity. The objective is to preserve the same underlying technical, spatial, safety or policy state while allowing the target language to become natural and usable.

6. Mail accepted by form but fails downstream

An intermediate SMTP server lacks required internationalization support. The hidden risk is front-end validation being mistaken for deliverability.

Test the actual transport path, report delivery failure accurately and offer only approved recovery options. The objective is to preserve the same underlying technical, spatial, safety or policy state while allowing the target language to become natural and usable.

Internationalized identifiers: twenty professional practice cases

For each case, identify the invariant, the localizable layer, the evidence required, the safest provisional action and the final verification step.

1. A domain contains accented Latin characters

Run IDNA processing and security checks; do not strip accents as a translation shortcut. State why the rule applies and what new evidence would make you change the decision. This keeps judgment accountable.