To translate IMEI, IMSI, ICCID and EID information accurately, a translator must separate four different layers of mobile identity: the device, the subscriber, the SIM or profile, and the embedded UICC. Telecom documents, eSIM workflows, device-management screens, support tickets and provisioning files often place these identifiers beside ordinary words. The text can be translated; the identifiers normally cannot. One changed digit can turn a clear mobile record into the wrong device, subscription or profile.
This guide explains how to translate mobile-network documents without changing IMEI numbers, IMSIs, ICCIDs or eSIM EIDs. It solves a specific high-intent translation problem: what does each identifier identify, which parts must remain exact, how should labels and explanatory text be localized, and how can a multilingual workflow preserve the relationship between equipment, subscription, physical or virtual SIM profile and eUICC?
The governing rule is identify the identity layer before translating the visible string. GSMA describes the IMEI as a 15-digit device identifier; GSMA eSIM specifications distinguish the EID as the unique identifier of an eUICC and ICCID as the identifier of a profile, while IMSI identifies the mobile subscriber identity used by the network. These are related but not interchangeable. This specialist branch connects to Master Art of Translation, the protected Vocabulary Learning Hub, and How English Works without replacing the broader telecom or localization architecture.
A one-minute orientation: four identifiers, four jobs
The easiest way to prevent mistakes is to ask what is being identified. IMEI identifies mobile equipment. IMSI identifies a subscriber identity used by the mobile network. ICCID identifies a SIM card or eSIM profile in the relevant implementation. EID identifies the eUICC itself. A phone can therefore participate in several identity systems at once.
This layered model explains why copying one long number into another field is dangerous. A customer-support screen can show all four values together because engineers need to relate device, subscription and profile. Their proximity does not make them synonyms.
1. Mobile identifiers are structured data, not translatable vocabulary
Long digit strings can look visually simple, which makes them easy to underestimate. They participate in authentication, provisioning, device checks, troubleshooting and inventory processes. Treat them as protected data tokens. Translate their labels and explanations, but preserve the assigned values.
Do not localize digits, insert spaces for readability unless the system permits it, or transliterate characters into another script. A document can be fully translated while the identifier remains exactly as the source system supplied it.
2. IMEI identifies mobile equipment
GSMA describes the International Mobile Equipment Identity as a 15-digit identifier used for mobile equipment. The GSMA IMEI database documentation separates it into the Type Allocation Code, a serial portion and a check digit. For translation purposes, that means the number is identity infrastructure. It is not a sentence, product name or telephone number.
Translate “IMEI,” “Device IMEI,” “Primary IMEI” or explanatory text according to the interface style, but do not rewrite the 15 digits. If the device exposes more than one IMEI because it supports multiple modem identities, preserve the labels that distinguish them.
3. TAC is part of the IMEI structure
The first eight IMEI digits form the Type Allocation Code in current GSMA practice. Device manufacturers obtain TAC allocations through the GSMA process. A translator may encounter TAC in device certification, network analytics or support tools.
Do not translate TAC digits or infer a marketing model name from them without an authoritative lookup. The visible brand name is human-facing product information; TAC is structured allocation data. Keep them linked but separate.
4. The IMEI check digit is not decoration
The final IMEI digit participates in validation. Dropping it because a form wraps badly or a spreadsheet shortens the value creates an incomplete identifier. Validation can detect some transcription mistakes, but a valid IMEI copied from the wrong row is still wrong.
Use two checks: exact source-target comparison and contextual device matching. A correct fifteen-digit string must still belong to the device described by the translated record.
5. IMEI and phone number are different identities
A phone number belongs to a telephony addressing and subscription context; IMEI belongs to the equipment. A user can move a subscription between devices, and a device can be used with different subscriptions. Translators should not place a telephone number under an IMEI label simply because both are numeric.
When support text says “Enter your IMEI, not your mobile number,” the contrast is meaningful. Translate it explicitly. The sentence teaches the user which identity layer the workflow expects.
6. Dual-SIM devices can expose multiple IMEIs
Modern devices can support two cellular identities or multiple radio paths and may expose IMEI 1 and IMEI 2. Do not collapse them into one generic “IMEI” row in translation. The numbering can matter during carrier registration and troubleshooting.
Preserve ordinal labels, slot labels and any relationship to physical SIM or eSIM capabilities. If the source interface distinguishes “IMEI (SIM 1)” and “IMEI (SIM 2),” keep that distinction unless the product team provides a different localized model.
7. IMEI SV is not the same visible object as a standard IMEI
GSMA material distinguishes IMEI from IMEI SV, where software-version digits can be included with the equipment identity structure. A translator who sees sixteen digits should not assume the source has an ordinary 15-digit IMEI with a typo.
Translate the label accurately and preserve the supplied value. If the field is unfamiliar, verify the product specification rather than forcing it into a more familiar identifier format.
8. IMSI identifies the mobile subscriber identity used by the network
IMSI stands for International Mobile Subscriber Identity. It belongs to the subscriber identity used in mobile-network operation, not to the physical handset. A subscriber profile can therefore have an IMSI even when the device is replaced.
In translation, preserve the IMSI value and translate only labels or explanatory prose. Do not expose IMSI unnecessarily in public-facing material: it is operational subscriber data and should be handled according to the project’s security and privacy rules.
9. IMSI and ICCID are not interchangeable SIM numbers
Support staff sometimes use informal phrases such as “SIM number,” which can create ambiguity. IMSI identifies subscriber identity in the network. ICCID identifies the integrated-circuit card or profile identity. A single screen can display both because they solve different tasks.
When translating an ambiguous source label, do not guess which code was intended. Check the field length, system schema and product documentation, then translate the label with enough precision to keep the two concepts separate.
10. MCC and MNC are components of subscriber-network context
IMSI structure includes mobile-country and mobile-network information under telecommunications standards. The surrounding terms Mobile Country Code and Mobile Network Code may be translated or expanded for readers, but the numeric codes are structured values.
Do not turn an MCC into a translated country abbreviation or an MNC into the localized operator brand. Codes and display names are related metadata fields, not substitutes.
11. ICCID identifies a SIM card or eSIM profile identity
GSMA eSIM specifications use ICCID as the Integrated Circuit Card Identifier and, in consumer eSIM workflows, as the identifier for a profile. The value is carried as structured data. It may contain nineteen or twenty displayed characters depending on implementation and padding conventions.
Do not shorten an ICCID because a spreadsheet removes a final character or leading digits. Store it as text, not as an arithmetic number. The fact that it consists mainly of digits does not make numeric formatting appropriate.
12. ICCID is not the same thing as the eSIM EID
An eUICC can hold profiles. ICCID identifies a profile or card identity within the relevant system, while EID identifies the eUICC. If a user deletes and installs profiles, profile identifiers can change while the hardware eUICC retains its EID.
This difference should be made explicit in translated help content. “Find your EID” and “Find your ICCID” are not two ways of asking for the same number.
13. EID identifies the eUICC, not the mobile subscription
GSMA SGP.29 states that the main purpose of the EID is to provide a unique global serial number for eUICCs and distinguishes it from service-subscription identity. Current GSMA eSIM documentation represents EID as a 32-digit value.
Translate “eUICC Identifier,” “EID,” and surrounding instructions naturally, but preserve all digits. Do not use an ICCID or IMSI merely because it is easier for the customer to find.
14. The eUICC is not simply “the SIM card” in every explanatory context
Consumer language often calls everything “eSIM,” but technical documentation distinguishes the eUICC platform from downloadable profiles and subscription data. A translation can be user-friendly while retaining the distinction when the workflow depends on it.
For general users, you may explain EID as the identifier of the device’s eSIM hardware or eUICC. For engineering documentation, retain the precise eUICC terminology. Audience determines explanation depth, not identifier meaning.
15. Activation codes are another identity layer
eSIM installation can involve activation codes, SM-DP+ addresses, confirmation codes and other provisioning data. These are functional strings. Do not translate their contents simply because they contain readable text or punctuation.
Translate the instruction “Enter activation code” while preserving the code itself. If a QR code encodes provisioning data, the visible instructional text can be localized while the encoded payload remains exactly what the service provider issued.
16. QR codes can hide mobile identity and provisioning data
A QR image may encode an activation address or other machine-readable content. Do not recreate the QR from a translated phrase. If the project requires a localized graphic, keep the machine payload unchanged unless the mobile operator explicitly supplies a different target-market payload.
After localization, scan the QR with an appropriate test device and compare the decoded content. Visual similarity is not enough; the encoded value is what matters.
17. Support tickets often mix all four identifiers
A troubleshooting ticket can show Device IMEI, IMSI, ICCID and EID in consecutive lines. That makes the ticket compact for engineers but risky for translators. One row shift can attach every code to the wrong label.
Lock the value column and translate only the label and free-text columns. After export, compare field order and identifier values against the source. Row integrity matters as much as character integrity.
18. Device serial number is not automatically the IMEI
Manufacturers often assign their own serial numbers in addition to the IMEI. A device settings page can display both. Preserve the source labels and never map “Serial Number” to IMEI unless the product documentation explicitly defines it that way.
This mirrors a broader principle from Translate | Model Numbers, Part Numbers, Serial Numbers and Version Strings: code shape does not reveal identity type. The label and system context do.
19. MSISDN is another number translators must keep separate
Telecom systems may display an MSISDN, the numbering-plan identity commonly associated with a mobile telephone number, alongside IMSI and ICCID. A customer may know the phone number but not the IMSI. A network engineer may need both.
Translate field names precisely enough to prevent substitution. “Subscriber number,” “mobile number,” and “subscriber identity” can refer to different technical objects depending on system design. If the source is ambiguous, consult the schema rather than guessing.
20. Do not localize digits inside identifiers
Some target languages use different numeral glyphs in ordinary text. Machine identifiers usually expect ASCII decimal digits. Replacing digits in IMEI, ICCID, EID or IMSI with localized numeral shapes can break copying, validation or system input.
Keep the identifier in its system-required digit form while localizing the surrounding sentence. A well-designed interface can display target-language labels beside unchanged machine-readable values.
21. Right-to-left layouts need bidirectional testing
Arabic, Hebrew and other right-to-left interfaces can visually reorder long digit strings, Latin abbreviations, plus signs or punctuation. The underlying identifier may be correct while the display becomes confusing. This is especially risky when a support agent must read an IMEI or ICCID aloud or copy it into another system.
Test the actual target interface or PDF. Use appropriate directionality handling so the identifier remains readable in its logical order. Do not insert arbitrary spaces until it “looks right” in one editor; another application may render it differently and make the value appear reversed.
22. Spreadsheets must store identifiers as text
IMEI, IMSI, ICCID and EID are dangerous in generic spreadsheet workflows because software may convert long values to scientific notation, trim digits or remove leading zeros. The value can look compact on screen while the original identifier has already been changed underneath.
Import identifier columns explicitly as text. Disable automatic numeric formatting and never perform arithmetic on these fields. After export, compare exact source and target strings before the file returns to provisioning, billing, support or device-management systems.
23. CSV round trips can silently corrupt long numeric strings
CSV itself can preserve digit strings, but the application opening the file may infer numeric types. A 32-digit EID is especially vulnerable to precision loss in software designed around ordinary floating-point numbers. Closing and saving such a file can permanently write the damaged value back.
Use quoted text where appropriate, define import schemas, and verify exported bytes or exact field values. Translation quality includes data preservation through the tools used to perform the language work, not only linguistic correctness inside the cells.
24. OCR can turn a clean label into a wrong identifier
Phone packaging, printed service documents and screenshots may be processed with OCR. Digits such as 0, 6, 8 and 9 can be confused; small fonts can merge adjacent characters. A translator who trusts the extracted text can reproduce an OCR error perfectly.
When possible, copy values from the source device, operator portal or structured export. If the only source is an image, perform a second human verification and flag unclear characters rather than inventing them. Identity data deserves a higher verification threshold than ordinary prose.
25. Device screenshots can contain private subscriber data
Support screenshots may display IMEI, ICCID, IMSI, EID, phone number, account name and QR provisioning details together. Treat these as potentially sensitive operational records. Public educational material should redact or use fictional placeholders unless publication of real values is explicitly authorized.
Do not create realistic replacement values that might belong to actual users. Clear placeholders such as [IMEI REDACTED] or [ICCID REDACTED] communicate the field without creating false operational data or exposing subscriber information.
26. SIM slot labels are user-interface language
Labels such as “SIM 1,” “SIM 2,” “Primary,” “Secondary,” “Business,” or “Travel” can be translated according to the operating system or product glossary. The underlying ICCID, IMSI or IMEI values remain protected. This is a classic example of translatable metadata surrounding non-translatable identity.
Do not infer that “SIM 1” always means physical SIM and “SIM 2” always means eSIM across all devices. Slot behavior varies by product. Translate the actual product interface and test against the device model rather than importing a generic assumption.
27. eSIM profile status is translatable; profile identity is not
eSIM systems can show statuses such as enabled, disabled, downloaded, pending, installed or deleted. These are user-facing or operational states and can be localized. The ICCID used to identify the profile should remain unchanged, and the EID identifying the eUICC should remain a separate value.
This distinction matters in logs: “Profile 8947… disabled” contains one translatable state and one protected identifier. Translation systems should be configured to recognize both kinds of token in the same line rather than sending the entire line through unrestricted transformation.
28. Operator names can have official localized display forms
Mobile operators may use global brands, local legal names and network display names. Use the official target-market form where provided. Do not translate a brand name into a literal phrase merely because its spelling resembles an ordinary source-language word.
Network codes and subscriber identifiers are separate from display names. A translated operator name should not cause any change to IMSI, ICCID, activation data or the codes used for network selection and provisioning.
29. Roaming records add visited-network identifiers
Roaming logs can contain home-network and visited-network codes, subscriber identifiers, device identifiers and timestamps. Translation should preserve the technical record while localizing narrative explanations such as “registered on visited network,” “authentication rejected” or “data roaming disabled.”
Do not replace network codes with country names inside structured fields. If readers need explanation, add the country or operator name as a separate translated label sourced from authoritative network data. Code and explanation should remain distinguishable.
30. Provisioning errors are easier to diagnose when identity layers stay visible
A device can have a valid IMEI while the wrong ICCID is provisioned, or the expected EID can be paired with the wrong activation record. Support translation should preserve these distinctions so engineers can follow the diagnostic chain instead of receiving one vague “SIM identity problem.”
When the source says EID mismatch, ICCID mismatch or IMSI mismatch, keep that technical noun unless the target product glossary supplies an established equivalent. Precision helps support teams identify whether the failure belongs to equipment, profile, subscriber or provisioning infrastructure.
31. Error messages should identify the field without exposing more than necessary
Public-facing error messages often mask identifiers. Translate the message while preserving the masking pattern. Do not expand a partially hidden ICCID or IMEI using information from logs unless the workflow explicitly authorizes that disclosure.
For internal tools, full values may be necessary. The translation should follow the original access model, not create new disclosure. Language localization and data-governance policy are separate decisions even when they appear on the same screen.
32. APIs need field names that preserve technical meaning
An API payload might use keys such as imei, iccid or eid. Those keys are machine contracts and normally should not be translated. The API documentation explaining the keys is translatable; the JSON property names are not ordinary user-interface labels.
This is the same principle used for URLs and code: machine-facing keys remain stable while user-facing documentation changes language. If an API offers localized schema descriptions, keep them outside the actual request and response key names.
33. Logs and traces need a preserve-first translation strategy
Technical logs may mix timestamps, identifiers, status codes and English diagnostic text. Translating the entire line as prose can corrupt parsable fields. Extract or protect structured tokens first, then translate only the message component that a human reader needs to understand.
Keep original log lines available for engineers when possible. A localized explanation can sit beside the original rather than replacing the evidence. This preserves debuggability across language teams and makes it easier to compare issues with vendor documentation.
34. Build a mobile-identity field map before translation
Create a project table containing field name, identity layer, example format, translation rule, privacy level and verification source. IMEI → equipment → preserve. IMSI → subscriber identity → preserve and protect. ICCID → SIM or profile → preserve. EID → eUICC → preserve.
Add phone number, device serial number, activation code, account ID, operator name and network code as separate rows. This map prevents translators from having to rediscover system architecture one segment at a time and gives reviewers a stable QA specification.
35. Build a terminology glossary separately from the identifier map
The language glossary should contain terms such as eSIM profile, mobile subscription, device, carrier, roaming, activation, download, enable and delete. The identifier map should contain fields that must not be linguistically transformed. Mixing the two resources encourages accidental substitution.
This separation reflects the broader Vocabulary Learning Hub principle: expertise begins by knowing what kind of thing a token is. A word can need semantic translation; a code can need exact preservation.
36. Automated QA should compare source and target identifiers
Extract IMEI, IMSI, ICCID and EID fields before translation. After export, compare values exactly. Unexpected changes, missing values, additions and row shifts should all trigger review. This check is cheap to automate and catches errors that are visually hard to notice.
Pattern checks can also warn about impossible lengths or non-digit characters, but do not treat a syntactically valid value as proof of correct pairing. A correct ICCID attached to the wrong customer or profile is still wrong.
37. Worked example: one phone, one eUICC, two profiles
Imagine a fictional phone with one device IMEI and one EID. The eUICC currently stores two profiles: a work profile and a travel profile, each with its own ICCID and subscriber identity. A support table therefore contains several legitimate identifiers for one physical phone.
The translator localizes “Work Profile,” “Travel Profile,” “Enabled” and “Disabled,” but preserves IMEI, EID, both ICCIDs and the subscriber identities. The target table remains understandable because it preserves the original relationships rather than flattening everything into the ambiguous phrase “SIM number.”
38. Worked example: wrong identifier in the right format
A provisioning sheet accidentally places a valid ICCID from row 12 beside the customer in row 13. The code passes every length check. Only row-level comparison reveals the problem. This demonstrates why validation needs both syntax and relationship checking.
The translator should not “repair” the record by guessing which customer owns the profile. Flag the source discrepancy and let the responsible system owner correct it. Translation should preserve provenance rather than create unofficial subscriber assignments.
39. Error clinic: ten mistakes that ordinary proofreading can miss
One: converting IMEI to scientific notation. Two: dropping an ICCID digit. Three: translating digits into local numeral glyphs. Four: placing IMSI under “phone number.” Five: calling EID the profile ID. Six: merging IMEI 1 and IMEI 2. Seven: translating API keys. Eight: rewriting a QR activation payload. Nine: shifting rows in a spreadsheet. Ten: exposing full subscriber data in a public screenshot.
These errors share one root cause: the workflow sees strings but not identity layers. Once device, subscriber, profile and eUICC are treated as separate objects, the correct translation behavior becomes easier to specify, automate and review.
40. A practical release checklist
IMEI: preserved exactly and attached to the correct equipment record. IMSI: preserved, privacy-protected and distinguished from telephone number. ICCID: preserved as text and attached to the correct SIM or profile. EID: preserved as the eUICC identity. Slots: IMEI and SIM slot labels retained. Profiles: status translated without changing profile identifiers.
Files: no scientific notation or digit truncation. RTL: visual order tested. QR: payload verified. APIs: keys unchanged. Privacy: public outputs redacted where authorized. QA: exact field-level source-target comparison complete.
41. Frequently asked questions
Should I translate an IMEI? No. Translate the label, not the 15-digit identifier. Is IMSI the phone number? No; it is the subscriber identity used by the mobile network. Is ICCID the same as EID? No. ICCID identifies a SIM or profile identity, while EID identifies the eUICC.
Can an eSIM device have several ICCIDs? It can hold or manage multiple profiles depending on platform and configuration, so multiple profile identifiers can be associated with one eUICC over time. Can I localize the digits? Not in machine identifiers. What is the best final test? Confirm that every preserved value remains attached to the same device, subscriber, profile and eUICC as in the source.
42. Connect this specialist guide to the wider eduKateSG translation architecture
This article owns the specialist search intent of translating IMEI, IMSI, ICCID and EID information without corrupting mobile identity. It does not replace the broader telecommunications translation material or general localization system. It complements Translate | VINs, Chassis Numbers, Registration Numbers and License Plates, where physical and administrative identity must likewise remain separated.
The deeper lesson is that digital systems place human language and machine identity side by side. Good translation changes what must be understood while preserving what must remain stable. When the translator protects that boundary, multilingual telecom systems remain readable, supportable and technically trustworthy.
43. Device replacement proves why equipment and subscription identity must stay separate
Imagine a customer replaces a damaged handset but keeps the same mobile subscription. The new device has a different IMEI, while subscriber and profile information may continue through the operator’s migration process. A translation that treats IMEI as the customer’s permanent subscription number makes this ordinary support case almost impossible to explain clearly.
Translate migration instructions with explicit nouns: old device, new device, subscription, eSIM profile and eUICC. When each object is named, the associated identifier can remain attached to the correct layer throughout the handoff.
44. eSIM transfer workflows can change profiles without changing every identity layer
An eSIM transfer or reprovisioning process can issue a new profile, retire an old profile or move service to a different device. The operational details depend on carrier and platform. Translation should therefore describe the exact workflow supplied by the service provider rather than promising that every identifier will remain the same.
Use before-and-after tables when documentation is complex. Show which device, EID, ICCID and subscription state belongs to each stage. This makes identity transitions understandable without rewriting the protected values themselves.
45. Support escalation needs identifier provenance
When a ticket moves from customer service to network engineering, the receiving team needs to know where each identifier came from: device settings, packaging, operator database, QR activation record or user transcription. Translation should preserve those provenance notes because they affect confidence in the data.
A value copied directly from a provisioning system carries different evidentiary weight from a number read over the phone. Do not erase phrases such as “customer supplied,” “system detected,” or “read from device settings.” They help engineers decide what to verify next.
46. Test environments need obviously non-production identity data
Localization teams often need screenshots and sample payloads. Use vendor-approved test identifiers, synthetic placeholders or redacted values rather than real subscriber data. A realistic-looking random number can accidentally collide with a production pattern or be mistaken for a live record.
Label examples clearly as fictional or test data. This lets translators learn field relationships without training them to copy sensitive values into documentation, bug reports or public knowledge bases.
47. Regression testing should compare identity fields across every language build
A product can localize perfectly in one release and break identifiers in the next because a formatter, component or import pipeline changes. Add regression tests that compare IMEI, ICCID and EID display behavior across languages, especially right-to-left layouts and locales that use non-ASCII numeral presentation elsewhere in the interface.
Test copy buttons, QR flows, truncation, line wrapping and accessibility labels. An identifier that is visually present but copied with hidden spaces is still functionally damaged.
48. Accessibility labels must name the correct identity layer
Screen-reader text such as “Copy device IMEI” or “Show eSIM EID” is user-facing language and should be translated. The action must still target the correct value. A mistranslated accessible name can cause a blind user to copy the wrong identifier even when the visible layout is correct.
Include accessibility strings in the same terminology QA as visible labels. Verify focus order and spoken grouping so long digit strings are understandable without altering their underlying value.
49. Final audit: prove both token fidelity and relationship fidelity
The final audit should answer two questions. First, are all protected identifiers unchanged where they are supposed to be unchanged? Second, are those identifiers still attached to the correct device, subscriber, SIM profile and eUICC? Exact characters alone are not enough when rows, labels or UI bindings can shift.
Run exact comparisons, inspect a sample manually, test the localized interface and verify the most complex multi-SIM or eSIM scenario end to end. When token fidelity and relationship fidelity both survive translation, the mobile identity layer is ready for release.
Authoritative reference points
For IMEI structure and allocation, consult the GSMA IMEI Database material and TS.06 IMEI Allocation and Approval Process. For eSIM and EID practice, use the GSMA eSIM specifications and SGP.29 EID Definition and Assignment. These references reinforce the core translation rule: preserve assigned identifiers and localize the explanatory language around them.