To translate InChI, InChIKey, SMILES and PubChem CID information accurately, a translator must separate chemical structure identity from the ordinary language used to describe a compound. Scientific papers, database exports, laboratory records, regulatory files and cheminformatics tools can place chemical names, formulas, InChI strings, InChIKeys, SMILES strings and PubChem identifiers in the same record. The descriptive language may need translation; the structure representations and database identifiers normally must remain exact.
This guide explains how to translate chemical structure and database information without changing InChI strings, InChIKeys, SMILES notation or PubChem CIDs. It solves one distinct high-intent search problem: what does each representation identify, which parts may be localized, why InChIKey is not the same thing as InChI, why a PubChem CID is not a SMILES string, and how multilingual chemistry documents can stay traceable to the same structure after translation.
The working rule is translate the chemical explanation, preserve structure notations and identifiers, identify the representation system, and verify the relationship after export. InChI is a structure-based identifier developed by IUPAC and the InChI Trust; InChIKey is its fixed-length 27-character condensed representation; SMILES is a line notation for representing molecular structure; PubChem assigns CIDs to standardized compound records and SIDs to submitted substance records. These layers are related but not interchangeable.
InChI is a structure-based chemical identifier
InChI encodes chemical structure information in layered machine-readable text. Translating tokens or separators corrupts the identifier. Preserve the entire InChI string exactly. Treat the chemical explanation as translatable, the structure notation or database ID as protected, and the relationship between them as something to verify after export. This prevents a correct-looking identifier from being attached to the wrong compound.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Standard InChI has its own prefix
Standard InChI begins with InChI=1S/. Replacing the prefix with target-language text breaks parser expectations. Keep the prefix unchanged. The practical test is structural traceability. A reviewer using only the target should be able to recover the same chemical record or structure without guessing which representation a string belongs to.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Non-standard InChI can use a different prefix
Non-standard InChI can begin with InChI=1/. Assuming every valid InChI must contain 1S can create false corrections. Preserve the source form. For data files, store structure strings and IDs as text with explicit representation and namespace fields. Exclude them from locale formatting, spell-checking and generative rewriting while allowing surrounding scientific prose to be translated normally.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
InChI layers carry structured information
Formula, connectivity, hydrogens, charge, stereochemistry and isotopes can appear in layers. A translator should not rewrite a layer because it resembles chemical prose. Treat delimiters and tokens as machine syntax. A strong reviewer checks both directions: from the target chemical name to the identifier, and from the identifier back to the same standardized structure, stereochemistry and provenance.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Slash delimiters are structural
InChI uses slashes to separate layers. Replacing them with localized punctuation invalidates the string. Protect punctuation. Treat the chemical explanation as translatable, the structure notation or database ID as protected, and the relationship between them as something to verify after export. This prevents a correct-looking identifier from being attached to the wrong compound.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Semicolons can separate components
Disconnected components can be represented using semicolons within layers. Smart punctuation can alter semicolons or spacing. Keep the raw identifier. The practical test is structural traceability. A reviewer using only the target should be able to recover the same chemical record or structure without guessing which representation a string belongs to.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
No whitespace belongs inside InChI
The official syntax does not permit whitespace within an InChI string. Line wrapping or justification can insert spaces. Prevent layout tools from altering the string. For data files, store structure strings and IDs as text with explicit representation and namespace fields. Exclude them from locale formatting, spell-checking and generative rewriting while allowing surrounding scientific prose to be translated normally.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
InChI length varies
The identifier can become long for complex structures. Editors may try to shorten it for readability. Never abbreviate a production identifier. A strong reviewer checks both directions: from the target chemical name to the identifier, and from the identifier back to the same standardized structure, stereochemistry and provenance.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
InChIKey is derived from InChI
The InChIKey is a short fixed-length signature based on a hash of the InChI. It is not a human-language abbreviation. Preserve the full 27-character string. Treat the chemical explanation as translatable, the structure notation or database ID as protected, and the relationship between them as something to verify after export. This prevents a correct-looking identifier from being attached to the wrong compound.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
InChIKey uses 27 characters
The official format is always 27 characters including dash separators. Removing dashes or characters produces a different key. Keep exact form. The practical test is structural traceability. A reviewer using only the target should be able to recover the same chemical record or structure without guessing which representation a string belongs to.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
InChIKey uses uppercase English letters
The official representation uses uppercase letters and dashes. Lowercasing can make a nonstandard display. Preserve official case. For data files, store structure strings and IDs as text with explicit representation and namespace fields. Exclude them from locale formatting, spell-checking and generative rewriting while allowing surrounding scientific prose to be translated normally.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
InChIKey is not human-readable chemistry
The key is condensed for indexing and search rather than manual interpretation. Translators should not infer chemical meaning from letter sequences. Use the parent InChI or database record for meaning. A strong reviewer checks both directions: from the target chemical name to the identifier, and from the identifier back to the same standardized structure, stereochemistry and provenance.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
InChI and InChIKey are not interchangeable
One is a layered structure identifier; the other is its condensed signature. Replacing InChI with InChIKey loses information. Keep both fields when supplied. Treat the chemical explanation as translatable, the structure notation or database ID as protected, and the relationship between them as something to verify after export. This prevents a correct-looking identifier from being attached to the wrong compound.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Hash collisions are theoretically possible
InChIKey is nearly unique rather than mathematically guaranteed collision-free. Calling it an absolute one-to-one identity can overstate the design. Use precise language. The practical test is structural traceability. A reviewer using only the target should be able to recover the same chemical record or structure without guessing which representation a string belongs to.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Chemical names are a separate layer
A compound can have systematic, common and translated names. Changing the name does not change the structure identifier. Keep nomenclature and structure identity separate. For data files, store structure strings and IDs as text with explicit representation and namespace fields. Exclude them from locale formatting, spell-checking and generative rewriting while allowing surrounding scientific prose to be translated normally.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Molecular formula is another representation
Formula strings describe elemental composition but not full connectivity. Two isomers can share the same formula. Do not treat formula as a substitute for structure ID. A strong reviewer checks both directions: from the target chemical name to the identifier, and from the identifier back to the same standardized structure, stereochemistry and provenance.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
SMILES is a line notation
SMILES represents molecular structure as a compact sequence of characters. It is not ordinary text even when letters resemble element symbols. Protect the entire string. Treat the chemical explanation as translatable, the structure notation or database ID as protected, and the relationship between them as something to verify after export. This prevents a correct-looking identifier from being attached to the wrong compound.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
SMILES punctuation is semantic
Parentheses, brackets, equals signs, hashes, slashes and digits can encode structure. Typography tools can change these characters. Preserve raw syntax. The practical test is structural traceability. A reviewer using only the target should be able to recover the same chemical record or structure without guessing which representation a string belongs to.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
SMILES case can matter
Uppercase and lowercase element symbols can carry different aromaticity or atom meanings in common SMILES conventions. Global case conversion can change the represented structure. Exclude SMILES from title-case or lowercase rules. For data files, store structure strings and IDs as text with explicit representation and namespace fields. Exclude them from locale formatting, spell-checking and generative rewriting while allowing surrounding scientific prose to be translated normally.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Ring closure digits are structural
Digits in SMILES can connect atoms across the string. A spell-checker or number formatter can alter them. Treat them as code. A strong reviewer checks both directions: from the target chemical name to the identifier, and from the identifier back to the same standardized structure, stereochemistry and provenance.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Branch parentheses are structural
Parentheses represent branches in SMILES. Removing them for readability changes connectivity. Never rewrite as prose punctuation. Treat the chemical explanation as translatable, the structure notation or database ID as protected, and the relationship between them as something to verify after export. This prevents a correct-looking identifier from being attached to the wrong compound.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Bond symbols are structured
Characters such as = and # can represent bond types. Replacing them with words or typographic symbols changes syntax. Preserve machine notation. The practical test is structural traceability. A reviewer using only the target should be able to recover the same chemical record or structure without guessing which representation a string belongs to.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Stereochemical tokens are structured
Characters such as @, / and backslash can encode stereochemistry in SMILES variants. Escaping or normalization can alter the representation. Protect raw values. For data files, store structure strings and IDs as text with explicit representation and namespace fields. Exclude them from locale formatting, spell-checking and generative rewriting while allowing surrounding scientific prose to be translated normally.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Equivalent SMILES strings can represent the same structure
Different traversal choices can produce different valid SMILES for the same molecule. A text mismatch does not automatically mean a structure mismatch. Use canonicalization or structure comparison when needed. A strong reviewer checks both directions: from the target chemical name to the identifier, and from the identifier back to the same standardized structure, stereochemistry and provenance.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Canonical SMILES depends on implementation
Different software can generate different canonical SMILES conventions. Calling one text form the universal canonical truth can be misleading. Record the generating toolkit when reproducibility matters. Treat the chemical explanation as translatable, the structure notation or database ID as protected, and the relationship between them as something to verify after export. This prevents a correct-looking identifier from being attached to the wrong compound.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
SMILES is not InChI
Both can represent structure but use different standards and algorithms. Replacing one representation with the other changes the data type. Keep representation labels explicit. The practical test is structural traceability. A reviewer using only the target should be able to recover the same chemical record or structure without guessing which representation a string belongs to.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
PubChem CID identifies a standardized Compound record
PubChem assigns a non-zero integer CID to a unique standardized chemical structure in its Compound collection. It is a database record identifier, not a structure string. Preserve the CID. For data files, store structure strings and IDs as text with explicit representation and namespace fields. Exclude them from locale formatting, spell-checking and generative rewriting while allowing surrounding scientific prose to be translated normally.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
PubChem SID identifies a submitted Substance record
Each depositor substance record receives its own SID. Several SIDs can standardize to the same CID. Keep CID and SID namespaces separate. A strong reviewer checks both directions: from the target chemical name to the identifier, and from the identifier back to the same standardized structure, stereochemistry and provenance.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
CID and SID can share the same integer value
Plain numbers are ambiguous across PubChem collections. Dropping the prefix can make lookup uncertain. Store identifier type with the number. Treat the chemical explanation as translatable, the structure notation or database ID as protected, and the relationship between them as something to verify after export. This prevents a correct-looking identifier from being attached to the wrong compound.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Compound and Substance records answer different questions
CID aggregates standardized structure-level information while SID preserves depositor submissions. Replacing one with the other changes provenance. Keep collection context visible. The practical test is structural traceability. A reviewer using only the target should be able to recover the same chemical record or structure without guessing which representation a string belongs to.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
One CID can aggregate many SIDs
Multiple sources can submit records that standardize to the same structure. A translator should not collapse depositor provenance into one SID. Preserve source relationships. For data files, store structure strings and IDs as text with explicit representation and namespace fields. Exclude them from locale formatting, spell-checking and generative rewriting while allowing surrounding scientific prose to be translated normally.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
PubChem names are not the identifier
Synonyms and preferred names can change or vary. The CID remains the database anchor. Translate names separately. A strong reviewer checks both directions: from the target chemical name to the identifier, and from the identifier back to the same standardized structure, stereochemistry and provenance.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
PubChem structure standardization affects CIDs
Compound records are generated through PubChem standardization processes. A submitted SID structure can map to a standardized CID. Do not assume the raw depositor form equals the standardized representation. Treat the chemical explanation as translatable, the structure notation or database ID as protected, and the relationship between them as something to verify after export. This prevents a correct-looking identifier from being attached to the wrong compound.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
CID is not CAS RN
PubChem CID and CAS Registry Number belong to different systems. Substituting one for the other creates a false identifier. Keep namespaces explicit. The practical test is structural traceability. A reviewer using only the target should be able to recover the same chemical record or structure without guessing which representation a string belongs to.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
CID is not InChIKey
PubChem records can expose InChIKey as structure metadata. The CID is a database key while InChIKey is a structure-derived identifier. Preserve both. For data files, store structure strings and IDs as text with explicit representation and namespace fields. Exclude them from locale formatting, spell-checking and generative rewriting while allowing surrounding scientific prose to be translated normally.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Chemical structure drawings are another representation
A 2D depiction visually represents structure. Replacing a structure string with an image can reduce machine interoperability. Keep text identifiers available. A strong reviewer checks both directions: from the target chemical name to the identifier, and from the identifier back to the same standardized structure, stereochemistry and provenance.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Stereochemistry matters
Two structures with the same formula and connectivity can differ by stereochemistry. Dropping stereochemical notation can change identity. Preserve stereochemical tokens. Treat the chemical explanation as translatable, the structure notation or database ID as protected, and the relationship between them as something to verify after export. This prevents a correct-looking identifier from being attached to the wrong compound.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Isotopes matter
Isotopic labels can be encoded in structure representations. Normalizing them to common isotopes changes the substance. Keep isotope information. The practical test is structural traceability. A reviewer using only the target should be able to recover the same chemical record or structure without guessing which representation a string belongs to.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Charge matters
Formal charges appear in InChI and SMILES representations. Removing charge notation can change the represented species. Protect charge syntax. For data files, store structure strings and IDs as text with explicit representation and namespace fields. Exclude them from locale formatting, spell-checking and generative rewriting while allowing surrounding scientific prose to be translated normally.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Tautomers complicate identity
Different representations can normalize or distinguish tautomeric forms differently. A text comparison alone can mislead. Use the relevant standard and toolkit for structure comparison. A strong reviewer checks both directions: from the target chemical name to the identifier, and from the identifier back to the same standardized structure, stereochemistry and provenance.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Salts and disconnected components need care
A record can represent multiple components or salts. Removing counterions for translation simplicity changes the structure. Preserve full representation. Treat the chemical explanation as translatable, the structure notation or database ID as protected, and the relationship between them as something to verify after export. This prevents a correct-looking identifier from being attached to the wrong compound.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Mixtures are not always single-molecule identifiers
Some chemical products contain mixtures that do not map cleanly to one structure ID. Forcing one InChI or CID onto a mixture can be wrong. Preserve source scope. The practical test is structural traceability. A reviewer using only the target should be able to recover the same chemical record or structure without guessing which representation a string belongs to.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Polymer identity needs specialized handling
Polymers and variable-composition substances can exceed simple small-molecule notation assumptions. A translator should not invent missing structure IDs. Use authoritative records. For data files, store structure strings and IDs as text with explicit representation and namespace fields. Exclude them from locale formatting, spell-checking and generative rewriting while allowing surrounding scientific prose to be translated normally.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Reaction SMILES is a different data type
Reaction representations can include reactants, reagents and products in one notation. Treating them as ordinary molecule SMILES can break reaction meaning. Keep type and syntax explicit. A strong reviewer checks both directions: from the target chemical name to the identifier, and from the identifier back to the same standardized structure, stereochemistry and provenance.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
SMARTS is not SMILES
SMARTS is a pattern language related to SMILES but used for substructure queries. Calling SMARTS a molecule identifier can be misleading. Preserve representation label. Treat the chemical explanation as translatable, the structure notation or database ID as protected, and the relationship between them as something to verify after export. This prevents a correct-looking identifier from being attached to the wrong compound.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Molfile and SDF are structured formats
Chemical files contain machine-readable connection tables and metadata. Translating structural fields breaks the file. Translate only permitted metadata. The practical test is structural traceability. A reviewer using only the target should be able to recover the same chemical record or structure without guessing which representation a string belongs to.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
JSON and XML chemical APIs are machine contracts
APIs can return CID, InChI and SMILES fields in structured payloads. Translating property names inside production payloads can break software. Localize documentation, not data schemas. For data files, store structure strings and IDs as text with explicit representation and namespace fields. Exclude them from locale formatting, spell-checking and generative rewriting while allowing surrounding scientific prose to be translated normally.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Spreadsheets can damage long strings
Long InChI or SMILES values can be truncated, wrapped or interpreted as formulas. The corruption can happen before translation. Store as plain text. A strong reviewer checks both directions: from the target chemical name to the identifier, and from the identifier back to the same standardized structure, stereochemistry and provenance.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
CSV needs quoting and schema discipline
Commas and quotes inside metadata can interact with CSV parsing. A structure string should be isolated in a defined column. Validate round trips. Treat the chemical explanation as translatable, the structure notation or database ID as protected, and the relationship between them as something to verify after export. This prevents a correct-looking identifier from being attached to the wrong compound.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
OCR is unsafe for structure strings
Scanned identifiers can lose punctuation and capitalization. A one-character error can represent another structure or invalid syntax. Verify against digital source data. The practical test is structural traceability. A reviewer using only the target should be able to recover the same chemical record or structure without guessing which representation a string belongs to.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Smart punctuation is dangerous
Typography tools can replace hyphens, quotes or minus signs. Visually similar Unicode characters may not parse. Protect raw strings. For data files, store structure strings and IDs as text with explicit representation and namespace fields. Exclude them from locale formatting, spell-checking and generative rewriting while allowing surrounding scientific prose to be translated normally.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Right-to-left layouts need directionality testing
Mixed Latin identifiers and RTL prose can display in confusing order. Underlying data may be correct while copying becomes unreliable. Test final rendering. A strong reviewer checks both directions: from the target chemical name to the identifier, and from the identifier back to the same standardized structure, stereochemistry and provenance.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Machine translation should lock structure identifiers
MT can expand tokens or add spaces. A fluent target can produce invalid chemistry strings. Mask identifiers before translation. Treat the chemical explanation as translatable, the structure notation or database ID as protected, and the relationship between them as something to verify after export. This prevents a correct-looking identifier from being attached to the wrong compound.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Translation memory can carry another compound’s ID
Laboratory and catalogue templates reuse similar wording. A high TM match can insert a previous CID or InChIKey. Populate identifiers from current source. The practical test is structural traceability. A reviewer using only the target should be able to recover the same chemical record or structure without guessing which representation a string belongs to.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Search-and-replace can corrupt large datasets
Bulk punctuation or case changes can alter every SMILES string. One editorial command can damage thousands of records. Restrict edits to translatable columns. For data files, store structure strings and IDs as text with explicit representation and namespace fields. Exclude them from locale formatting, spell-checking and generative rewriting while allowing surrounding scientific prose to be translated normally.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Worked example: InChI and InChIKey
A fictional compound record provides both a Standard InChI and InChIKey. The target translates the chemical name but preserves both identifiers. Use the parent relation for verification. A strong reviewer checks both directions: from the target chemical name to the identifier, and from the identifier back to the same standardized structure, stereochemistry and provenance.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Worked example: PubChem CID and SID
A fictional supplier SID maps to a standardized PubChem CID. The target preserves depositor and compound identifiers separately. Do not merge provenance. Treat the chemical explanation as translatable, the structure notation or database ID as protected, and the relationship between them as something to verify after export. This prevents a correct-looking identifier from being attached to the wrong compound.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Worked example: two SMILES forms
Two valid SMILES strings can encode the same structure using different traversal order. A textual difference should be checked structurally rather than translated into one preferred spelling. Record the toolkit if canonicalization matters. The practical test is structural traceability. A reviewer using only the target should be able to recover the same chemical record or structure without guessing which representation a string belongs to.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Error clinic
Common failures include lowercase InChIKeys, added whitespace, punctuation changes, CID/SID swaps, case changes in SMILES and smart-quote corruption. These errors can survive fluent chemistry prose. Run dedicated structure-identifier QA. For data files, store structure strings and IDs as text with explicit representation and namespace fields. Exclude them from locale formatting, spell-checking and generative rewriting while allowing surrounding scientific prose to be translated normally.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Release checklist
InChI, InChIKey, SMILES type, PubChem CID/SID, chemical name, stereochemistry and provenance all need verification. Checking only the translated name is insufficient. Validate both token integrity and structure relationship. A strong reviewer checks both directions: from the target chemical name to the identifier, and from the identifier back to the same standardized structure, stereochemistry and provenance.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Frequently asked questions
InChI, InChIKey, SMILES and PubChem IDs should not be translated. Users often ask whether they all identify the same thing. Explain structure representation, condensed key and database-record identity separately. Treat the chemical explanation as translatable, the structure notation or database ID as protected, and the relationship between them as something to verify after export. This prevents a correct-looking identifier from being attached to the wrong compound.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Connection to eduKateSG architecture
This specialist owner protects chemical structure identity rather than broad chemical safety or nomenclature. The CAS/EC/UN owner already covers regulatory substance and transport identifiers. Use this page for structure strings and database IDs. The practical test is structural traceability. A reviewer using only the target should be able to recover the same chemical record or structure without guessing which representation a string belongs to.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Authoritative sources
InChI Trust, IUPAC and PubChem maintain the core systems discussed here. SMILES implementations can differ in canonicalization behavior. Verify identifiers and structure representations with the authoritative toolchain. For data files, store structure strings and IDs as text with explicit representation and namespace fields. Exclude them from locale formatting, spell-checking and generative rewriting while allowing surrounding scientific prose to be translated normally.
Before release, ask what the field represents: a structure string, condensed key, database compound record, depositor substance record or human-language name. The target should make that role visible rather than relying on the shape of the text.
Reference verification route
For InChI and InChIKey, use the InChI Trust and its technical documentation. For PubChem Compound and Substance identity, use PubChem’s data-organization guidance. SMILES strings should be checked with the toolkit or source system that generated them because canonicalization conventions can differ across implementations.