If you are searching for how to translate MARC 21 records, how to translate MARC tags, indicators and subfield codes, how to translate library catalogue metadata, or how to make bibliographic records understandable in another language without breaking machine-readable cataloguing, the first rule is to separate metadata structure from human-language content. Translate titles, notes, descriptions and explanatory documentation where cataloguing rules permit it; preserve MARC tags, indicator positions, subfield codes, control-field positions, identifiers and record structure exactly.
This matters in libraries, national bibliographies, university catalogues, archives, integrated library systems, discovery layers, union catalogues, digital repositories, authority files and metadata migrations. A MARC record can look like ordinary text when displayed in a catalogue, but underneath it is a carefully structured data record. A translation can read beautifully and still be technically wrong if field 245 becomes a translated tag, if a subfield code is changed, if indicators move, if an ISBN is reformatted, if an 880 linked field loses its pairing, or if a subject heading is translated without authority control.
This guide explains how to translate around MARC 21 safely. It shows what tags, indicators, subfields, fixed fields, control fields and linked-script fields actually do; how bibliographic, authority and holdings data differ; why translation is not the same as cataloguing or authority work; how MARC relates to RDA, Dewey, Library of Congress Classification, BIBFRAME, ISBN and language codes; and how to verify that multilingual catalogue records remain both readable and machine-processable. It belongs beneath eduKateSG’s Master Art of Translation architecture rather than creating a competing broad hub.
1. MARC 21 is a machine-readable record format, not a translation vocabulary
MARC stands for Machine-Readable Cataloging. MARC 21 provides formats for encoding bibliographic and related metadata so library systems can store, exchange and interpret records consistently. The structure tells software what a piece of data means and where it belongs. Human-language words live inside that structure, but the structure itself is not translated.
A safe workflow therefore asks two questions for every token: is this controlled MARC syntax, or is it human-language metadata? Tags, indicators, subfield codes and delimiters belong to the first category. Titles, notes and some descriptive content belong to the second. Confusing the two is the fastest way to turn a valid record into a broken one.
2. Three-digit MARC tags are protected technical identifiers
MARC variable fields are identified by three-digit tags such as 020, 100, 245, 264, 300, 650 and many others. The number tells cataloguing software which kind of data the field contains. It is not a section number that changes for each language.
Preserve tags exactly. Translate the label “Title Statement” or “Publication, Distribution, etc.” in documentation if needed, but never replace 245 or 264 with a local number or language-specific abbreviation. A translated catalogue interface can show friendly labels while the stored MARC field remains canonical.
3. The Leader is fixed-position structural data
Every MARC record begins with a Leader containing fixed-position values that describe record characteristics and help systems process the record. These positions are not prose. A single character can encode record status, type, bibliographic level or another structural property.
Do not translate Leader characters. Documentation may explain them in another language, but the stored values stay exactly as defined. If the translation project exposes Leader positions to human reviewers, label each position clearly and protect the actual coded character from editing.
4. The Directory maps field locations and lengths
Traditional MARC record structure includes a Directory that identifies the tags, lengths and starting positions of variable fields. It exists so software can locate data efficiently within the encoded record. This is record mechanics, not bibliographic language.
A translation process should normally operate on parsed MARC fields, not raw byte positions. If someone translates text inside an unparsed MARC record and changes byte lengths without rebuilding the structure correctly, field locations can become invalid even though the words themselves are accurate.
5. Control fields 001–009 carry special machine-readable data
Fields in the 00X range include identifiers and fixed-length control information. They do not follow the same indicator-and-subfield structure as ordinary variable data fields. A translator should never assume that every MARC field can be handled as a sentence.
Protect control numbers and fixed-position values. Translate only external documentation that explains them. If a system exports human-readable labels such as “Control Number” or “Date and Time of Latest Transaction,” localise those labels without changing the underlying field content.
6. Field 001 is record identity, not descriptive text
The 001 control field commonly contains the record control number assigned by the organisation that creates or maintains the record. That value helps systems identify the record and is not something to translate or prettify.
Keep leading zeros, punctuation and character sequence exactly as supplied by the responsible system. If a migration maps local control numbers to another database key, that is a data-conversion task with an audit trail, not a translation decision.
7. Field 003 identifies the control-number source
The 003 field can identify the organisation whose system control number appears in field 001. This relationship matters because the same number string could exist in more than one organisation’s database.
Translate the organisation name in explanatory prose if an approved form exists, but preserve the coded or registered value used in the MARC record. Record identity depends on namespace as well as digits.
8. Field 005 is a timestamp, not a sentence
The 005 field records the date and time of the latest transaction in a defined machine format. Reformatting it into a local display date inside the stored record would change the data representation.
Localise dates only in presentation layers designed for people. Keep machine timestamps canonical in MARC. This is the same principle used throughout technical translation: preserve the stored value and translate the explanation around it.
9. Field 008 is forty character positions of coded meaning
The 008 field is a fixed-length data element whose character positions encode publication dates, place, language and format-specific characteristics. Many positions contain one-letter or one-digit codes. They are compact metadata, not abbreviated prose.
Never translate individual characters by substituting target-language initials. Use MARC documentation to interpret each position. A localised cataloguing interface can display the decoded meaning, but the stored 008 string must continue to follow MARC rules.
10. Variable data fields use indicators and subfields
Most descriptive MARC fields contain a three-digit tag, two indicator positions and one or more subfields. Each layer carries meaning. A field is therefore more like a structured record than a line of free text.
Translation tools should expose enough structure that linguists can see which field and subfield they are editing. Flattening everything into one paragraph removes the context needed to translate accurately and can encourage accidental edits to non-translatable codes.
11. Indicators are positional codes, not punctuation
Variable data fields can use two indicator positions. The meaning of each position depends on the field. A blank, zero or other value can control indexing, note generation, entry form or another behaviour.
Keep indicator values exactly as defined. A target-language cataloguer may decide that a cataloguing change requires another indicator, but that is metadata editing under cataloguing rules, not ordinary translation. Translation alone should not rewrite machine behaviour.
12. A blank indicator is still meaningful
In MARC documentation, an undefined or blank indicator position is often represented by a blank marker. Translators can mistakenly delete it because it appears to contain “nothing.” Structurally, however, the position still exists.
Preserve both indicator positions even when one has no defined value. In developer documentation, explain how the display represents blanks without converting them into target-language words inside the record.
13. Subfield codes are field-specific technical codes
MARC subfields are identified by codes such as $a, $b, $c and many others. The same letter can mean different things in different fields. The semantic unit is therefore tag plus indicators plus subfield code, not the letter alone.
Never translate a subfield code into the first letter of the target-language label. Preserve the code and translate the data that belongs inside it when appropriate. Documentation can localise the subfield name separately.
14. Delimiters belong to serialization, not language
Human-readable MARC displays often show subfields with a dollar sign or another delimiter convention, while raw MARC uses control characters. The visual delimiter helps readers see structure; it is not punctuation to adapt stylistically.
Keep whichever representation the system requires. Translate text within the subfield, not the delimiter. If content is moved between MARCXML, mnemonic displays and ISO 2709 records, use proper conversion tools rather than manual replacement.
15. Field 245 is a title statement, not a single title string
Field 245 can contain the title proper, remainder of title, statement of responsibility and related information in distinct subfields. A translation that treats the entire field as one sentence can blur title boundaries and responsibility statements.
Preserve subfield structure and punctuation rules required by the cataloguing standard. If a translated title is added, record it in the appropriate field according to local policy rather than overwriting the transcription of the resource’s original title.
16. The 245 second indicator can affect title filing
In field 245, the second indicator can specify the number of nonfiling characters at the beginning of a title. That supports indexing around initial articles or other leading characters under cataloguing conventions.
A translator should not change that indicator merely because the translated display title begins with a different article. If the record itself is being recatalogued with a translated title, a qualified cataloguer must apply the appropriate rule. Translation and cataloguing remain separate decisions.
17. Field 100 carries a controlled personal-name access point
Field 100 can contain a personal name used as a main entry or authorised access point according to the record’s cataloguing context. Personal names are identity data and may have authorised forms, dates, titles and fuller forms.
Do not semantically translate a person’s name. Use the authorised form or approved script representation. If a catalogue provides a vernacular form and a romanised form, preserve their relationship through established MARC mechanisms.
18. Corporate names require authority-aware handling
Corporate bodies can have official names in several languages, historical names and subordinate units. A translator who freely localises the name can create a heading that no longer matches the authority record.
Use established authorised access points and variant-name structures. Translate explanatory notes about the organisation, not the controlled heading itself unless the authority workflow explicitly creates an authorised target-language form.
19. Field 264 separates publication, distribution, manufacture and copyright roles
Field 264 supports different production and publication functions through indicator values and subfields. “Publisher,” “distributor,” “manufacturer” and copyright information are not interchangeable merely because they appear near one another on a title page.
Translate role labels accurately in interfaces and training materials. Preserve names, places and dates according to transcription and cataloguing rules. Do not turn a distributor into a publisher because the target language uses one broad commercial term for both.
20. Place names can be transcribed, established or displayed differently
Bibliographic description often transcribes publication-place information from the resource, while authority and display layers can use established geographic names. Translation teams need to know which function a field is serving before replacing a place name with a local-language exonym.
Preserve transcribed evidence where cataloguing rules require it. Add authorised or translated access information in the appropriate field rather than rewriting the source description. This keeps the catalogue both faithful to the item and useful to searchers.
21. Publisher names are organisational identity, not ordinary nouns
A publisher’s name can look translatable because it contains ordinary words such as university, press, house or institute. Yet the legal or imprint name may have an established form that should be transcribed rather than translated.
Check the resource and cataloguing policy. Translate generic explanatory labels around the publisher, but preserve the imprint name when it is part of bibliographic evidence. If an official target-language publisher name exists, record it through an authorised mechanism rather than improvisation.
22. Field 300 describes physical extent and characteristics
Physical-description data can include extent, illustrations, dimensions and accompanying material. These terms are ordinary language but also cataloguing vocabulary with conventional abbreviations and units.
Translate according to the cataloguing standard and local policy, not conversational style. Preserve numerical values and units. Do not infer physical characteristics that the source record does not state simply because the target language expects a fuller phrase.
23. Notes in the 5XX range are not all the same kind of prose
MARC note fields cover many different purposes: general notes, bibliography notes, contents notes, language notes, source-of-description notes and more. Their wording may be free text, structured text or controlled according to local practice.
Translate the note according to its function. A contents note listing chapter titles needs different treatment from a cataloguer’s provenance note or a machine-generated source note. Keep field identity visible throughout localisation.
24. Field 505 contents notes can contain titles that need identity care
Contents notes can reproduce titles of parts, chapters or works contained in a resource. Those titles may already have official translated forms or may need to remain as printed on the resource.
Do not translate every title automatically. Determine whether the catalogue is transcribing contents, supplying a translated aid, or indexing works. When translated titles are added, distinguish them clearly from the source text.
25. Field 520 summaries are genuinely translatable but still factual
Summary, abstract or scope notes are among the most naturally translatable MARC elements. Their purpose is human comprehension. Even here, translation must preserve names, events, chronology, claims and genre accurately.
A target summary can read naturally, but it should not become a review, recommendation or rewritten synopsis. If the source note is supplied by a publisher or another agency, preserve provenance where the record records it.
26. Subject fields are controlled vocabulary, not free translation
Fields such as 650 can contain topical subject access points drawn from controlled thesauri or subject-heading systems. Translating the visible words without consulting the target-language authority system can create headings that look plausible but have no controlled identity.
Use authorised subject vocabularies where a target-language scheme exists. If no equivalent exists, keep the source heading and provide translated discovery terms in a separate local field or search layer according to catalogue policy.
27. Subject subdivisions carry hierarchy and syntax
Controlled subject strings can include topical, geographic, chronological and form subdivisions. Their order and form are governed by the subject system, not merely by grammar. A word-for-word translation can create a string that is linguistically natural but structurally invalid.
Translate through the target authority structure where possible. Preserve the relationship among main heading and subdivisions. Search synonyms can support users, but controlled subject identity should remain explicit.
28. Added entries in the 7XX range preserve related identities
Fields in the 7XX range can record additional personal, corporate, meeting, title or related-resource access points. These are often tied to authority records and relationship designators.
Do not translate names as prose. Translate relationship labels such as editor, translator, illustrator or performer using controlled terminology while keeping the authorised access point intact.
29. Series fields need title-identity discipline
A series can have a transcribed statement, an authorised access point and numbering. Translating a series title casually can break collocation, causing records from the same series to scatter in search results.
Keep transcribed and authorised forms distinct. If a translated series title is useful to readers, record it in an appropriate additional field or display layer rather than replacing the series identity used for access.
30. Field 880 supports alternate graphic representations
MARC 21 field 880 is used with linked fields to record alternate graphic representations, allowing a catalogue to connect data in different scripts. This is central to multilingual cataloguing because it lets romanised and vernacular forms coexist.
Do not treat an 880 field as a disposable translation duplicate. Preserve the linkage information that connects it to the associated field. The power of the mechanism lies in keeping two representations of the same bibliographic element explicitly related.
31. Subfield $6 carries linkage information
Linked-script fields can use subfield $6 to connect an 880 field with its associated field and identify occurrence or script-related information. This value is technical metadata, not content to translate.
Protect $6 exactly. If translation tools omit hidden or unfamiliar subfields, the record can lose the relationship between scripts even though both text strings remain present.
32. Transliteration is not the same as translation
A catalogue may romanise a title, name or publication statement so users can read or search it in another script. Transliteration changes script representation; translation changes language meaning. MARC can accommodate both functions, but they should not be confused.
If a Russian title is romanised into Latin letters, it remains Russian. A translated English title is a different metadata statement. Label each representation honestly so users know whether they are seeing pronunciation-oriented script conversion or semantic translation.
33. Field 041 encodes language information
Field 041 can record language codes for the resource and related language relationships such as translations, summaries or accompanying material. The codes belong to maintained code lists and should not be replaced with target-language initials.
Translate the displayed language name, preserve the code. If cataloguing a translation, ensure the record accurately distinguishes the language of the text from the language of the original where the field structure requires it.
34. Language of cataloguing is different from language of the resource
A resource may be in Japanese while the catalogue description is created in English, or vice versa. Metadata can also contain parallel script representations. Translators should not infer one language dimension from another.
Keep record-language, resource-language and translated-display language as separate concepts. A user changing the catalogue interface to French should not change the actual coded language of a Japanese book.
35. Field 020 protects ISBN identity
Field 020 can contain International Standard Book Numbers and qualifying information. ISBN digits, check digits and related identifiers are not translated. A qualifier such as hardcover, paperback or a binding note can require language treatment, but the number itself remains exact.
eduKateSG already has a specialist owner for ISBN, ISSN, DOI and publication identifiers. This MARC article explains how those identifiers live inside catalogue records without duplicating that broader identifier intent.
36. Field 022 protects ISSN identity
Serial records can carry an ISSN in field 022 along with related data. The identifier remains the same across catalogue languages. Translating the serial title does not create a new ISSN.
Preserve punctuation and check characters according to the standard and local MARC encoding practice. If a serial changes title and receives a different identifier, that is a bibliographic event, not a translation choice.
37. Field 024 can carry other standard identifiers
Field 024 supports standard numbers or codes not handled by certain more specialised identifier fields. Indicator values and subfields can tell systems what type of identifier is present and which agency or source applies.
Translate descriptive labels, preserve the identifier. Never infer the identifier scheme only from its shape when the field explicitly records scheme information. That context protects against confusing different namespaces with similar-looking strings.
38. MARC bibliographic records are not authority records
MARC 21 includes separate formats for bibliographic data and authority data. Bibliographic records describe resources; authority records establish and connect authorised access points, variants and related identities.
A translation project should identify which format it is editing before work begins. The same-looking name can have a different role in a bibliographic field and an authority field. Do not flatten both into one spreadsheet without format context.
39. Holdings records are another distinct MARC context
Holdings metadata describes what a particular organisation owns or can access, including locations, enumeration, chronology and copy information. It is not simply another descriptive record for the title.
Translate location names and public notes according to local policy while preserving call numbers, coded holdings values and linked identifiers. A translated discovery display should not make users believe the library owns a different issue or copy.
40. MARC classification fields are not the classification schemes themselves
MARC can carry classification numbers from systems such as Dewey Decimal Classification or Library of Congress Classification. The MARC field is the container; the classification scheme supplies the meaning of the number.
Do not translate a classification number because the catalogue language changes. eduKateSG’s separate Dewey, Library of Congress and UDC translation owner handles classification-code meaning. This article handles MARC structure around those values.
41. MARC 21 is not RDA
RDA is a content standard for resource description and access; MARC 21 is an encoding format. A cataloguer can use RDA rules to decide what data to record and MARC fields to encode that data. Translation should not conflate the two layers.
If a project localises RDA terminology, keep that governance separate from MARC syntax. A change in cataloguing instruction does not automatically imply a change in tag, indicator or subfield code.
42. MARC 21 is not BIBFRAME
BIBFRAME is a linked-data model developed to support bibliographic description on the web and is often discussed as part of the evolution beyond record-centric MARC environments. Mapping MARC to BIBFRAME is a semantic transformation, not a translation into another human language.
A bilingual project may involve both localisation and MARC-to-BIBFRAME conversion, but the two operations should have separate validation. Do not let translated labels decide ontology mappings.
43. Punctuation can come from content standards or display conventions
Legacy MARC records can contain punctuation associated with cataloguing conventions, while some modern workflows generate punctuation for display. Translators should know whether punctuation is stored data, prescribed transcription, or presentation logic.
Do not “clean up” punctuation blindly. Removing a slash, colon, semicolon or period may alter how cataloguers interpret a field or how systems display it. Follow the implementation’s punctuation policy consistently.
44. Titles of works may have established translated forms
Well-known books, films, musical works and sacred texts can have official or conventional titles in different languages. A catalogue may need to connect those forms for discovery while preserving the title as it appears on the item.
Use authorised access points and additional title fields where appropriate. Do not replace transcribed evidence with the translator’s preferred published title unless cataloguing rules explicitly call for that form in that field.
45. Edition statements are evidence, not marketing rewrites
An edition statement can distinguish a revised edition, second edition, student edition, international edition or another manifestation-level form. It can be transcribed from the resource and may contain abbreviations.
Translate edition information only according to catalogue policy and purpose. Never change the ordinal or edition status to make the wording more natural. “Second revised edition” is not interchangeable with “revised edition.”
46. Dates need bibliographic role as well as numerical accuracy
A MARC record can contain publication, copyright, distribution, manufacture and fixed-field dates. Two identical year values can represent different events. Translation that labels every year “publication date” can erase useful evidence.
Preserve the event role, not only the digits. Validate fixed fields and variable fields together where cataloguing practice requires consistency.
47. Geographic codes are not translated place names
MARC records can contain geographic area or place codes as well as spelled-out place names. Codes belong to maintained code lists; names can be displayed in a reader’s language.
Keep code and label separate. A translated country name should not overwrite a coded place value, and a historic place in a bibliographic record should not be silently modernised into a current jurisdiction.
48. Relator terms and relator codes identify relationships
MARC can express relationships such as author, editor, translator, illustrator or composer through terms and codes. The human term may need translation while a relator code remains stable.
Use controlled target-language relationship vocabulary. Do not translate the code itself. Check that the translated term still describes the same contribution, especially where one target word could cover several source roles.
49. Authority control prevents names from fragmenting across languages
A multilingual catalogue may encounter one person or organisation under several scripts, spellings, transliterations and translated names. Authority control connects those variants to one identity and chooses authorised access points according to policy.
Translation should cooperate with authority control rather than compete with it. Add variant forms where appropriate, but do not create independent uncontrolled headings for every target-language rendering.
50. Unicode enables multilingual scripts but does not remove cataloguing decisions
Modern MARC environments can carry Unicode characters, allowing many scripts to appear directly in records and displays. This reduces the need to force every resource into Latin transliteration, but it does not decide which script form should be primary or how variants should be linked.
Preserve Unicode text exactly, normalise only under documented technical rules and keep language/script metadata where the system uses it. Visual similarity between characters from different scripts is not proof that they are the same code point.
51. Legacy MARC-8 conversion is data migration, not translation
Older systems can contain MARC-8 encoded records. Converting MARC-8 to Unicode changes character encoding while aiming to preserve the same textual content. That technical conversion should be handled by tested library tools.
Do not ask translators to repair encoding artifacts by sight if the source bytes can be converted deterministically. Fix character encoding first, then translate actual language content. Otherwise mojibake can be mistaken for unfamiliar bibliographic text.
52. Right-to-left scripts need directional and field-aware testing
Arabic, Hebrew and other right-to-left scripts can appear beside Latin tags, subfield codes, identifiers and punctuation. A record editor that handles bidirectional text poorly can make field structure appear scrambled even when the underlying characters are correct.
Test editing, display, cursor movement, selection and copy-paste. Keep MARC syntax in its expected direction and let the rendering system handle script direction. Never reverse codes manually to make the screen look tidy.
53. CJK records need script and romanisation policies to remain explicit
Chinese, Japanese and Korean catalogues can contain original script, romanised forms and translated information. One record may therefore have several representations of a title or name serving different discovery purposes.
Label each representation accurately and preserve linked-field relationships. Do not treat romanisation as English translation, and do not replace original script simply because a target-language interface prefers Latin characters.
54. Search indexes can use translated access terms without rewriting MARC
A discovery layer can index synonyms, translated subject terms and alternate titles to help users search in their preferred language. Those search aids do not have to overwrite the MARC source record.
Keep the authoritative metadata layer and search-enrichment layer distinct. This allows experimentation with multilingual discovery while preserving a stable bibliographic record for exchange and long-term maintenance.
55. Machine translation should operate on selected content fields only
Sending an entire MARC export to a general translation engine exposes tags, codes, indicators and identifiers to accidental transformation. It also gives the engine little clue which text is controlled, transcribed or free-form.
Parse the record first. Select genuinely translatable fields such as approved notes or discovery descriptions, lock everything else, translate with field context, and rebuild the record through a MARC-aware library or catalogue system.
56. Generative AI can explain MARC but should not invent cataloguing data
AI can explain why field 245 differs from 246, suggest a natural translation for a summary note or compare terminology. It should not fabricate ISBNs, authority headings, subject codes, publication dates or missing indicator values.
When source data is incomplete, preserve uncertainty and route the record to a cataloguer. Plausible metadata is not bibliographic evidence. Deterministic validation and authority lookup remain essential.
57. Translation memory needs tag and subfield context
The same word can appear in a title, note, subject heading, relationship designator or local public note. Reusing one translation everywhere can be wrong because the metadata functions differ.
Store tag, indicators, subfield code, record type and vocabulary source as translation-memory context. A phrase matched in 520 should not automatically replace a controlled subject term in 650.
58. Spreadsheets can detach subfields from their records
Libraries sometimes export MARC fields to spreadsheets for batch review. Sorting one column, filtering incorrectly or pasting translated text into shifted rows can attach a correct phrase to the wrong record or subfield.
Use stable record IDs and field occurrence keys. Protect tags and subfield codes. After translation, compare record-field-subfield relationships before importing anything back into the catalogue.
59. MARCXML preserves MARC semantics in XML form
MARCXML represents MARC data using XML elements such as controlfield, datafield and subfield with attributes for tags, indicators and codes. The XML wrapper is machine syntax; the contained bibliographic data retains MARC semantics.
Do not translate element or attribute names. Localise selected subfield content only. Validate the resulting XML and, where practical, round-trip it back to MARC to confirm no field structure has been lost.
60. APIs should expose both structure and readable labels
A modern library API can return raw MARC structure plus friendly field labels or normalised JSON. Multilingual applications should keep canonical tags in the machine layer while localising labels for users.
Changing interface language should not change which field contains a title, ISBN or subject. Contract tests can compare the same record across locales to verify stable metadata identity.
61. Worked example: a bilingual book
A catalogue record describes a book with an English title page and a parallel Chinese title. The library keeps the transcribed title data in the appropriate 245 structure, records alternate script data through linked fields and provides localised notes for readers where policy allows.
The MARC tags and subfields remain unchanged. Users can search either script, while the record still exchanges cleanly with other MARC-aware systems. Translation improves discovery without rewriting bibliographic identity.
62. Worked example: a translated novel
A library acquires a French translation of a Japanese novel. The record needs to describe the French manifestation, identify the original work and record language relationships. Simply replacing the Japanese title with the French title would lose the distinction between work and manifestation.
Cataloguing rules and authority data establish the relationships. Translation assists reader-facing notes and titles where appropriate, while MARC fields preserve which title belongs to which role.
63. Worked example: a serial with identifiers and title changes
A journal changes title over time and has ISSN data, variant titles and publication notes. A multilingual catalogue translates explanatory notes but does not merge earlier and later titles into one invented translated title.
Identifiers, title relationships and chronology remain explicit. Users receive understandable local-language context without losing the publication history that serial control depends on.
64. Worked example: Arabic script with romanisation
A record contains Arabic-script title and author data plus a romanised representation. The catalogue also offers an English-language summary. These are three different functions: original-script metadata, transliteration and translation.
The 880 linkage and authorised fields keep the representations connected. The English summary is stored as descriptive content rather than replacing either title form. Users can search and understand the resource without collapsing scripts or languages.
65. A practical MARC translation workflow
Begin by identifying record format, cataloguing code, source agency, character encoding and target use. Parse MARC into structured fields. Mark tags, indicators, control fields, identifiers, authority-controlled headings and linkage subfields as protected. Select genuinely translatable content and provide tag-level context to translators.
After translation, rebuild the record through MARC-aware software. Validate structure, field repeatability, indicators, subfield codes, fixed-field lengths and identifiers. Check authority links, 880 pairings and display behaviour. Then perform ordinary linguistic review on the translated content.
66. The minimum QA checklist
Before release, verify unchanged three-digit tags; correct indicator positions; preserved subfield codes; intact control fields; fixed-length field lengths; unchanged ISBN, ISSN and other identifiers; valid authority headings; intact 880 linkages; correct language codes; valid Unicode; unchanged record control numbers; and correct record-to-field relationships after any spreadsheet or XML round trip.
Then review translated titles, notes, summaries, role labels and discovery terms for accuracy, scope and readability. Technical validity and linguistic quality are complementary. A structurally perfect record with misleading translated content is wrong, and a beautiful translation inside a structurally broken record is equally unusable.
67. Official reference route
The Library of Congress maintains the authoritative MARC 21 Format for Bibliographic Data, including field-by-field definitions, examples and updates. For record mechanics, consult the Library of Congress MARC 21 Specifications for Record Structure. Use the current documentation for the exact format and update level implemented by the catalogue.
Operational projects should also record local cataloguing policy, content standard, authority sources and encoding environment. MARC defines structure, but real catalogues combine that structure with other standards and institutional decisions.
68. Connection to vocabulary and How English Works
MARC 21 demonstrates a deep language principle: the same words mean different things depending on role, relation and structure. “Title,” “name,” “subject,” “edition,” “publisher” and “language” are ordinary vocabulary, but cataloguing gives each concept a precise function. Translators need that semantic architecture before they choose target words.
That is why this technical owner connects naturally to eduKateSG’s Vocabulary Learning Hub and How English Works ecosystem. Precise vocabulary is not about replacing one word with another; it is about understanding which concept a word activates and how that concept relates to others.
69. Connection to the master translation architecture
This article owns one narrow search intent: how to translate MARC 21 catalogue metadata without breaking tags, indicators, subfields, identifiers or bibliographic relationships. It does not compete with eduKateSG’s broader owners for literary translation, technical translation, terminology, quality assurance, machine translation or general translation process.
For general decisions about source analysis, terminology systems, translation memory, quality control and release confidence, return to the master translation architecture. Use this page when MARC 21 is the technical object that must survive the language change.
70. Final rule: translate the catalogue language, preserve the metadata architecture
Safe MARC 21 translation treats bibliographic content and record structure as separate but connected layers. Translate what readers need to understand. Preserve tags, indicators, subfield codes, control fields, identifiers, fixed positions and authority relationships. Use transliteration, translation and alternate-script representation for their proper purposes instead of treating them as interchangeable.
When those controls are respected, multilingual catalogues become richer without becoming less reliable. Readers can discover resources through their own language and script, cataloguers can preserve evidence and authority, and library systems can continue to exchange records across institutions exactly because the machine-readable structure remains stable.