To translate UN/LOCODE location data accurately, a translator must separate the human-language name of a port, city, terminal area or trade-and-transport location from the standardized code used to identify that location in international logistics. Bills of lading, freight systems, customs data, port schedules, shipping instructions and supply-chain databases can place UN/LOCODE, subdivision data, function codes and location names together. The names may need translation or transliteration; the code and function structure normally must remain exact.
This guide explains how to translate UN/LOCODE records, shipping documents and logistics data without changing the five-character location code, ISO country prefix, location element, subdivision field or function classifier. It answers a distinct translation search intent: what UN/LOCODE identifies, how it differs from port names, airport codes and postal codes, which fields may be localized, what the function digits mean operationally, and how multilingual logistics data can remain connected to the same trade-and-transport location after translation.
The working rule is translate the human-readable place and logistics language, preserve the UN/LOCODE value and structural fields, keep the code system visible, and verify the relationship after export. UNECE Recommendation No. 16 defines UN/LOCODE as a five-character geographic coding scheme whose first two characters are the ISO 3166-1 alpha-2 country code followed by a three-character location code. The same location can carry several transport functions while retaining one UN/LOCODE. This specialist page extends the Master Art of Translation architecture without becoming a broad shipping or customs hub.
1. UN/LOCODE identifies a trade-and-transport location
UN/LOCODE is designed to identify locations relevant to international trade and transport. The code can appear beside a city or place name, but the code is not merely an abbreviation of that name. It is a maintained reference identifier used to connect transactions, schedules and logistics records across organizations.
Translation should therefore protect the code as structured identity data. The location name can move into another language; the five-character code stays the same unless the authoritative UN/LOCODE dataset itself changes.
2. The five-character structure must remain visible
Recommendation No. 16 defines the code as a two-character country component followed by a three-character location component. In compact display, the five characters are often presented together. The country portion comes from ISO 3166-1 alpha-2; the location portion identifies the place within that country context.
Do not translate the letters, insert spaces arbitrarily or replace the country component with a target-language abbreviation. Treat the full code as one protected identifier.
3. Country prefix is an ISO code, not a translated country initial
The first two characters use the ISO 3166-1 alpha-2 country code. This is another governed namespace nested inside UN/LOCODE. Translating a country name does not change the alpha-2 code. A French, Arabic or Chinese display can show a localized country name beside the same Latin-letter code.
This nested structure makes schema awareness important. The translator should understand that two letters belong to a country-code system, while the remaining three belong to the location element.
4. Location element is not free-form initials
The final three characters are assigned within the UN/LOCODE maintenance framework. They can resemble an abbreviation of the place name, but they are not recreated from a translation. A renamed or differently transliterated city does not automatically receive a new target-language three-letter element.
Always take the location code from authoritative UN/LOCODE data rather than generating it from a localized name.
5. Location name and code are independent fields
A database can contain the UN/LOCODE plus an international gazetteer name, a name without diacritics, local-language forms and user-facing translations. These name fields support human readability. The code supports machine identity. Keeping them separate allows rich multilingual display without changing transactional identity.
If a logistics platform stores only a translated place name and discards the code, reconciliation becomes harder when several places share similar names.
6. One location can have several transport functions
UNECE maintenance guidance emphasizes the one-LOCODE-per-location principle. A place with several functions receives one location code with several function positions rather than a separate code for every transport mode. This is a fundamental concept for translation and data modelling.
Do not create separate localized codes for “port,” “airport” and “rail” when the official UN/LOCODE record represents one location with multiple functions.
7. Function classifier is structured data
UN/LOCODE records include an eight-position function classifier indicating which trade or transport functions apply. The positions are machine-readable metadata, not a phrase that should be translated. Human-readable descriptions of the functions can be localized while the classifier remains exact.
A translation workflow should therefore store function digits separately from descriptive labels such as port, rail terminal, road terminal, airport or postal-exchange location.
8. Port function does not make the code a port-only code
A location with a port function can also have rail, road, airport or other functions. Calling UN/LOCODE a “port code” is understandable in shipping contexts but technically too narrow. Translators should use the broader location-code concept when the document spans multiple transport modes.
In a port-specific document, “UN/LOCODE for the port location” can be clear, but the underlying code system remains multimodal.
9. Airport function does not replace IATA or ICAO codes
A UN/LOCODE record can indicate an airport function, while the same physical or metropolitan location can also have IATA and ICAO aviation identifiers. These are separate namespaces managed for different purposes.
Do not substitute an IATA three-letter code into a UN/LOCODE field or infer the UN/LOCODE from an ICAO indicator. Translate the labels and preserve each code in its proper system.
10. Rail function is not a station code from a railway operator
A UN/LOCODE rail function indicates the location’s relevance to rail transport; national railways and ticketing systems can still use their own station identifiers. A translated logistics record should keep the UN/LOCODE and railway-specific code separate if both are supplied.
This prevents one generic “station code” label from collapsing independent systems.
11. Road-terminal function is another operational layer
Road freight hubs, border logistics points and inland terminals can be represented through relevant UN/LOCODE functions. The target language may need different words for truck terminal, road terminal, depot or logistics centre, but the function classifier remains machine data.
Use the official record and local logistics context rather than translating one generic word for every kind of road facility.
12. Postal function is not a postal code
UN/LOCODE can represent postal-exchange relevance, but a UN/LOCODE is not the same as a national postal or ZIP code. Postal codes identify delivery areas under national postal systems and often have completely different formats.
Translate “postal code” and “UN/LOCODE” distinctly. Never use one value as a replacement for the other.
13. Fixed transport function needs context
The function classifier can represent additional transport roles beyond sea, rail, road and air. Translators should rely on the current UN/LOCODE support-code documentation for the exact function definition instead of guessing from a single digit.
In human-facing prose, translate the function description accurately while leaving the coded position untouched.
14. Border-related legacy values require current guidance
UN/LOCODE maintenance documentation evolves. Current guidance notes that certain older function practices are deprecated. Translators working with historical datasets should preserve the source value and its period meaning, while current datasets should follow current support-code definitions.
Do not silently rewrite a historical record to satisfy a modern validation rule without an explicit data-migration decision.
15. Subdivision is another coded field
UN/LOCODE records can include a subdivision value based on ISO 3166-2 structure. This helps distinguish places with similar names and supplies administrative context. The subdivision code is not a translated province or state abbreviation.
Translate the subdivision name if the target displays it, but preserve the ISO-based subdivision element exactly.
16. Location-name diacritics can be meaningful
Current UN/LOCODE maintenance guidance permits diacritics in the international gazetteer name and also expects an ASCII fallback form. Translators should preserve authoritative spelling rather than stripping diacritics simply because the code itself uses a restricted character set.
This is a useful model for multilingual data: rich human names can coexist with compact standardized codes.
17. ASCII fallback is not a translation
A name without diacritics serves technical compatibility and search use cases. It is not automatically the English name and should not be treated as a translation. Keep original-language or international name, ASCII fallback and target-language display in separate fields when possible.
Conflating transliteration, diacritic removal and translation makes place-name quality difficult to audit.
18. Place names can have exonyms and endonyms
A city may have a local-language name and an established foreign-language exonym. The appropriate display depends on audience and style. UN/LOCODE provides the identity anchor so the localized name can change without losing the underlying location.
Use authoritative geographic and national sources for names when translation is uncertain. Avoid literal invention.
19. Transliteration should not create a new code
A non-Latin place name may be romanized in several ways. Those transliterations belong to human-readable naming, not to UN/LOCODE assignment. The three-character location element remains the maintained reference value.
When a source transliteration differs from the target style, preserve the code and choose the approved name form separately.
20. Similar names require subdivision and code context
Many countries contain towns with identical or similar names. Translation can make the similarity even greater if distinct local spellings collapse into one target form. Use country, subdivision and UN/LOCODE together to disambiguate.
A name-only translation workflow is therefore weaker than a code-aware workflow for logistics.
21. UN/LOCODE is not coordinates
Geographic coordinates describe a position; UN/LOCODE identifies a trade-and-transport location concept. A port area, city or terminal location can cover more than one point. Translators should not replace the code with latitude and longitude.
When both appear, preserve both and label them clearly. Coordinates and location codes answer complementary questions.
22. UN/LOCODE is not a customs office code
Customs systems can maintain their own office, declaration or border-post identifiers. A UN/LOCODE can describe the location while a customs code identifies the office or procedure endpoint. Translators should not merge them because both appear in trade documents.
Use explicit labels and preserve the namespace of each code.
23. UN/LOCODE is not EORI or trader identity
An EORI number identifies an economic operator in relevant customs systems; UN/LOCODE identifies a trade-and-transport location. A declaration can contain both. Translation should preserve the trader identifier and the location identifier independently.
This matters in audits because “who” and “where” are separate dimensions of the transaction.
24. UN/LOCODE is not the container number
Container identifiers track equipment; UN/LOCODE identifies places. A bill of lading can show container number, port of loading, port of discharge and inland destinations. Each field needs its own protected identifier rules.
Translate location labels and cargo descriptions while keeping container and location identity separate.
25. Port of loading should preserve both code and role
Shipping documents use role labels such as port of loading, port of discharge, place of receipt and place of delivery. The same location can appear in different roles across shipments. Translate the role accurately and preserve the UN/LOCODE assigned to the place.
Do not infer the role from the code. The code identifies where; the field tells you how that location functions in the shipment.
26. Place of receipt is not always a seaport
Multimodal transport can begin inland. A place of receipt can be a rail, road or logistics location long before the cargo reaches a seaport. Calling every UN/LOCODE in a maritime document a port can therefore be misleading.
Translate the shipment role and check the function metadata if the facility type matters.
27. Place of delivery can be multimodal too
The final contractual place of delivery may be inland and may use the same code system as seaports. Preserve the code and translate the contract term carefully. “Port of discharge” and “place of delivery” are not synonyms.
Legal and commercial scope can depend on that distinction.
28. Transshipment locations need separate rows or fields
A shipment can pass through several intermediate locations. Each should retain its own UN/LOCODE and event role. Translation systems should not flatten all locations into a single destination field.
Chronological and relational integrity matter as much as code spelling.
29. Vessel identity is another namespace
Maritime records can contain IMO ship number, MMSI, call sign and UN/LOCODE in the same message. The vessel identifiers answer “which ship?” while UN/LOCODE answers “which place?” Preserve all values independently.
The existing maritime identifier owner should handle ship identity; this page remains narrowly focused on trade-and-transport location identity.
30. Voyage number is not a location code
Shipping lines assign voyage references that can include letters and numbers resembling other logistics codes. A voyage number identifies a service movement or schedule context, not a place. Translate the label and preserve the value separately.
Typed fields prevent short alphanumeric strings from being confused during translation.
31. Bill of lading number is document identity
A bill of lading number identifies a transport document or shipment record. The same document can contain several UN/LOCODE values for origin, load, discharge and delivery. Do not call every code in the document a shipment number.
Preserve document identity and location identity as separate layers for auditability.
32. Terminal identifiers can sit beneath a UN/LOCODE location
Large ports and cities contain several terminals, depots and berths. Current UN/LOCODE maintenance guidance notes that subsets such as terminals or berths inside an existing location should not simply receive another ordinary top-level location code; child-code mechanisms and other identifiers can be used depending on the system.
Translation should therefore avoid pretending that one city-level UN/LOCODE uniquely identifies every terminal inside the area.
33. Berth and terminal names may need local-language preservation
Terminal names can be proper names, operator brands or numbered facilities. Translate generic descriptors only when appropriate and keep official facility names according to owner policy. The parent UN/LOCODE remains the location anchor.
If another terminal identifier is present, preserve it too rather than forcing all location detail into the UN/LOCODE.
34. Status fields belong to data maintenance, not translation
UN/LOCODE datasets can contain status and change information indicating how records are maintained. Translate human explanations of those statuses if required, but preserve the underlying status code as governed data.
A location can be added, changed or reviewed over time. Reference-data freshness matters in current logistics systems.
35. Release versions matter
UNECE publishes UN/LOCODE releases periodically, and the public site identifies release cycles and maintenance activity. A translation project using a fixed logistics dataset should record which release it used. Otherwise later code changes can make audit comparisons confusing.
For current operations, update reference data through controlled system maintenance rather than letting translators substitute values ad hoc.
36. Historical records should preserve old code context
Ports and cities can be renamed, administrative boundaries can change and location records can evolve. An archival bill of lading should retain the code and name used at the time. Modern explanatory notes can be added separately.
Translation preserves the historical transaction; data migration is a different task.
37. Database joins depend on exact code equality
UN/LOCODE is often used as a lookup key to join schedules, ports, rates, customs data and routing tables. One changed character can break the join or point to another location. Protect codes from case conversion, transliteration and whitespace insertion.
Automated equality checks should compare source and target code fields after translation.
38. Spreadsheet software can break code-name relationships
The code itself is short and robust, but spreadsheets can still damage the dataset by sorting one column without the others, trimming characters or applying broad find-and-replace rules. Use stable row keys and locked protected columns.
A valid UN/LOCODE attached to the wrong city name is still a serious error.
39. CSV needs explicit field definitions
A logistics export can include UN/LOCODE, ISO subdivision, terminal code, postal code, customs code and internal location ID. A column called “location code” is too vague. Document the namespace for each field before translation.
Schema clarity reduces human guesswork and supports automated QA.
40. JSON and XML should keep codes outside language processing
APIs can expose originLocode, destinationLocode and human-readable location names. Translate only designated display strings. Do not translate JSON keys or UN/LOCODE values in production payloads.
This allows one API response structure to support many localized interfaces without changing logistics identity.
41. EDI messages depend on exact code semantics
Electronic data interchange in shipping and trade uses coded locations inside structured messages. Translation of documentation about the EDI standard is different from editing a live message. Keep production segments and location codes machine-exact.
Localize user interfaces and manuals, not the transport syntax itself.
42. Machine translation should lock UN/LOCODE values
A five-letter code can accidentally resemble a word or abbreviation. Machine translation may lowercase, space or expand it if the text is not protected. Mark UN/LOCODE fields as non-translatable.
After translation, compare all source and target location-code sets and verify their associated names and shipment roles.
43. Translation memory can reuse the wrong port or city
Shipping instructions are repetitive, so a high translation-memory match can carry a previous shipment’s location code into the target. Treat all current shipment identifiers as variables populated from the current source.
Linguistic repetition should accelerate phrasing without freezing stale routing data.
44. OCR can misread short location codes
Scanned bills of lading and manifests can make letters hard to distinguish. Because UN/LOCODE is short, one OCR error can produce another plausible-looking code. Verify extracted values against the official dataset and the shipment context.
Use OCR as extraction assistance, not as the final authority for routing identity.
45. Right-to-left interfaces need code isolation
UN/LOCODE values use Latin letters even when displayed inside Arabic or Hebrew logistics systems. Directionality controls should keep the five-character token intact and copyable. Do not translate the letters into another script.
Test final screens, PDFs and exported spreadsheets for visual and copy-paste integrity.
46. Search intent: what does UN/LOCODE mean?
UN/LOCODE is the United Nations Code for Trade and Transport Locations, maintained by UNECE through UN/CEFACT collaboration. It identifies locations relevant to international trade and transport using a five-character code built from a two-character ISO country code plus a three-character location element.
Translate that explanation; preserve the actual code.
47. Search intent: is UN/LOCODE a port code?
It is often used for ports, but the system is broader. A location can have maritime, rail, road, air, postal and other trade-related functions. Calling it only a port-code system can mislead multimodal users.
Use “trade and transport location code” when explaining the system generally.
48. Search intent: should I translate a UN/LOCODE?
No. Translate the location name, shipment role and explanatory text. Preserve the five-character UN/LOCODE exactly. If a local-language display requires another name form, store it beside the code rather than replacing the code.
The point of the identifier is to remain stable across languages.
49. Search intent: why do I see another code for the same place?
The same place can have several identifiers from different systems: UN/LOCODE, IATA, ICAO, postal code, customs office code, terminal code and internal company code. They identify different aspects of place and operation.
Do not choose one as the universal replacement. Preserve the namespace required by the document.
50. Worked example: bill of lading
A bill of lading lists place of receipt, port of loading, port of discharge and place of delivery, each with names and location codes. The target translates the role labels and place names while preserving every UN/LOCODE, vessel identifier, container number and bill number.
QA confirms that each code remains attached to the same shipment role and that no origin and destination rows were reversed.
51. Worked example: freight booking portal
A freight platform supports English, Spanish, Chinese and Arabic. Users search localized place names, while the backend stores UN/LOCODE as the canonical location key. Search results show the localized name plus code and country, reducing ambiguity.
This architecture allows language to change without duplicating location identity.
52. Worked example: multimodal route
A shipment moves from an inland road terminal to a seaport, across the ocean, then by rail to an inland destination. The route stores a sequence of UN/LOCODE values and transport functions. The target translates instructions and status messages while preserving route order and identifiers.
The same code system can therefore support a journey involving several modes without becoming a “port-only” dataset.
53. Error clinic: valid code attached to wrong city
Sorting or copy-paste can pair a correct UN/LOCODE with another location’s translated name. Both values remain individually valid, so generic spellcheck passes. Validate code-name-country tuples against the reference dataset.
Relational QA is essential whenever structured identifiers and translated labels coexist.
54. Error clinic: IATA code substituted for UN/LOCODE
A three-letter airport code can look similar to the location element inside a five-character UN/LOCODE. Substituting one because it is more familiar changes the data system. Keep IATA and UN/LOCODE fields clearly labeled.
Code length, country prefix and field schema provide useful automatic checks.
55. Error clinic: translated country prefix
A translator may see the first two characters and assume they are initials of the country’s English name, then replace them with target-language initials. This destroys the ISO 3166 country component and therefore the UN/LOCODE.
Translate the country name separately; preserve the alpha-2 prefix.
56. Error clinic: one code per function
A poorly designed localized database may duplicate the same city into separate rows for “port,” “airport” and “rail” and invent distinct pseudo-codes. Current UN/LOCODE maintenance guidance instead emphasizes one code per location with multiple function positions.
Keep function metadata separate from the core location identity.
57. Vocabulary that logistics translators should control
Important terms include location code, port of loading, port of discharge, place of receipt, place of delivery, transshipment, terminal, berth, inland terminal, intermodal, subdivision, function classifier, shipment, bill of lading, freight forwarder, customs, carrier, consignee and consignor.
For broader word learning, route readers to the protected Vocabulary Learning Hub. This specialist page remains responsible for preserving trade-location identity.
58. How English wording can hide system boundaries
English logistics documents often say “port code,” “location code” or “terminal code” loosely. A translator should identify the actual field system before selecting the target term. The same phrase can refer to UN/LOCODE, IATA, a customs code or an internal terminal identifier.
This connects to the broader How English Works ecosystem: everyday language compresses technical distinctions that professional translation must recover from context.
59. A practical UN/LOCODE QA workflow
Extract every UN/LOCODE from the source, along with country, subdivision, name, function and shipment role. Lock the code fields. Translate names and role descriptions. After import, compare source and target code sets, validate code-name-country tuples, confirm route order and inspect any machine-readable EDI or API payloads.
This workflow catches mutation, row shift, namespace substitution and role reversal.
60. Reference verification route
Use the official UN/LOCODE service and UNECE Recommendation No. 16 for the current definition, code structure and maintenance framework. Use the official support-code and maintenance documentation for function classifiers, subdivisions and record status. For current production data, work from the relevant published UN/LOCODE release rather than an unverified third-party list.
61. Final rule: translate the place name, preserve the trade location
Global logistics works because people and systems can refer to the same places even when they use different languages. Location names can be translated, transliterated and displayed in local scripts. UN/LOCODE provides a stable trade-and-transport identity that lets those names converge on one record.
The strongest translation keeps both layers intact: understandable place language for people and exact location codes for systems. When the relationship survives, the cargo still moves through the same route the source described.