Tone of Voice — Vulture Web

Purpose

The single source of truth for voice, tone, and wording in everything a visitor reads on vulture.aero: locales/*.yml and the blog posts in posts/.

This is the website’s counterpart to the app’s LOCALIZATION_STYLE.md. The voice is the same — one product, one personality. What differs is spelling and a handful of mechanics, and those differences are listed explicitly below so they read as decisions rather than drift.

Out of scope: README.md and docs/api/, which are written for developers, and the Terms and Privacy pages, which are legal text and are not rewritten for style.

Voice — constant

Vulture speaks like a knowledgeable co-pilot: it knows gliding, assumes you do too, and gets you the information fast.

• Write for a pilot, not a shopper. The reader already knows what a thermal, a turnpoint and an IGC file are. Explaining the basics of the sport reads as condescension; explaining what Vulture does with them is the job.
• Specific beats enthusiastic. “Half-hourly forecast steps from 06:00 to 20:00” tells a pilot something. “Powerful weather planning” does not. When a sentence could describe any app in the App Store, it is not doing any work.
• Say the thing, then stop. No build-up, no restating the benefit you just stated. The shortest version that stays accurate is the right one.
• Confident, not boastful. Describe what the app does and let the reader judge. Vulture does not need to tell anyone it is the ultimate anything.
• Clear over clever. No puns or wordplay: they fragment across eight languages and slow translation down.

Tone by surface

Surface	Tone
Home page (home, sections)	The one place with a little warmth and rhythm. Still concrete — a claim per sentence, no adjective stacking.
Why page (why)	Persuasive but evidence-led. Each block makes one argument and backs it with a specific capability.
Features page (features)	Flat and factual. A scannable inventory, not a pitch. Bullets are noun phrases, not sentences.
FAQ (faq)	Answer in the first sentence, qualify in the second. Never open with “Great question” or restate the question.
Blog posts (posts/)	Explanatory and unhurried. Walk through what the feature does and why it is built that way. First person plural is fine; so is admitting a limit.
Errors, empty states (404, open)	Plain and useful. Say what happened and what to do next.
Terms, Privacy	Leave alone. Legal register, changed only for accuracy.

The rules that decide most edits

Spelling: British English

Locked. analyse, optimise, customise, synchronise, visualise, favourite, colour, centre, organise.

This deliberately differs from the app, which is locked to US English. The split is intentional — the site reads as British prose, the app UI stays US — and it creates exactly one rule to remember:

When you quote a label, button, or menu item from the app, spell it exactly as the app spells it. The surrounding prose stays British.

So: “the Distance optimization group shows your optimised distance”. The bolded label is the app’s; the prose is ours. Never silently re-spell a UI string to match the page, because a reader is going to go looking for it on screen.

Capitalisation: sentence case

Headings, page titles, section titles, buttons, and blog post titles are sentence case. Capitalise the first word and proper nouns; nothing else.

• Yes: “Import or create tasks”, “Your data stays yours”, “How PEV cylinder starts work”
• No: “Import or Create Tasks”, “Your Data Stays Yours”, “How PEV Cylinder Starts Work”

Title Case is an English-only construct that reads oddly in Dutch and German and is simply wrong in several of the other locales. Sentence case is the rule the app already follows, and the locale files mirror each other, so it has to hold here too.

Two known exceptions:

• Nav labels (nav.*) are uppercased in the source as a typographic treatment. That belongs in CSS rather than in content, but it is left as-is until the styling moves; do not “fix” it into sentence case on its own.
• Proper nouns keep their own casing: SkySight, WeGlide, SkyLines, Soaring Spot, openAIP, XCSoar, FLARM, LXNAV, Xctracer, Apple Watch, iCloud.

Person and address

Second person, informal, active voice. “You” and “your”, never “the user”. Vulture is “Vulture” or “it” — not “we” on marketing pages, though “we” is fine in a blog post where a person is clearly talking.

Prefer the active form: “Vulture applies the competition task” over “the competition task is applied”.

Claims must be checkable

Every capability sentence has to match what the shipping app actually does. This is the rule that has caused the most rework, so it is worth stating plainly:

• Name UI elements exactly. If the menu says “Align start”, the copy says “Align start” — not “Align task start”.
• Numbers come from the code, not from memory. Thresholds, intervals, ranges, counts and supported formats are all verifiable; go and verify them.
• Don’t describe a mechanism you haven’t read. “Detects it from your speed, climb rate, and glider type” is worse than saying nothing if only speed is used.
• Name the limit when there is one. “Signing in once per device” is more useful than implying credentials follow you around.

Numbers and units

Aviation units keep their standard abbreviations: kt, ft, hPa/inHg, m, km. Don’t expand or translate them. Write ranges with an en dash and no spaces around it (06:00–20:00, 1000–7000 m). Spell out numbers under ten in prose, use numerals for measurements and UI values.

Words and constructions to avoid

The pattern is always the same: replace the adverb or superlative with the fact it was standing in for.

Avoid	Because	Instead
effortlessly, seamlessly, easily	Adds no information. Every app claims it.	Delete, or say what makes it quick
elevate, unleash, empower, immerse	Marketing filler with no referent	Name the actual capability
ultimate, comprehensive, powerful, robust	Unfalsifiable	Give the number or the list
at your fingertips, has never been easier	Cliché	Delete
leave no detail uncovered, excels in	Boast without content	Say what is calculated
dive into, take it to the next level	Filler verbs	Use a plain verb
Whether you’re X or Y, …	Padding before the real sentence	Start at the real sentence
Your journey, your waypoints	Slogan cadence	One plain statement

Also avoid: exclamation marks outside a blog sign-off, rhetorical questions as headings, and em dashes used to stack three clauses where a full stop would do.

Before and after

Real copy from this repo.

Before. Initiate the recording of your in-flight adventure to generate an IGC file. Recording begins automatically upon acceleration, allowing you to preserve your flights within Vulture upon landing—accessible on all your Apple devices.

After. Recording starts on its own once you accelerate, and writes a standard IGC file when you land. Flights sync to your other Apple devices through iCloud.

Why: “in-flight adventure”, “initiate”, “preserve” and “upon” are doing the work that “starts”, “writes” and “land” do better. The after says the same three facts in half the words.

Before. Our platform excels in performing vital calculations, presenting you with valuable statistics. From optimized distance to altitude gained, longest leg, soaring duration, and airspace infringements, our calculations leave no detail uncovered.

After. Vulture works out optimised distance, height gain, longest leg, soaring duration and airspace infringements from your track.

Why: “our platform excels in performing vital calculations” says nothing the list does not already prove. The list is the argument.

Before. Stay ahead with weather updates from SkySight, effortlessly overlaid on your map. Plan your flight with all the essential information at your disposal.

After. Overlay SkySight’s thermal, wind, cloud and wave forecasts on your planning map, and step through the day half hour by half hour.

Why: the before could describe any weather feature. The after names the layers and the one detail a pilot actually wants to know.

Checklist before committing copy

1. Could this sentence describe a different app? Rewrite it.
2. Does every capability claim match the code? Check it.
3. Are UI labels quoted exactly, in the app’s spelling?
4. British spelling in the prose, sentence case in the headings?
5. Any word from the avoid table left in?
6. If locales/en.yml changed, is the drift against the other seven locales noted?

Keeping the translations honest

locales/ holds eight files with the same key structure. English is the source; the other seven are translated from it. Changing an English string silently leaves seven files saying something the site no longer says.

When en.yml changes, list the affected keys in the commit message so the retranslation is a deliberate, reviewable step rather than something discovered later. scripts/patch_locale.rb rewrites individual values without reformatting the rest of the file, which keeps the diff to the lines that actually changed.

Form of address — per file, as it stands

The app is informal in every language. The site is not uniform, and each file is internally consistent, which matters more than matching the app:

Locale	Form
nl	informal — je
de	informal — du
es	informal — tú
it	informal — tu
pl	informal — Ty, with the polite capitalised possessive (Twoje)
fr	formal — vous
cs	formal — vy (vykání)

Czech diverges from the app’s locked rule, which mandates tykání. Switching it means rewriting every Czech string at once, not just the ones a copy change touches — a half-informal file reads worse than a consistently formal one.

Locked terms

Domain vocabulary follows the app’s LOCALIZATION_STYLE.md glossary. Site-specific decisions on top of it:

English	Dutch	Note
task	opdracht	Locked. Not opgave — a task is an assignment. Compounds follow: opdrachtplanning, opdrachtbeheer, opdrachtdeclaratie.
leg	poot	As in poot-voor-poot-uitsplitsing. Not leg.
turnpoint	keerpunt	From the app glossary.
flight log	logboek	From the app glossary.