How to Proofread Technical Terms, Capitalization, and Translated Labels

Why can’t one capitalization rule settle every term?

Style guides provide useful defaults, but a product or domain may have established names that require different treatment. Google’s developer guide recommends standard American English capitalization and sentence case for headings, lists, and tables, while preserving official product names and code forms. Microsoft’s guide also favors sentence-style capitalization, but explicitly reserves capitalization for proper nouns such as its brands, products, and services. Their shared default is a starting point, not proof that a given technical term is generic. [Google’s capitalization guidance](https://developers.google.com/style/capitalization) [Microsoft’s capitalization guidance](https://learn.microsoft.com/en-us/style-guide/capitalization)

A word list can answer a different question from a general capitalization page: which spelling or usage a particular editorial guide prefers for specific terms. Google’s word list, for instance, points readers to its preferred dictionary for entries it does not cover and distinguishes style guidance from checking a technical definition in authoritative documentation. That separation is useful: editorial consistency and technical correctness need evidence from the sources suited to each question. [Google’s word list](https://developers.google.com/style/word-list)

What belongs in a proofreading term table?

Build one row for each term that could be changed inconsistently or mistranslated. This hypothetical example shows the fields and decision logic; “Sync token” and its translation are illustrative, not claims about a real product or approved terminology.

The table’s job is to preserve decisions and their limits. A permitted lowercase form should not silently become a second product name; an identifier should not be “corrected” to match prose; and an unresolved translation should remain visibly unresolved. When an official source conflicts with a local glossary, record the conflict and the source of the final decision instead of merging the forms into an unexplained list.

How do you decide the displayed spelling and case?

First identify what the term refers to: an ordinary concept, a brand or product name, a UI label, or a literal identifier. Check the relevant product documentation or glossary for the official form. Then apply the target publication’s style rules to ordinary prose, headings, and labels, retaining documented exceptions for names and identifiers. Google advises against unnecessary capitalization and warns against using case alone to distinguish meanings; Microsoft similarly says to use lowercase except for sentence starts and proper nouns in its sentence-style approach. [Google capitalization guidance](https://developers.google.com/style/capitalization) [Microsoft capitalization guidance](https://learn.microsoft.com/en-us/style-guide/capitalization)

Next, compare the form against the target organization’s word list and dictionary where appropriate. Capture the source and its version or check date so another editor can retrace the choice. Do not infer official status from an attractive-looking capitalized spelling, a search result, or a translation that resembles the English term. If sources disagree or fail to specify the form, flag the row for a decision rather than presenting a guess as settled terminology.

How should translations and interface labels be checked?

Treat translation as a meaning and context decision, not a mechanical capitalization conversion. A label may be constrained by the interface, established localized product terminology, or a different grammatical form in the target language. Compare the candidate with approved localized materials and the context in which readers will encounter it. If no authoritative localized form is available, mark the translation unresolved and request the appropriate terminology decision; do not invent a supposedly official equivalent.

After the term decision, proofread the actual label in place. Check whether capitalization follows the chosen language’s rules and the applicable product or house style. Keep the original label visible in the term record, alongside its source and status, so a future edit does not mistake a temporary translation for an approved one. If the label is also referenced in instructions, verify that the prose names the same on-screen wording.

How do you protect code and API identifiers?

Separate literal strings from editorial text before changing case. Compare identifiers character for character with the relevant API reference, schema, code, or interface. Preserve underscores, capitalization, spacing, and punctuation where the source defines them; style normalization belongs in surrounding explanation, not in a literal value. Google’s guide specifically allows all-caps or camel-case forms in official names or when referring to code that uses them. [Google capitalization guidance](https://developers.google.com/style/capitalization)

A practical review marks protected identifiers in the term table and then checks every occurrence against that reference. If a prose sentence uses a code-form term as an ordinary noun, decide whether to explain it in reader-friendly wording while keeping the literal identifier intact in code formatting. When the authoritative definition itself is unclear, record the uncertainty; a style guide cannot establish an API’s behavior or canonical field name.

What is a reliable proofreading sequence?

This sequence is a proofreading aid, not an automatic translation or universal casing rule. Its value is that it makes each editorial decision inspectable: what form was chosen, where it came from, where it applies, and what still needs a decision. For a short document, a compact table may be enough; for a large terminology set, retain the same fields in the team’s established glossary workflow.

Keep exploring this topic