If you are searching for how to translate an S10 tracking number, how to translate UPU postal item identifiers, how to translate registered-mail, parcel or EMS tracking codes, or how to preserve international postal identity across languages, the first rule is that the 13-character S10 identifier is data, not prose. Translate the service description, tracking events, addresses and customer instructions around it; do not translate, transliterate, reorder or localize the identifier itself.
This matters in international registered mail, insured mail, tracked letter post, parcels, EMS, postal customer service, customs data, e-commerce, returns, postal EDI, logistics dashboards and multilingual tracking pages. A target text can read perfectly and still be operationally wrong if a service indicator changes, a leading zero disappears from the serial number, the check digit is mistyped, the final country code is interpreted as the item’s physical origin in every case, or a second barcode is mistaken for the UPU S10 item ID.
This guide explains how to translate around the Universal Postal Union S10 identifier while preserving item identity. It covers the two-letter service indicator, eight-digit serial number, check digit and two-letter country code; service classes, tracking events, EMS, registered and insured mail, OCR and barcode risks, postal EDI, customs relationships, right-to-left layouts, spreadsheets and customer-facing tracking so the language can change while every postal event continues to refer to the same item.
1. S10 is a 13-character postal item identifier
UPU Standard S10 defines a fixed-length identifier used for postal items. Its recognizable structure helps postal operators and systems distinguish the international item reference from order numbers, customs numbers and other barcodes on the same package. Preserve all thirteen characters exactly and treat the complete value as protected data. A translated label may say “tracking number,” “registered item” or “EMS item” in the reader’s language, but the code itself should remain character-for-character identical to the issuing postal record.
2. The structure is two letters, nine digits and two letters
The S10 pattern is commonly described as A2-N9-A2: two alphabetic service characters, eight serial digits, one numeric check digit and two final alphabetic country-code characters. Those pieces have different operational roles, so a translator should not regroup them according to target-language number style. A useful QA rule is to validate the expected character class at every position before and after translation, then compare the entire target string with the source record rather than trusting visual similarity.
3. The first two characters are the service indicator
Characters one and two form the service indicator. They come from UPU-controlled allocations and describe postal service context; they are not an abbreviation created from the customer-facing service name. If a source identifies registered mail, insured mail, tracked letter post or EMS, translate the service wording naturally for readers but keep the two letters unchanged. Generating new initials from the target-language term would create a different identifier and could make tracking lookup fail.
4. The next eight digits are a fixed-width serial
Characters three through ten form an eight-digit serial number. Leading zeros are valid, which means ordinary numeric formatting is dangerous. Spreadsheet software, low-code platforms and careless CSV imports can silently turn a value such as 00123456 into 123456. Store the serial and the complete S10 as text, never as an integer. After every import or export, check both total length and literal value so formatting software cannot change identity without anyone noticing.
5. Character eleven is the check digit
The eleventh character is a check digit calculated under the S10 rules. It is not optional decoration and should not be removed simply because the remaining characters seem unique. The check digit is useful for catching transcription and OCR errors, but a failed check does not tell the translator which source character is wrong. Preserve the source value, validate it with the UPU tool or an approved implementation, and escalate discrepancies instead of silently recalculating a “better” identifier.
6. The last two characters are a country code
Characters twelve and thirteen use a two-letter country code within the S10 system. Those letters are controlled data, not a place name to translate, expand or replace with a flag. If the target interface needs a human-readable country label, translate that label separately. Keep the suffix exactly as issued. The country characters belong to the identifier string and should survive language changes, font changes, PDF export and copy-paste without substitution.
7. The country suffix does not always prove physical origin
A particularly important translation trap is to treat the final country code as guaranteed proof that the item was physically posted in that country. UPU guidance discusses extraterritorial offices of exchange and related arrangements where the identifier can use the designated operator’s member-country code even though the item entered the postal network elsewhere. When prose needs to state physical origin, rely on verified acceptance events, office information or operator data rather than translating the suffix into an unsupported geographic claim.
8. The suffix does not uniquely identify every operator
The final country code alone is not a complete operator identifier. More than one relevant postal operator or operational arrangement can exist in a country or territory, and the S10 suffix should not be converted into a specific operator name without supporting metadata. A multilingual tracking page should get the postal operator from authoritative service data, then localize that operator’s public name separately. This prevents the translator from turning a country-level code into a false company-level statement.
9. S10 format and S10 validity are not identical
A string can look like S10 because it contains two letters, nine digits and two letters, yet still fail the data-content rules or check-digit logic. Pattern matching is therefore a useful first filter, not final validation. Translation systems should protect candidate identifiers, then validate service-indicator position, serial length, check digit and issuing context. A regex can tell you that a string resembles S10; it cannot prove that the postal network actually assigned that identifier to the item.
10. One postal item can carry several different barcodes
A parcel or letter may display warehouse labels, merchant return codes, customs references, domestic carrier numbers and the international S10. OCR and human reviewers can easily choose the wrong string if they assume the largest barcode is the tracking number. Before translation, identify each namespace and field role. Preserve every relevant code separately, label it correctly for the target audience, and never “simplify” the label by replacing several identifiers with one generic number.
11. Registered, insured and tracked services need precise wording
Registered mail, insured mail and tracked letter-post products can share the general idea of traceability while offering different service features. Translation should not collapse all of them into one broad word such as “tracked” or “registered” merely because an S10 is present. Decode or retrieve the service context from authoritative postal data, preserve the service indicator, and choose target terminology that matches the actual product. This protects customer expectations about proof, compensation, handling and delivery.
12. EMS uses the same identity principle
EMS items also use S10-style postal item identifiers in international operations. The premium service name, event language and customer instructions can be localized, but the item ID remains the event anchor across countries. A useful implementation separates three layers: the stable S10, the postal event code or state, and the translated customer-facing sentence. When those layers remain separate, one identifier can support many languages without fragmenting the tracking history.
13. Postal item identity is not product identity
A parcel can contain many products, SKUs, serial numbers or customs lines while having one postal item identifier. The S10 answers “which postal item is this?” rather than “which product is inside?” Translate goods descriptions and preserve product identifiers under their own rules. Keep every declared line relationally attached to the correct S10. This distinction matters for e-commerce returns, customs review and claims because a correct product code on the wrong parcel record is still operationally wrong.
14. The S10 is not an e-commerce order number
Merchants create order IDs, fulfillment IDs and return-merchandise references that can appear on the same label or tracking page. Those transaction identifiers are not the postal item ID. A translator should preserve each namespace and translate only the labels around them. If a support message says “order number” but displays the S10, or says “tracking number” but inserts an internal order ID, customers and postal staff can search the wrong system even though every character was copied correctly.
15. The S10 is not a customs declaration number
International postal items can carry CN22 or CN23 customs data, electronic advance data and other customs references in addition to S10. Customs identifiers serve regulatory processes, while S10 anchors the postal item through transport and delivery events. Translate customs labels and goods descriptions, but preserve the postal and customs identifiers separately. In structured data, keep explicit field names so import/export routines cannot swap the postal tracking key with a customs declaration reference.
16. The S10 is not a GS1 SSCC
Postal networks and logistics partners can also use GS1 identifiers such as SSCC for logistics units, RFID or handling processes. SSCC and S10 can coexist in one operational flow without being substitutes. If both appear, preserve both and maintain the mapping supplied by the source system. This distinction also prevents search cannibalization inside eduKateSG: the existing GS1 logistics owners explain SSCC and related keys, while this article owns the postal item identifier and postal tracking semantics.
17. Service-indicator interpretation must use current UPU data
The first two characters come from controlled ranges and allocations. Static blogs and old cheat sheets can omit reserved ranges, special cases or current assignments. When an article or translation needs to explain what the letters mean, use current UPU standards or code lists rather than guessing from familiar examples. The service letters themselves remain untouched even when the surrounding explanation is translated into another language.
18. Reserved ranges are not free abbreviation space
A translator should never invent an S10 service indicator because a target-language service phrase starts with convenient letters. Reserved and allocated ranges exist for postal interoperability, and a plausible-looking pair can still be invalid or assigned to another purpose. Keep the supplied identifier as evidence. If the source has no S10, do not manufacture one from prose. Identifier assignment belongs to the postal issuing system, not the translation process.
19. Leading zeros are identity, not formatting
Leading zeros in the eight-digit serial can be lost long before a linguist touches the text. CSV import, spreadsheet formatting and database type inference are common causes. The safest policy is to declare S10 and serial fields as strings at schema level. QA should check not only the visible value but also the raw exported data, because a formatted cell can display zeros that disappear when the file is saved or sent to another system.
20. Scientific notation is unacceptable for postal identity
If a serial segment is converted to scientific notation, exact identity can be lost through rounding. Even when the full S10 includes letters, workflows sometimes split the numeric portion into another column and expose it to numeric software behavior. Treat any exponent notation in an identifier field as a critical data defect. Recover the value from the postal source, restore text typing and verify the full thirteen-character S10 before translation continues.
21. Check-digit success is not proof of real-world assignment
A mathematically valid identifier can still be unissued, mistyped in a way that accidentally passes a check, or unrelated to the physical item being translated. Check digits protect internal consistency, not provenance. For high-stakes claims, customs work or customer disputes, combine check-digit validation with label evidence, postal-system lookup and event history. The translation should never present “valid check digit” as proof that the item exists or belongs to a particular sender.
22. A failed check digit does not authorize automatic repair
When validation fails, the source can be wrong because of OCR, typing, cropping or a bad label. Recomputing a check digit only tells you what digit would fit the preceding characters; it does not prove those preceding characters are correct. Preserve the source evidence, flag the exception and obtain the canonical identifier from the postal operator or source system. Translation should not turn uncertainty into false certainty.
23. Tracking events must stay on one stable identifier
Acceptance, dispatch, export, arrival, customs, delivery attempt and final delivery can all be recorded against the same S10. If one translated event accidentally receives another identifier, the history splits into two apparent items. Keep S10 as the join key across all events and localize only the event text. Relational QA should compare event count, timestamp, location and item ID so a correct tracking number is never attached to the wrong status row.
24. Event code and event sentence are different layers
Postal EDI and internal systems can use coded event values while customer interfaces show human-readable sentences. Translators should operate on the sentence layer without altering the underlying event code or item key. This architecture also makes quality assurance easier: the reviewer can verify that the target phrase accurately represents the event state while the system preserves the exact S10 and coded event that drive downstream logic.
25. Accepted is not the same as dispatched
Postal status verbs encode a sequence. “Accepted,” “processed,” “dispatched,” “handed over,” “arrived” and “delivered” do not mean the same thing. A target that turns all of them into “sent” removes operational information. Build a controlled glossary for tracking events and validate it against the actual event code or operator definition. Keep chronology intact so the translated timeline still tells the same story as the source.
26. Arrival in the destination network is not delivery
An inward-office or destination-country arrival event can occur hours or days before delivery. Customer-facing translation must not convert “arrived at inward office” into “delivered” simply because both suggest progress. The S10 provides continuity across those stages. QA should read the translated timeline as a whole and ask whether each message preserves the state transition represented by the underlying postal data.
27. Customs processing is not delivery
Events such as presentation to customs, customs retention or release describe regulatory processing. They do not prove that the recipient has the item. Translate customs language carefully and resist optimistic simplification in customer interfaces. The same S10 should continue through customs and back into postal handling. If the item is held, the target message should preserve that uncertainty rather than imply successful final-mile delivery.
28. Delivery attempt is not successful delivery
A failed attempt can be mistranslated as delivery when the target language uses a broad verb for “bring” or “deliver.” That error can affect complaints, claims and customer expectations. Maintain separate target terms for attempted delivery, notice left, available for collection, refused, returned and delivered. Validate every phrase against the event state while keeping the S10 unchanged.
29. Return to sender remains part of the same history
When an item reverses direction because of refusal, incomplete address, customs issue or non-collection, the tracking narrative changes direction but does not become a new translation identity. Preserve the original S10 unless the postal system actually assigns another item identifier. Translate return reasons precisely and keep timestamps and locations in sequence so the reader can distinguish outbound movement from return movement.
30. Addresses and S10 require different transformation rules
Addresses may need target-script rendering, locality-order changes or transliteration to support delivery and comprehension. The S10 does not. Putting both into one free-text block increases the chance that a translation engine or formatter will touch the identifier. Separate address fields from the protected item ID. Apply address policy deliberately, then confirm that the S10 is unchanged before rebuilding labels or documents.
31. Recipient names need their own policy
Personal names on postal items can be retained, transliterated or formatted according to delivery requirements and cultural conventions. They are not part of S10. A workflow that treats the whole label as translatable prose may accidentally modify both the name and tracking ID. Define a names policy, an address policy and an identifier policy separately, then integrate them only at the final presentation layer.
32. Postal operator names should come from verified metadata
A translated tracking page may show the sending and destination operators. Those names should be retrieved from authoritative service metadata or official operator branding rather than guessed from the final country code. Translate or select the official multilingual operator name as appropriate. Keep operator identity separate from S10 itself so a code suffix never becomes an unsupported corporate attribution.
33. Spacing is presentation, not part of the canonical value
Some labels or websites add spaces to make tracking numbers easier to read. That does not mean the stored identifier contains those spaces. Maintain a canonical continuous S10 string for lookup, comparison and API exchange, then apply display spacing only if the product specification permits it. When QA compares source and target, normalize only approved presentation differences and never normalize away changed letters or digits.
34. Do not insert hyphens for target-language readability
Hyphenation conventions vary across identifiers, phone numbers and account numbers, but S10 should not acquire new punctuation simply because a target-language style guide prefers grouped codes. Extra characters can break search boxes, APIs and copy-paste. If a customer interface wants visual grouping, implement it through presentation formatting while retaining a canonical raw value underneath.
35. Uppercase Latin letters remain canonical
Service and country code letters are conventionally uppercase. A lowercased S10 may still be understandable to a person, but exact-match systems and data-cleaning rules can behave differently. Preserve canonical uppercase throughout source, target, export and API payloads. Treat case changes in identifier fields as QA warnings rather than harmless typography.
36. Localized numeral glyphs should not replace machine digits
A multilingual interface can display local numeral glyphs for dates, counts or prices while keeping the S10 in the standard representation expected by postal systems. Converting identifier digits for visual localization can make external lookup fail. Preserve the canonical Latin-letter and Arabic-digit string, and localize the surrounding prose separately. If a secondary human-readable rendering is required, never overwrite the machine value.
37. Right-to-left interfaces require directional isolation
Arabic, Hebrew and other right-to-left pages can visually reorder mixed Latin letters and digits if the S10 is not isolated correctly. Reversing the code manually is never the solution. Use proper bidirectional controls or UI components to keep the identifier left-to-right while surrounding prose follows the target language. Test visual order, cursor movement, selection, copying and submission into a tracking search field.
38. OCR often confuses letters and digits
Receipts, screenshots and labels can be noisy. OCR can confuse O and 0, I and 1, or other similar shapes. S10 position rules help detect impossible character classes, and the check digit adds another signal, but neither replaces the source image or postal record. When OCR and validation disagree, inspect the original or retrieve electronic data instead of letting a model guess the most plausible character.
39. OCR can also drop leading zeros
Post-processing tools sometimes recognize the eight-digit serial correctly and then convert it to a number, deleting leading zeros after OCR. The resulting S10 can have the right visible letters but the wrong number of digits. Count positions before translation begins, compare the extracted value against the image and reject identifiers that do not retain their fixed-width structure.
40. Barcode decoding can provide an independent check
When a machine-readable barcode is available, decoding it can provide another copy of the postal item identifier. The encoded value and printed human-readable S10 should agree. If they do not, stop and investigate; do not choose the prettier or more legible one. Independent representations are valuable precisely because they expose corruption that one channel can hide.
41. Screenshots are weaker evidence than source records
A tracking screenshot can crop the first or last character, hide timestamps or show presentation spacing that is not part of the raw data. For high-stakes translation, request the underlying tracking record, full label or operator export. Use screenshots as visual context, not as unquestionable machine identity. The S10 should ultimately be verified against a source that preserves all thirteen characters.
42. CSV exports must type S10 as text
Tracking exports often contain item ID, timestamps, event code, facility, country, operator and translated description. Declare the identifier column as text before any spreadsheet tool opens it. Use stable row keys so sorting descriptions cannot detach events from their S10. After translation, re-import a sample file through the same production path and confirm every event still belongs to the same postal item.
43. JSON should separate identity from presentation
A robust API keeps S10 in a dedicated string field and stores event codes, times, locations and localized messages separately. Flattening everything into one translated sentence makes systems harder to reconcile and encourages accidental identifier edits. Preserve the raw item ID and machine event fields, then localize display strings at the presentation layer. Contract tests should confirm that changing interface language never changes the S10 payload.
44. UPU EDI is structured data, not a translation paragraph
International postal operations exchange structured messages containing identifiers and coded values. Translators may need to document those messages or localize interfaces built from them, but the raw EDI syntax is not ordinary prose. Protect message structure, S10 and event codes. Translate documentation, labels and customer-facing descriptions separately so the operational message can still be parsed after localization.
45. Customs electronic data can reference the same S10
Electronic advance customs data such as ITMATT can carry content information linked to the postal item. The S10 must remain stable so customs and postal networks reconcile the same object. Translate goods descriptions when permitted, preserve HS codes and monetary fields under their own rules, and keep every customs line linked to the correct S10. A correct description attached to another item is still a serious error.
46. HS code and S10 answer different questions
HS or tariff codes classify goods, while S10 identifies the postal item carrying those goods. One parcel can contain several commodity classifications under one S10. Never replace the tracking ID with a product or customs code because both appear near the word “number.” Field labels, namespace metadata and relational QA should make each identifier’s role explicit.
47. Declared value and weight are separate attributes
Postal records may show declared customs value, insured value, postage, gross weight or chargeable weight near the tracking number. None of those values are encoded in the S10. Translate their labels and units carefully while preserving separate fields. OCR and table extraction should be checked so nearby digits cannot be concatenated into the identifier or shifted onto another item row.
48. Operational location codes are not the country suffix
Postal networks can use office-of-exchange codes and other facility identifiers. Those codes provide more detailed operational location information than the final two S10 letters. Translate facility names from verified metadata and keep each code system separate. When the user asks where an item actually entered or moved through the network, event location data is stronger evidence than interpreting the S10 suffix alone.
49. Origin events are better evidence of physical posting location
Because special postal arrangements can complicate the meaning of the final country code, physical origin should be established from acceptance events, office information and operator records. A translated timeline can say where the item was accepted when that fact is supported, while leaving the S10 unchanged. This avoids turning identifier structure into a geographic claim it was never designed to guarantee.
50. Tracking aggregators can add their own identifiers
Commercial tracking services may generate internal shipment IDs, request IDs or cache keys while displaying the postal S10. Those platform identifiers belong to the aggregator, not the UPU standard. Preserve them if operationally useful, but label them separately. Customer support should quote the actual S10 when contacting a postal operator so the investigation reaches the correct system.
51. Complaint translations must preserve chronology
Claims and complaints often quote several tracking events. If translated events are sorted differently, timestamps lose time-zone context or one row picks up another item ID, the customer’s narrative becomes misleading. Keep event order, timestamp, location, event code and S10 tied together. Read the target timeline from beginning to end and verify that it describes the same journey as the source.
52. Time zone is event metadata, not S10 metadata
International items cross time zones. Event times can be stored in local time, UTC or system-specific conventions, but S10 itself does not encode time zone. Translate and format dates according to the application’s rules while preserving the source instant and zone metadata. Do not infer a time zone from the country suffix or translate a timestamp into another day without documenting the conversion.
53. Search intent: translate tracking number
Many users who search “translate tracking number” are asking whether the letters and digits should change when a shipping label changes language. For UPU S10, the identifier should remain canonical. What can be translated are the service name, event descriptions, addresses and instructions. Explain the structure so the reader understands why the code is preserved rather than simply telling them never to translate numbers.
54. Search intent: decode an S10 number
Decoding means explaining the structure—the two-letter service indicator, serial, check digit and country suffix—not converting the code into a target-language equivalent. Use current UPU data when interpreting service indicators and be careful not to overstate geographic origin from the suffix. If the user needs live tracking, the canonical S10 should be entered unchanged in the postal operator’s tracking system.
55. Search intent: translate registered-mail status
A registered item can move through acceptance, dispatch, transit, customs, delivery attempt, collection or final delivery. The translation task is to render each event precisely while keeping the same item identity throughout. Build target terminology from postal definitions rather than ordinary conversational synonyms, because a small verb change can alter what the customer thinks has happened.
56. Search intent: translate EMS tracking
EMS users often paste the same identifier into different national tracking pages. This is a practical example of why S10 must survive language change unchanged. Each site can localize the event message and service explanation while the code remains the stable lookup key. QA should test the same S10 across the localized interface and confirm that only language presentation changes.
57. Worked example: a leading zero disappears
A registered item’s serial begins with zero. A CSV is opened in spreadsheet software, the serial becomes numeric and the first zero disappears. The target article or tracking export now contains a different identifier although no translator edited it. The repair is to return to the authoritative source, restore the fixed-width string and lock the field as text before continuing.
58. Worked example: the suffix is misread as physical origin
A customer-service translation states that an item was posted in the country represented by the last two letters. The operational record shows acceptance through an extraterritorial office elsewhere. The revised translation uses the verified acceptance location and stops treating the suffix as universal origin evidence. The S10 remains unchanged because the identifier itself was not wrong—the interpretation was.
59. Worked example: SSCC and S10 coexist
A postal logistics operation uses a GS1 SSCC for a logistics unit while the customer-facing international item carries an S10. Both codes are valid and useful at different layers. Translation preserves both, labels them clearly and retains the system mapping. Removing one to “simplify” the target would break either warehouse or postal traceability.
60. Worked example: OCR corrupts the service indicator
A scanned receipt turns the first service letter into a digit. Structural validation immediately shows that the first position should be alphabetic, and the check digit also fails. The reviewer does not guess the intended letter. Instead, the electronic postal record supplies the canonical S10. This is the right relationship between automated detection and authoritative correction.
61. Worked example: a right-to-left tracking portal
An Arabic portal displays all customer-facing statuses in Arabic but isolates the S10 as a left-to-right token. Users can select and copy it into another postal website without reordering. Dates and ordinary numbers follow the locale’s presentation rules, while the S10 remains in its canonical interoperable form. This is successful localization: the interface adapts and the identity does not drift.
62. Reference route: UPU S10 standard
The Universal Postal Union publishes Standard S10 for identification of postal items, including the fixed thirteen-character structure, service indicator, serial number, check digit and country code. Use the official standard or current UPU standards resources when structural questions matter. Third-party tracking guides can be useful for consumers, but production translation should anchor technical claims in the governing postal standard.
63. Reference route: UPU check-digit validation
UPU standards resources include a check-digit validation tool for S10. That tool is useful for detecting internal inconsistencies without authorizing the translator to rewrite the source. If validation fails, retrieve the canonical identifier from the postal system. Verification tools should narrow uncertainty, not encourage automatic correction of evidence.
64. Postal labels can change language without changing item identity
A sender receipt, customs form, customer portal and destination-country tracking site can display different languages around the same international item. That is exactly why a stable identifier matters. When rebuilding a label or translated tracking view, source S10 from structured postal data and regenerate the surrounding text from localization resources rather than retyping the code from artwork.
65. Connection to postal-address translation
eduKateSG already has a specialist owner for postal addresses and address formats. That page handles house numbers, street order, locality structure and postal codes; this page owns S10 item identity and tracking events. The two topics meet on shipping labels but should remain separate search owners so readers can find the exact problem they need without creating a competing broad translation hub.
66. Connection to GS1 logistics identity
eduKateSG also has specialist GS1 logistics owners for SSCC and related identifiers. Postal operations can carry both UPU and GS1 identity layers. This article does not duplicate the GS1 material; it explains the international postal item key, its tracking history and the translation errors unique to S10. Cross-linking should clarify the boundary rather than merging the two standards.
67. Connection to Vocabulary Learning and How English Works
Postal statuses use deceptively ordinary words—accepted, dispatched, arrived, retained, attempted, delivered—that have precise operational meanings. The protected Vocabulary Learning Hub and How English Works ecosystem support careful word choice and sentence interpretation, while this specialist page protects the item identifier and event semantics.
68. Connection to the master translation architecture
This specialist article sits beneath eduKateSG’s Master Art of Translation — Technical Translation System. The master owns general specifications, terminology, QA and change control. This page has one narrower responsibility: preserving UPU S10 postal-item identity while service language, tracking messages and customer guidance move across languages.
69. Release checklist
Before release, verify that every S10 has thirteen characters in the correct alpha-numeric pattern; preserve the service indicator, eight-digit serial, check digit and final country code; retain leading zeros; validate the check digit; distinguish S10 from order numbers, customs references and GS1 keys; avoid treating the ending country code as guaranteed physical origin; protect identifiers from machine translation, OCR, digit shaping and right-to-left reordering; preserve tracking-event chronology; and compare every target event to the same source item ID.
Then perform linguistic QA on service names, postal events, operator names, addresses, customs descriptions and customer instructions. The S10 tells the network which item is moving; translation tells the reader what is happening to that item. Both must remain accurate.
70. Final rule: translate the postal journey, preserve the postal item identity
International mail crosses languages, operators, customs systems and transport networks. The UPU S10 identifier provides a stable reference that lets all of those events belong to one item. Translate the tracking messages, service descriptions and customer guidance clearly, but keep the thirteen-character identifier unchanged so every reader and system is still following the same letter, parcel or EMS item.