Translate | OCLC Numbers and WorldCat Record IDs

OCLC Control Numbers and WorldCat record identifiers are not ordinary prose. They are identity-bearing strings used to point readers, software and databases to the same bibliographic record in WorldCat. In translation, the safe rule is to preserve the identifier exactly while translating the surrounding human-readable explanation. A fluent target sentence is not correct if the identifier has been reformatted, localized, split, normalized or silently replaced.

This guide explains how to translate OCLC numbers accurately: what the identifier means, who assigns it, which characters are structural, how resolver or registry links work, what translators may localize, what must remain invariant, and how to run QA across documents, spreadsheets, PDFs, CAT tools, databases and multilingual publishing systems.

The central distinction is between identity and description. OCLC Control Number (OCN) identifies bibliographic record in WorldCat; the title, label, institution name, resource description or explanatory sentence describes it. Translation normally changes the description and preserves the identity string. When those two layers are mixed, a translation can remain readable while pointing to the wrong thing.

What OCLC Control Numbers and WorldCat record identifiers Are

OCLC assigns a unique control number to each bibliographic record entered into WorldCat. OCLC documentation describes the OCLC Control Number as system-supplied record data and notes that it is included when a WorldCat bibliographic record is created.

OCLC documentation identifies the OCLC number as a unique numeric identifier for a WorldCat record. In MARC-oriented workflows it appears in the bibliographic control-number context, and WorldCat search interfaces can search by OCLC number.

An OCLC number is not the same as ISBN, ISSN, DOI, call number, WorldCat Registry ID or a WorldCat Entity URI. One resource can be represented by several identifier systems, each serving a different bibliographic or organizational purpose.

The Translation Invariant

Treat the identifier as an invariant token unless the authoritative system explicitly says otherwise. Do not translate letters because they look like abbreviations, substitute locale digits, add spaces for readability, or change capitalization or punctuation merely to match target-language style. The identifier belongs to an external naming system, not to the translator’s orthographic preferences.

The surrounding prose is different. A phrase such as “identifier,” “record,” “resource,” “organization,” “entity,” “version,” “registration,” “catalog entry” or “research material” can be translated naturally. Preserve the machine-facing string; translate the human-facing explanation.

Identifier, Label and Link Are Three Different Things

Many documents place the identifier inside a URL or alongside a registry link. Separate three layers: the underlying identifier, a resolver or service URL, and the visible label shown to readers. A translation may localize the label while leaving both identifier and functional URL untouched. If the URL contains the identifier, changing one character can break resolution even when the page still looks professional.

Do not assume every URL is the canonical identifier itself. A website can change domains or route structure while the underlying identifier remains stable. In metadata work, store the canonical identifier in its dedicated field and the URL in a link field when the schema supports that separation.

Character Integrity

Identifier QA begins at the character level. Check letters, digits, separators, punctuation, slashes, periods, hyphens, underscores and prefixes. Look for characters that are visually similar but technically different, especially Unicode homoglyphs. A Latin A, Cyrillic А and Greek Α can look alike while representing different code points.

Copying through rich-text editors, OCR systems or PDF extraction can introduce nonbreaking spaces, line breaks or hidden characters. The safest workflow compares the final target identifier against the authoritative source or a trusted structured source, not against a retyped copy.

Case, Punctuation and Spacing

Even when a service appears tolerant of capitalization or punctuation differences, translation should not depend on undocumented tolerance. Preserve the authoritative representation. Do not “prettify” an identifier to match sentence case, title case or local punctuation conventions. If a source shows a prefix, separator or status component, keep it unless the governing system says the component is optional.

Numbers Must Remain Numbers, Not Localized Typography

Do not convert ASCII digits into another numbering system inside an identifier unless the identifier authority explicitly permits localized forms. The prose around the identifier can use local numerals where appropriate; the machine identifier should remain the form recognized by the registry, resolver or database.

Line Breaking and Layout

Long identifiers can wrap badly in narrow columns. Solve that as a layout problem, not by inserting visible spaces or punctuation. In web and publishing systems, use appropriate line-break opportunities or CSS. In print, allow safe line wrapping only where editorial policy permits and ensure that copying the identifier does not include an inserted character.

OCR and Scanned Documents

OCR is dangerous for identifiers because a one-character substitution can create a different string. Common confusions include O/0, I/l/1, S/5, B/8, hyphen/en dash, and slash/backslash. When translating scanned material, verify identifiers against a trusted online record or original digital source whenever possible.

Spreadsheets, CSV and Databases

Structured files add another class of risk. Spreadsheet software can strip leading zeros, convert long numeric strings to scientific notation, interpret dates, or normalize text. Import and export routines can change encoding or delimiters. Store identifiers as text unless the official schema requires another type, and validate row-by-row mappings after round trips.

Do not translate database keys. If a table contains columns for identifier, display name and description, translate only the human-readable fields. The identifier column should remain stable so that joins, lookups and reconciliation still work after localization.

CAT Tools and Translation Memory

In CAT tools, lock or protect identifiers when possible. Add them to non-translatable patterns, QA rules or placeholder logic so they are carried forward without human retyping. Translation memory should not learn a corrupted identifier as if it were a legitimate target-language variant.

For recurring projects, add a project note describing the identifier syntax and the authoritative verification route. This turns one careful decision into reusable project knowledge.

Machine Translation and LLM Risk

Machine translation and language models sometimes “help” too much: expanding prefixes, inserting spaces, normalizing punctuation, translating nearby labels into the identifier field, or converting a registry URL into prose. Treat identifiers as protected spans. If an automated workflow cannot guarantee protection, run a post-translation comparison against the source tokens.

Search, Discovery and Indexing

Identifiers often exist because names are ambiguous. Titles change, organizations rebrand, transliterations vary and resource names collide. Preserving the identifier allows search systems to connect translated descriptions to the same underlying entity. Replacing an identifier with a translated name sacrifices that function.

Metadata and APIs

When working with XML, JSON, MARC, JATS, registry metadata or application APIs, preserve the field semantics as well as the identifier string. Do not put a translated label into an identifier property, and do not move the identifier into free text if the schema provides a dedicated field.

Human-Readable Citations

A citation can contain both translatable and non-translatable components. Translate explanatory words where the publication style allows it, but preserve the identifier, version, accession or record string. If the target publication follows a citation style, apply that style without altering the identity token itself.

Five Worked Examples

Example 1: Identifier inside prose

Source: “Use OCLC 37993343 to retrieve the record.” The target may translate “use,” “retrieve” and “record,” but OCLC 37993343 stays unchanged. Do not add target-language punctuation inside the token.

Example 2: Identifier inside a registry link

If the source contains https://www.worldcat.org/oclc/37993343, translate the surrounding anchor text but preserve the functional link. Test the link after localization.

Example 3: OCR confusion

If OCR turns 37993343 into a visually similar string, do not guess. Compare with the authoritative registry or source. The QA issue is identity, not spelling.

Example 4: Spreadsheet import

If the identifier contains leading zeros, prefixes or punctuation, force text handling before importing. After export, compare the target file with the source identifier column. A translated description can change; the identifier should not.

Example 5: Localized user interface

A UI may display “OCLC Number” in the target language while retaining the original identifier underneath. This is the correct separation of interface localization from entity identity.

Common Failure Modes

Retyping instead of copying from a trusted source.
Translating a prefix or abbreviation that is part of the identifier.
Replacing ASCII digits with locale-specific digits.
Changing hyphens, slashes, periods or underscores.
Dropping a status, registry or record component.
Turning a plain identifier into a guessed URL.
Breaking the identifier across spreadsheet columns.
Letting OCR confuse look-alike characters.
Using a translated name as though it were the identifier.
Reusing a translation-memory segment containing an outdated or corrupted ID.

Preflight Workflow

Identify every OCLC Control Number (OCN) before translation begins.
Mark each occurrence as protected content.
Record the authoritative verification source.
Separate identifier fields from labels and descriptions.
Check whether historical or superseded identifier systems exist.
Decide how links will be preserved or regenerated.
Set QA rules for character-for-character comparison.

Review Workflow

Review identifiers independently from prose. First compare source and target identifier strings mechanically or visually. Then check that each identifier remains attached to the correct translated title, resource, organization or record. Finally test registry links and structured imports.

This ordering matters. A character-perfect identifier attached to the wrong translated resource is still an error. Identity has both string integrity and relationship integrity.

Quality-Assurance Table

Check	Question	Risk
String	Is every character unchanged?	Broken or wrong identity
Field	Is the ID still in the identifier field?	Schema failure
Association	Is it attached to the right translated entity?	Misidentification
Link	Does the registry or resolver still open the intended record?	Dead/wrong link
Status	Was a historical or current-status distinction lost?	Wrong administrative/scholarly object
Unicode	Did any look-alike character change code point?	Silent corruption

Training Exercises

First, give learners a paragraph containing several names, dates and one OCLC Control Number (OCN). Ask them to translate the paragraph while preserving the protected span exactly. Then compare the target token character by character.

Second, create five near-miss identifiers by changing one character, separator or prefix. Ask learners to verify them against the official source. This develops the habit of checking identity rather than trusting visual similarity.

Third, provide a CSV with identifier, name and description columns. Translate only the human-readable columns, export the file, then test whether the identifier column remains byte-for-byte stable and still maps to the same records.

Frequently Asked Questions

Should OCLC Control Number (OCN) be translated?

No. Translate the explanation around it, not the identifier string, unless the authority explicitly defines a localized form.

Can I change capitalization?

Preserve the authoritative representation. Even when a system is case-insensitive, editorial normalization can create inconsistencies and complicate matching.

Can I insert spaces for readability?

Not inside the identifier unless the official syntax includes them. Solve readability with layout, not character changes.

What if the source identifier is wrong?

Do not silently invent a correction. Verify against the authority, flag the discrepancy and follow the project’s correction policy.

Should I translate the linked page title?

You may translate visible anchor text when appropriate, but keep the link target and identifier intact.

What if the source and registry disagree?

Record the discrepancy. The translation should not hide evidence. Follow the client’s or publisher’s documented authority hierarchy.

Can machine translation handle identifiers safely?

It can, but only if the workflow protects them or verifies them afterward. Fluency is not evidence of string integrity.

What about PDFs?

Check copy/paste output because fonts, ligatures and OCR can corrupt characters. Verify critical IDs against a structured source.

What about right-to-left languages?

Bidirectional display can move punctuation visually. Preserve the logical character order and test rendering in the final interface.

Should historical identifiers be preserved?

Preserve the OCLC number that belongs to the cited WorldCat record. If a cataloging workflow merges, replaces or otherwise changes records, do not invent a new number in translation; follow the current authoritative WorldCat record and local cataloging policy.

Authoritative Verification

Use OCLC’s official documentation, including OCLC Control Number guidance and WorldCat bibliographic data. OCLC states that each WorldCat bibliographic record receives a unique OCLC Control Number.

Operating Manual: Translation Production

At intake, inventory every OCLC Control Number (OCN) and classify whether it appears as plain text, link, metadata field, API value or printed label. Decide which occurrences can be protected automatically. High-volume projects should use extraction rules so translators never have to type the identifier manually.

During drafting, translate names and explanations normally while leaving protected spans untouched. During review, run a source–target token comparison. During release, test links and structured files in the system that will actually consume them. A translation that passes visual proofreading can still fail at import time.

Operating Manual: Revision and Change Control

Identifiers can outlive surrounding prose. When a source is revised, do not assume the old identifier should change merely because the title or description changed. Conversely, if the authoritative record assigns a new identifier, do not carry the old one forward automatically. Treat identifier changes as controlled data changes with provenance.

Keep a decision log when corrections are made. Record the original source value, the verified authoritative value, the source used for verification, and who approved the correction. This prevents future translators from “fixing back” a corrected identifier.

Operating Manual: Multilingual Publishing

When the same item appears on several language sites, use the same canonical identifier across all locales. This gives analytics, search, citation tracking and deduplication a stable cross-language key. Localized titles can vary; identity should not.

If the content-management system generates locale-specific URLs, do not confuse those URLs with the external identifier. Store both where possible: one field for the canonical ID, another for the localized page URL.

Operating Manual: Data Migration

Migration is a high-risk moment because identifiers may pass through CSV exports, databases, APIs and spreadsheets. Before migration, create a checksum or reference list. After migration, compare counts and values, then sample registry behavior. Do not treat a successful file import as proof that identifiers survived.

Operating Manual: Search and Deduplication

Use identifiers to reconcile translated records that have different titles or transliterations. If two records share the same authoritative identifier, they likely refer to the same underlying object or entity even when names differ. If two different identifiers appear under one translated label, do not merge them simply because the label looks identical.

Advanced Failure: Identifier Drift Through Copy Editing

Copy editors can unintentionally corrupt identifiers while standardizing punctuation, dashes, quotation marks or capitalization. Configure style tools to exclude protected spans. A typography improvement outside the token is welcome; a typographic dash replacing an ASCII hyphen inside the token can be destructive.

Advanced Failure: Stale Identifier in Translation Memory

A translation memory can reproduce an identifier that was correct for an earlier source version but is now stale. Compare protected values against the current source before accepting high-percentage matches. Exact linguistic matches do not guarantee exact data matches.

Advanced Failure: Confusing Identifier Families

Do not confuse the OCLC number with ISBN or ISSN, which identify publication products or serials, or with the WorldCat Registry ID used for institutions. An OCN identifies the WorldCat bibliographic record. Preserve these identifier families separately.

Release Checklist

All identifier strings match the approved source or authority.
All translated labels point to the correct identifier.
All links resolve as expected.
No OCR substitutions remain.
No localized digits or punctuation were inserted.
Historical/current distinctions remain intact.
Structured exports preserve field types and delimiters.
The final rendered page displays identifiers in readable logical order.
Corrections are documented rather than silently normalized.
The hub or parent article links readers to the identifier guide.

Final Principle: Translate Meaning, Preserve Identity

Identifiers exist to keep identity stable when names, languages, interfaces and descriptions change. That stability is the asset a translator must protect. The target text can become completely different in wording while still pointing to the same bibliographic record in WorldCat.

Translate the meaning around the identifier; preserve the identifier itself; verify the final association. That three-part rule turns identifier handling from fragile copy work into a controlled multilingual data process.

Extended QA Note 1: MARC Record Integrity

A robust OCLC numbers workflow should assume that identifiers will cross more than one boundary: authoring system, translation tool, review environment, export format, content-management system and end-user interface. At each boundary, ask whether the exact identity token survived and whether it is still attached to the correct bibliographic record in WorldCat. Demonstrate the answer through comparison or registry testing rather than trusting appearance.

This check becomes more important when many locales are released together. One damaged OCLC Control Number (OCN) can propagate into search indexes, citations, APIs and downstream databases. Centralized validation is therefore more efficient than asking each language reviewer to notice the same class of error independently.

For long-term maintenance, keep the authority link and validation rule with the localization assets. Future editors should be able to see how the identifier is structured, where it can be verified and which parts are protected. Institutional memory prevents a correct translation from becoming incorrect during the next revision cycle.

Translate | OCLC Numbers and WorldCat Record IDs — Preserve Bibliographic Record Identity Across Languages