Working With Text: Case, Diffs, Fonts & Translation

6 min readLast updated

Text work is mostly small, repetitive transformations: fixing capitalisation that arrived inconsistent, finding what actually changed between two drafts, cleaning a list down to unique entries, or checking a caption against a character limit. Each is trivial in isolation and each has a detail that catches people — a sort order that differs by language, a word count that disagrees with the one your editor shows, a stylish font that turns out to be unreadable to a screen reader.

Case conventions and where each belongs

Capitalisation styles are not interchangeable decoration; each convention belongs to a context, and mixing them is how codebases and content become inconsistent.

StyleExampleConventionally used for
camelCaseuserAccountIdVariables and functions in JavaScript, Java
PascalCaseUserAccountClasses, components, types
snake_caseuser_account_idPython variables, database columns
SCREAMING_SNAKEMAX_RETRY_COUNTConstants, environment variables
kebab-caseuser-account-idURLs, CSS classes, file names
Title CaseThe User AccountHeadings and titles

Title Case has genuine rules that automated converters often get wrong. Major words are capitalised and short function words — articles, coordinating conjunctions, short prepositions — are not, except when they begin or end the title. So it is 'The Rise and Fall of the Third Republic', with 'and', 'of' and the second 'the' lowercase. Style guides disagree on the preposition length cutoff, which is why two tools can produce different and equally defensible output.

Diffing: what a comparison is actually showing you

A diff finds the smallest set of insertions and deletions that turns one text into another. It does not know about intent, so it cannot tell you a paragraph moved — it reports that as a deletion in one place and an insertion in another.

The granularity determines what you can see. A line diff is the default and works well for code and configuration, where lines are meaningful units. It works poorly for prose, where a single corrected word marks the entire paragraph as changed. A word-level diff highlights just the changed words, which is far more useful when reviewing writing, contracts or documentation.

Where diffs are most valuable is the change nobody mentioned. Comparing a contract against the version you agreed, or a configuration file against the one that was working, surfaces the modification that was not in the summary — which is precisely the one worth finding.

Counting words and characters — and why totals disagree

Two tools counting the same passage will often report different numbers, and neither is broken. There is no single definition of a word. Hyphenated compounds may count as one or two. Whether numbers, standalone symbols or URLs count at all varies. Contractions are usually one word but not always.

Character limits are stricter and more consequential, because the platform enforcing one has its own definition too. Some count Unicode code points, some count UTF-16 units — under which many emoji count as two — and some count bytes, under which an accented character can cost more than a plain one. A caption that fits in one place is rejected in another for reasons that look arbitrary.

The limits worth knowing are the ones with real consequences: an SMS is 160 characters in GSM encoding but only 70 once any character forces Unicode, which is why adding one emoji can split a message into several and multiply the cost. A meta description is truncated by pixel width rather than character count, so roughly 155 characters is a guideline rather than a rule.

Sorting, deduplicating and locale collation

Cleaning a list is usually three operations: sort it, remove duplicates, and strip the empty lines. The subtleties are in what counts as order and what counts as duplicate.

Sorting by raw character codes puts all uppercase letters before all lowercase ones, so 'Zebra' sorts before 'apple'. That is correct by byte value and wrong by any human expectation. Proper alphabetical ordering is locale-aware, and the correct answer genuinely differs by language: Swedish places å, ä and ö after z, while German sorts them with a, a, and o. There is no universal ordering to fall back on.

Deduplication needs the same care. Whether entries differing only in case are duplicates depends on the data — for email addresses, usually yes; for identifiers, usually no. Trailing whitespace is the other silent culprit, since two visually identical lines differing by one trailing space are distinct strings and both survive.

Styled Unicode text and its accessibility cost

The stylish lettering people paste into social profiles is not a font. It is a set of separate Unicode characters — mathematical alphanumeric symbols, fullwidth forms, circled letters — that happen to look like styled Latin letters. That is why it survives being pasted anywhere: the styling is baked into the character choice rather than applied as formatting.

The other costs are less severe but real: these characters are excluded from search indexes and site search, so styled text is often unfindable; they break word-boundary detection, so selecting and editing behaves oddly; and they render as boxes wherever a font lacks the glyphs, which is common on older devices.

Used sparingly — a single decorative flourish in a personal bio — none of this matters much. Used for a name, a heading, or anything a reader needs to act on, it excludes people for a purely cosmetic gain.

Summarising, and what a summariser can honestly do

There are two approaches to condensing text and they fail in different ways. Extractive summarising scores the sentences already present and returns the highest-ranked ones. Abstractive summarising generates new sentences describing the content.

Extractive output is guaranteed to be faithful, because every sentence appeared verbatim in the source — it cannot invent a claim the original did not make. The trade-off is that the result reads as a set of excerpts rather than prose, and it handles a document with one argument spread across many sentences badly.

Abstractive summaries read far better and can misrepresent the source, because generating text means the output is not constrained to what was actually said. For anything where accuracy matters more than fluency — a legal document, a technical specification, a medical letter — the extractive approach is the safer instrument precisely because it is the less clever one.

Spelling things out loud without ambiguity

Reading a reference number or a surname over the phone fails on the same handful of sounds every time: m and n, s and f, b and d and p, and the whole set of similar vowels. The NATO phonetic alphabet exists because these confusions cost lives in aviation and shipping, and it works just as well for a support call.

Alfa, Bravo, Charlie, Delta and the rest were chosen after testing across accents and over poor radio links — which is why using an ad-hoc alternative ('B for bravo, D for... David?') reintroduces exactly the ambiguity the standard set was designed to eliminate. Any time you are dictating a booking reference, a postcode or a name that will be typed into a system, the standard words are worth using.

Morse code persists for a related reason: it needs almost no bandwidth and a human ear can pull it out of noise that would render speech unintelligible. It remains in use in amateur radio and aviation beacons, which still identify themselves in Morse today.

Tools in this guide

Jump to a specific task