no-nb

Translate to Norwegian

Translate English content into Norwegian that reads like it was written in Norwegian — not translated. Tone, idiom, and rhythm matter more than word-for-word fidelity.

When this skill activates

• "Translate this to Norwegian"
• "Oversett til norsk"
• "Make a Norwegian version of "
• "Localize this for Norway"
• "Rewrite this in Norwegian"
• Any request that involves rendering existing English content as Norwegian

If the user just wants a one-off Norwegian phrase, you don't need this whole flow — answer directly. This skill is for content — emails, docs, slides, marketing copy, READMEs, posts.

First-call clarifications

Ask exactly once, only if not already obvious from context:

1. Bokmål or nynorsk? Default is bokmål. Detect a nynorsk preference from any of the following before defaulting:

   • Filename hints: *.nn.md, *.nynorsk.*, *-nn.*
   • Project config: lang: nn / language: nynorsk in YAML frontmatter or a project metadata file
   • Source content mentions nynorsk-leaning regions (Sunnmøre, Sogn, Vestland, Nordfjord, Sunnfjord, Hardanger, Voss, Setesdal, parts of Telemark/Agder)
   • User explicitly invokes the skill via "no-nn" or "translate to nynorsk"
   • Existing Norwegian text on the same site/project is in nynorsk

   When any of these fire, propose nynorsk and let the user confirm. If none fire, default to bokmål silently.

2. Audience? Inferable from content type, but if ambiguous between exec / technical / consumer / sales, ask.

Don't ask about length, in-place vs. side-by-side output, or voice — sensible defaults below.

Process

1. Read the source

If the user gave a file path, read it. If they gave a string, use it. If they gave a URL, fetch and translate the readable content (skip nav, footer, ads).

Identify:

• Format (markdown, HTML, plain text, email)
• Content type (marketing, docs, email, slide deck, blog, technical reference)
• Tone (formal, casual, technical)
• Audience if specified

2. Detect what NOT to translate

Leave alone:

• Code blocks, file paths, command-line examples
• URLs, emails, version numbers, ISO dates already in YYYY-MM-DD
• Product names supplied by the user (ask once: "Any names that must stay in English?" — common answer is the product name, the company name, and the brand)
• Technical jargon with no good Norwegian equivalent (embeddings, fine-tuning, prompt engineering — keep in English, possibly italicized)
• Markdown structure, HTML tags, JSX/MDX components

3. Translate by intent, not by word

For each paragraph:

1. Read the English. Ask: what is this paragraph trying to do? (Inform, persuade, reassure, sell, explain, instruct.)
2. Write the Norwegian version that does the same job in a Norwegian voice.
3. Re-read the Norwegian out loud (mentally). If it sounds like a translation, rewrite it.

The English source is a brief, not a template.

4. Apply Norwegian conventions

Get these right — they're the difference between "machine-translated" and "written by a Norwegian":

Punctuation & symbols

• Em dashes (—) sparingly. Norwegian writers use them less often than American writers and almost never two-or-three to a sentence. Prefer commas, periods, or parentheses. One em-dash per paragraph is fine if it earns its keep; chains of them ("X — Y — Z") read as translated and should be rewritten.
• Quote marks: «sitat» (guillemets) in formal/print writing; straight "sitat" in technical/web; never English curly “…”.
• Decimal: comma. 3,14 not 3.14.
• Thousands separator: non-breaking space (preferred) or period. 10 000 or 10.000. Never 10,000.
• Percent: space before sign. 20 % not 20%.
• Currency: 1 250 kr or kr 1 250. In prose use kroner; NOK only in finance/invoicing contexts.
• Dates: 8. mai 2026 (note period after the day) in body text; 08.05.2026 or 2026-05-08 in technical contexts. Never May 8, 2026 or 5/8/2026.
• Time: 24-hour. kl. 14.30 or 14:30. Never 2:30 PM.

Pronouns & address

• du, never De. The formal "De / Dem / Deres" is essentially obsolete in modern Norwegian. Use "du / deg / din" even in formal business writing.
• vennligst sparingly. Don't translate every English "please" as "vennligst" — Norwegian doesn't sprinkle it. Bare imperative is the polite default ("Send rapporten innen fredag", not "Vennligst send…"). One per email maximum, and only for genuinely formal asks.
• vi sparingly in marketing. "Vi gjør X, vi tilbyr Y, vi er stolte av Z" reads as boastful in Norwegian. Lead with the customer or the problem.

Capitalization (Norwegian is much more sparing than English)

• Days, months, languages, nationalities → lowercase: mandag, januar, norsk, engelsk
• Job titles → lowercase: administrerende direktør Kari Hansen
• Headings → sentence case, not Title Case

Anglicisms to actively avoid

• "ta et øyeblikk" (took a moment) → "tenkte seg om" / "nølte litt"
• "i person" (in person) → "ansikt til ansikt" / "personlig"
• "ikke nøl med å" → "ta gjerne kontakt om…"
• "føl deg fri til å" → "bare" / "spør gjerne"
• "i forhold til" used as universal "regarding" → "når det gjelder" / "om" (keep "i forhold til" only for actual comparisons)
• "Beste hilsener" (calque of "Best regards") → "Med vennlig hilsen" / "Mvh" / "Hilsen"
• "Jeg håper denne mailen finner deg vel" → cut entirely; Norwegians don't open emails this way
• "adressere problemet" → "ta tak i problemet" / "håndtere problemet"

For the deeper catalog — særskriving (split compounds), sin/sitt/sine vs. hans/hennes, bokmål/nynorsk form-consistency, V2 word order, Norwegian AI vocabulary — see the humanizer skill's Norwegian section. Apply those patterns during translation.

Sentence structure (V2) Norwegian is V2 — finite verb takes the second position in main clauses. Don't carry over English subject-first defaults:

• ❌ "I morgen jeg skal til Bergen."
• ✅ "I morgen skal jeg til Bergen."

Don't add commas after fronted adverbials the way English does:

• ❌ "I dag, det er fint vær."
• ✅ "I dag er det fint vær."

5. Audience adaptation

Match register to audience (ask if not specified):

• exec — concise, outcome-focused, less jargon. "Dette sparer dere 20 timer i uka" beats "Dette automatiserer den manuelle prosessen for deviasjonshåndtering."
• tech — precise, technical terms welcome, can leave English jargon untranslated.
• consumer — conversational, no acronyms, examples over abstractions.
• sales — direct ask, clear next step, no hedging.

6. Length control

Default to "same length ±20%". Norwegian often needs fewer words once you stop translating literally — if the natural Norwegian comes out 70–80% of the source length, that's a good sign, not a problem. Don't pad.

If the user asked for "tighter" or "kortere", aim 60–70% of source length. If "expanded" / "lengre", only when the English was so dense the Norwegian reader needs unpacking.

7. Output

• Markdown / text file source: write to <source>.no.<ext> next to the source by default. If the user said "in-place" / "overskriv", overwrite the source after confirming.
• Inline text: print the translation directly.
• HTML source: preserve all tags and attributes. Translate text content only. If <title>, <meta description>, <og:*> tags exist, translate those too.
• Slides / structured docs: preserve structure; translate slot-by-slot.

After producing the translation, briefly note (1–3 lines) any choices that might surprise the user — e.g. "translated 'pipeline' as 'salgstrakt' — say if you'd prefer keeping 'pipeline'", or "kept 'embeddings' in English; let me know if you want a Norwegian alternative."

Voice matching (optional)

If the user provides a writing sample (their own previous Norwegian writing), read it before translating:

1. Note: sentence-length pattern, formality level, recurring phrases, dialect markers, any idiosyncratic punctuation habits.
2. Match those patterns in the rewrite — don't just remove anglicisms, replace them with patterns from the sample.
3. If the sample uses radical bokmål forms (fram, boka, kasta), use those. If it uses conservative (frem, boken, kastet), match that. Don't mix.

How the user provides a sample:

• Inline: "Translate this. Sample of my Norwegian writing for voice: [paste]"
• File: "Translate this. Match my voice from <file>."

Hard rules

• Minimize em-dashes — prefer commas, periods, or parentheses; one per paragraph max. Chains read as translated.
• Never invent product features. If the English is vague ("we're working on X"), don't tighten that to a stronger claim.
• When the English is bad, fix it. A fluent translator improves clarity; literal transcription is the wrong job.
• Flag untranslatables. Some idioms or US-specific cultural references don't have clean Norwegian equivalents — call them out and propose 2 alternatives rather than guessing.
• Don't translate code, paths, code-fenced commands, URLs, or product names. Translate the prose around them.
• Don't switch between bokmål and nynorsk mid-document. Pick one and hold it (LLM mid-document drift is a known failure mode — see the humanizer skill's nynorsk-leakage section).

Final pass

After producing the translation, do an explicit Norwegian-naturalness check. Re-read mentally and ask:

"Would a Norwegian writer have started this sentence this way? Or does this still feel translated?"

If sentences feel translated, rewrite them. The final version should not betray its English origin.

For deeper anti-AI tells in Norwegian (rhythm too even, word choices abstractly correct but slightly stiff, missing dialectal flavor), see the humanizer skill — running the translated output through humanizer afterwards is a reasonable default for high-stakes content.