To translate model numbers, part numbers, serial numbers and version strings accurately, you need to know which characters carry language and which characters carry identity. Technical documents are full of strings that look like ordinary words but function as keys: a model number can select the correct machine, a part number can determine whether a replacement fits, a serial number can identify one physical unit, and a software version can tell a technician which instructions or security fixes apply.
This guide explains how to translate technical identifiers, product model numbers, part numbers, serial numbers, SKUs, lot codes, revision labels, firmware versions and software version strings without changing the object they identify. It solves a high-intent translation problem: what should stay exactly unchanged in a manual or product document, what may be localized around the identifier, and how do you prevent one-character errors from turning a fluent translation into the wrong repair, wrong component or wrong configuration?
The core rule is conservative: identifiers are data until proven otherwise. Translate the descriptive language around them, but preserve the registered or manufacturer-defined string unless an official localized identifier exists. Then verify the target against a trusted product record, drawing, bill of materials, software release note or manufacturer catalogue. This specialist branch connects to Master Art of Translation, the protected Vocabulary Learning Hub, and How English Works without competing with those broader owners.
A one-minute orientation: technical identifiers are coordinates, not prose
Think of a model number as a coordinate in a product family. The string may encode series, size, market, voltage, generation or feature package. It may also encode nothing a translator can safely infer. Either way, changing one character can point to a different product.
A serial number is even more specific: it often identifies one manufactured unit. A part number may identify a component shared across several models. A version string may identify a software build, document revision or firmware release. These are different identifier types and should not be blended under a generic label.
The strongest translation question is: If a technician copies this target string into a catalogue, search field, diagnostic tool or service system, will it retrieve the same object as the source? If not, the identifier has been damaged.
1. Model number, serial number and part number are not synonyms
A model number usually identifies a product type or configuration. A serial number usually identifies one individual unit. A part number identifies a component or assembly. A translator should preserve these category distinctions because service instructions often ask for one specifically.
If a warranty form asks for “serial number” and the target says “model number,” the customer may submit a value shared by thousands of devices instead of the unique unit identifier. The language error becomes an operational failure.
Keep glossary entries for identifier labels as well as values. The value should usually remain unchanged; the label around it should be translated with stable terminology throughout manuals, forms and support pages.
2. Part numbers are compatibility keys
Replacement parts are frequently ordered by part number rather than by translated description. Two components can look nearly identical yet differ in connector type, tolerance, material, firmware compatibility or region. Translating or “simplifying” the part number can therefore create a physical mismatch.
Preserve punctuation, prefixes and suffixes exactly unless the manufacturer publishes a normalized format. A suffix such as “-L” may indicate left-hand orientation, “-230” may relate to voltage, or a letter may indicate revision. Do not infer and rewrite these codes from their likely meaning.
The descriptive noun can be translated—“pump assembly,” “filter cartridge,” “control board”—while the part number stays fixed. This gives the target reader both semantic understanding and exact procurement identity.
3. Serial numbers identify individual units
Serial numbers may connect a device to manufacturing date, warranty status, calibration history, service record or recall eligibility. Treat them as immutable data. Do not localize digits, insert spaces or convert letter forms for readability unless the manufacturer specifies that display format.
A serial number may contain ambiguous characters such as O and 0, I and 1, B and 8, or S and 5. Copy from a reliable digital source where possible. If transcription from a label is necessary, verify the value twice.
In support documents, translate instructions such as “The serial number is on the rear label,” but keep example serials clearly fictional or manufacturer-supplied. Never create a real-looking serial and imply it belongs to an actual device.
4. SKUs belong to inventory systems, not dictionaries
A stock keeping unit, or SKU, is an internal inventory identifier. Retailers may use different SKUs for the same manufacturer product, and regional stores may assign their own codes. The SKU should not be translated as though each character were an abbreviation.
When localizing an ecommerce catalogue, preserve the SKU tied to the target inventory system. If the localization process creates a different regional SKU, that is a commerce-system decision rather than a linguistic translation. Document the mapping explicitly.
Do not confuse SKU with barcode, EAN, UPC, GTIN or manufacturer part number. They can coexist on the same product record but serve different identification systems.
5. Version strings identify states of software and documents
Software and firmware often use strings such as 3.2.1, v5.4, 2026.09, build 4187 or release 12b. These strings may encode major, minor and patch levels or simply follow an internal scheme. Preserve the exact string unless official documentation says otherwise.
Do not assume that 2.10 is numerically the same as 2.1. In many versioning systems, minor version 10 follows minor version 9 and is newer than 2.9. Treat each segment as a version field, not a decimal fraction.
The word around the string may be localized: version, release, build, firmware, revision. The identifier itself remains stable so users can compare it with a device screen or support article.
6. Revision letters can change engineering meaning
Drawings, circuit boards and manuals may use Rev A, Rev B, Rev C or numeric revisions. A revision can represent a changed dimension, component, wiring scheme, safety instruction or document correction.
Preserve the revision designator exactly. Do not translate “Rev B” into a target-language word that drops the letter B. You can translate the label “Revision,” but the revision value must remain identifiable.
If the target document itself becomes a new controlled revision, follow the organization’s document-control process. Translation does not automatically authorize a new engineering revision number.
7. Batch and lot codes connect products to manufacturing history
Food, pharmaceuticals, chemicals, electronics and industrial components may carry batch or lot numbers for traceability. These identifiers can determine whether a product belongs to a recall, inspection group or quality investigation.
Do not translate embedded letters or reorder date-like segments unless the manufacturer explicitly defines a display transformation. A code that resembles a date may actually contain plant, line or shift information.
Translate explanatory labels such as “Lot No.” or “Batch number” consistently. If the target market has regulatory labeling requirements, apply them through the approved compliance workflow rather than by ad hoc translation.
8. Leading zeros are part of many identifiers
Spreadsheet software often converts 001247 into 1247 because it treats the cell as a number. That may be harmless for arithmetic but disastrous for identifiers. A leading zero can be part of the official code.
Store identifier columns as text when necessary. Check CSV exports and imports because automatic type detection can strip zeros, convert long codes into scientific notation or turn date-like product codes into dates.
A translation QA pass should compare identifier strings character by character, not numerically. “001247” and “1247” may be numerically equal but not textually identical.
9. Hyphens, slashes and spaces may be significant
Some identifiers require punctuation; others tolerate alternate display formats. Unless you know the manufacturer rule, preserve the source exactly. A part number AB-120/4 should not casually become AB 120-4.
Automatic typography can replace a hyphen-minus with an en dash, em dash or nonbreaking hyphen. In prose that can improve appearance; inside a searchable identifier it can prevent exact matching.
Use plain ASCII characters for machine-sensitive strings where the system expects them. Protect identifiers from smart punctuation, automatic capitalization and language-specific typographic substitution.
10. Case can be meaningful even when humans ignore it
Some systems treat uppercase and lowercase as equivalent; others do not. Product codes, license keys, build hashes and file identifiers may be case-sensitive. Preserve case unless authoritative documentation confirms normalization.
Do not apply sentence-case rules to an identifier at the beginning of a sentence. If the string starts with a lowercase letter, keep it. Rewrite the surrounding sentence if necessary so grammar does not pressure you to change the code.
Case-sensitive review is especially important after machine translation or desktop publishing, where automatic style rules may alter capitalization silently.
11. O versus 0 and I versus 1 are classic transcription traps
Technical labels often use condensed fonts that make letters and digits look similar. Optical character recognition can misread them, and human typists can repeat the error. A mistranslated manual may therefore contain a code that never existed.
Where possible, copy identifiers from structured source files rather than screenshots or scans. If you must transcribe, compare with manufacturer databases, packaging, bills of materials or device screens.
Do not “correct” a suspicious character based only on intuition. Raise a query when the evidence is ambiguous. An uncertain code should be verified, not normalized.
12. Unicode lookalikes can break exact matching
Characters from different scripts can look nearly identical: Latin A versus Cyrillic А, Latin o versus Greek omicron, hyphen-minus versus several dash characters. A string can look correct to a reader while being different at the character-code level.
This risk grows when translators switch keyboards or paste text from formatted PDFs. Technical identifiers should be preserved from the original data source whenever possible rather than retyped in another script environment.
For critical systems, use automated comparison or checksums. Visual proofreading alone cannot reliably detect every Unicode confusable.
13. Region codes and market suffixes should not be expanded casually
A model suffix may indicate region, language pack, plug type, radio band, regulatory approval or packaging bundle. The same base model can therefore have several market-specific identifiers.
Do not translate a suffix into a country name unless the manufacturer documents that meaning and the document style calls for an explanation. Keep the official string and explain the region separately.
For ecommerce localization, verify that the target-market model actually exists. Translating the source page without changing an unavailable regional model can send customers toward incompatible hardware.
14. Voltage, frequency and plug variants can hide inside a model code
Electrical equipment may use codes that distinguish 120 V from 230 V, 50 Hz from 60 Hz, single-phase from three-phase or one connector standard from another. Even if the code is opaque, the surrounding specification table can reveal the difference.
Never change a model code because the target market uses another voltage. Product localization and product substitution require engineering or commercial authorization. The translator’s job is to represent the specified product accurately.
If the document is intentionally adapted for another market, verify that the model, electrical ratings and safety instructions all change together. Partial localization can be hazardous.
15. Left/right, front/rear and handedness suffixes can be safety-critical
Automotive, medical and mechanical components often distinguish left from right or inlet from outlet through suffixes or part-number variants. Translate the descriptive label but preserve the part identifier.
Do not assume L always means left or R always means right. A manufacturer may use letters for series, material or connector family. Decode only from authoritative documentation.
Where orientation matters to safety, repeat it in plain language near the identifier: “left-hand bracket, part no. XJ-442-L.” Redundancy can help humans detect a mismatch between description and code.
16. Product names and model numbers need separate treatment
A marketed product name may be localized while the model number stays constant. For example, a device could have different consumer-facing names in different countries but share a manufacturer model identifier.
Do not merge the two fields. Keep product name, model designation and variant description distinct in catalogues and manuals. Search systems may index each differently.
If the target market uses an official localized product name, verify it on the manufacturer’s regional site. A literal translation can create a name that the company never uses.
17. File names can behave like identifiers in technical workflows
Manuals and software instructions often tell users to open a file such as FW_3.2.1.bin or MODEL-X_Config.xml. The file name is executable workflow data, not prose.
Do not translate the filename unless the localized package genuinely supplies a different file with an official target name. A translated filename in instructions can cause users to search for a file that does not exist.
Protect extensions as well. Changing .csv, .json, .bin or .pdf can alter how systems interpret the file. Translate the description around the filename, not the extension.
18. Build numbers and commit hashes should remain exact
Support documentation may identify a software state using a build number, revision hash or commit ID. These strings can be longer and less memorable than semantic version numbers, but they are often more precise.
Never shorten a hash merely for visual neatness unless the source intentionally uses an accepted short form. The number of displayed characters can be part of the project’s identification convention.
When a screenshot shows a build string, compare it with selectable text or release notes. OCR can introduce one-character errors that are hard to notice in hexadecimal strings.
19. Barcodes and QR codes should be verified against the visible text
A product label may display a human-readable number beneath a barcode. Localization can change nearby language while the encoded data remains fixed. If the label is rebuilt, ensure the barcode still encodes the intended identifier.
Do not generate a new barcode from a translated description. Barcodes encode structured identifiers, not product names. The correct source is the approved product-data system.
QR codes can encode URLs, serials, configuration strings or other data. If a QR code is replaced for localization, test it with multiple scanners and verify the destination or payload exactly.
20. Tables of specifications must keep codes aligned with the right attributes
A technical table may list model numbers in rows and dimensions, power, capacity and options in columns. Translation can widen headers and tempt a designer to rearrange the layout. Any row or column shift can pair a model with the wrong specification.
After layout, verify row identity before checking language style. Compare each model against the source table and ensure that every value remains in the correct row.
This is the same relationship-preservation principle used in Translate | Tables, Charts, Graph Labels and Figure Captions. In technical documentation, the row label may be an identifier rather than a word.
21. Technical prose can explain an identifier without decoding it
You may know that a suffix probably indicates stainless steel, a connector size or a region. Unless the manufacturer confirms that interpretation, do not expand it as fact in the translation.
A safer sentence is “Use model AB-230-S according to the equipment label” rather than “Use the 230-volt stainless model” if those expansions were not stated in the source.
Translation should reduce linguistic uncertainty without creating technical certainty that the source did not provide. Technical identifiers are especially dangerous places for plausible guessing.
22. Localized numerals may be inappropriate inside machine-readable identifiers
Some languages commonly display digits in numeral systems other than the ASCII 0–9 set. For prose quantities, localization may be appropriate. For manufacturer identifiers, ASCII digits may be required for exact matching with databases and labels.
Check the target organization’s policy. A support portal that accepts only Latin letters and ASCII digits can reject a visually equivalent localized numeral string.
When human readability and machine entry conflict, show the official identifier unchanged and translate the instructions around it. The user should be able to copy the string exactly.
23. Searchability is a quality criterion
A technical identifier should work when pasted into the manufacturer catalogue, parts database, support site or internal ERP system. If the translated document introduces punctuation or spacing that prevents search, it has reduced usability.
Test representative identifiers in the systems users actually rely on. Search behavior can reveal hidden normalization rules, such as optional hyphens or required leading zeros.
Do not optimize all identifiers for one search engine if the official printed form differs. Prefer the manufacturer’s canonical display form and add searchable variants only where the system supports aliases.
24. Controlled language around identifiers improves translation
Technical manuals become easier to translate when identifier labels are consistent: always use “model number,” not model code in one chapter and type number in another unless those are genuinely different fields.
Controlled language also helps users. “Enter the serial number shown on the product label” is clearer than “Enter the device code” when the interface field is labeled Serial Number.
This is where How English Works matters: noun phrases, modifiers and reference must make it clear which code belongs to which object. Technical accuracy depends on grammar as well as data preservation.
25. Glossaries should store meanings, while termbases should protect strings
A glossary can explain that “serial number” means the unique identifier for one manufactured unit. A termbase can enforce the approved target label. But the actual serial values should not be translated through terminology rules at all.
Use protected-pattern rules in translation software for model numbers, part numbers, URLs, file names and version strings. Regular expressions can flag unexpected changes between source and target.
Vocabulary learning and identifier protection serve different goals. The Vocabulary Learning Hub develops semantic understanding; identifier QA ensures that meaning-bearing codes remain untouched where they should.
26. Worked example: a replacement part
Imagine a fictional manual that says: “Replace the inlet valve with part no. IV-0427-B. Do not use IV-0427-A.” The two identifiers differ only in the final letter, but the source explicitly treats them as incompatible.
A careless translation might omit the suffixes, writing “Replace with IV-0427.” That erases the compatibility distinction. Another might auto-correct the hyphen or turn B into a localized letter that looks similar.
The correct target translates “inlet valve,” “part number” and the warning, while preserving both codes exactly. The warning’s contrast must remain grammatically clear so the reader cannot confuse approved and prohibited parts.
27. Worked example: firmware instructions
Suppose a device requires firmware version 3.10.2 or later. The update file is FW3102_release.bin. The manual says not to install version 3.9 on hardware revision C.
Several traps appear at once. Version 3.10.2 must not become 3.1.2. The filename must remain exact. Hardware revision C must not be translated as a generic “third version” unless the manufacturer defines it that way.
A robust target preserves all strings and translates only the instructions around them. A QA reviewer then compares the values against release notes or the product support page.
28. Worked example: a regional model family
Imagine a product family with models AX-100-US, AX-100-EU and AX-100-JP. The marketing name is translated differently in each market, but the service manual uses the exact model suffixes.
The translator should not replace “EU” with the target-language name of Europe inside the model string. The suffix belongs to the identifier. A surrounding explanation can say “EU market version” if the source supports that interpretation.
If the target document is for only one region, do not delete the other models unless the project owner explicitly scopes the manual that way. Translation should not silently reduce product coverage.
29. A release checklist for technical identifiers
Identity: Are model, part, serial, SKU, lot, revision and version fields distinguished correctly? Characters: Did any letter, digit, hyphen, slash, dot or case change? Zeros: Were leading zeros preserved? Typography: Did smart punctuation replace machine-sensitive characters?
Alignment: Are identifiers still paired with the correct product, row, image and specification? Files: Do filenames and extensions still exist? Versions: Are major, minor, patch, build and revision labels accurate? Regions: Were market suffixes left intact unless officially remapped?
Verification: Can identifiers be found in authoritative manufacturer or system records? Searchability: Can users copy and paste them successfully? Safety: Could any changed code lead to a wrong part, wrong firmware or wrong configuration? If yes, block release until verified.
30. Practice clinic: translate the label, preserve the key
Practice one: “Model No. AB-0042-X.” Translate “Model No.” but preserve AB-0042-X. Practice two: “Firmware v2.10.” Do not rewrite 2.10 as 2.1. Practice three: “Serial 0O18I5.” Verify visually ambiguous characters against an authoritative source.
Practice four: A spreadsheet removes the first two zeros from a part code. Treat the column as text and restore the canonical identifier. Practice five: A designer converts hyphens in product codes to en dashes. Revert machine-sensitive strings to the official characters.
Practice six: A market suffix looks like an English abbreviation. Do not expand or translate it unless manufacturer documentation confirms the meaning. Identifier interpretation is evidence work, not guessing.
31. Frequently asked questions
Should model numbers ever be translated? Normally no. Use an official localized model designation only when the manufacturer actually assigns one.
Can I change spaces or punctuation for readability? Only if the authoritative product system treats the forms as equivalent. Exact preservation is safer.
What if the source identifier looks wrong? Do not silently fix it. Verify against manufacturer records and raise a query. A suspected source error should remain traceable.
Are serial numbers personal data? They can sometimes be linked to ownership, warranty or service records. Handle real serials according to the project’s privacy and security requirements.
What is the strongest final test? Copy the target identifier into the same technical system or catalogue used for the source. It should retrieve the same product, part, unit or software state.
32. Connect this specialist guide to the wider eduKateSG translation architecture
This article is a specialist branch of Master Art of Translation, not a competing broad guide. It complements existing eduKateSG work on scientific notation, equations, units, technical documents and data fidelity while preserving those owners. The Vocabulary Learning Hub supports the terminology around products and components; How English Works supports the grammar that links identifiers to actions, warnings and conditions.
The practical lesson is severe but useful: technical identifiers are small strings with large consequences. Translate the explanation, not the key. Preserve every character until authoritative evidence says a localized identifier should differ. Then verify the mapping. A translation that keeps the prose elegant but corrupts the code has failed the user at exactly the moment precision matters most.