Skip to main content
ExplanationUpdated · 5 min read

Why monolingual is first-class in Skrebe

Skrebe treats Kriolu-only documents as the default, not a stripped-down bilingual editor. Here's the reasoning behind that choice.

Open the editor on a brand-new document and you'll see a single pane — not the split English-on-the-left, Kriolu-on-the-right layout you might expect from a translation tool. That's deliberate. Monolingual is the default in Skrebe; bilingual is the special case. This page explains why, because the decision shapes a lot of what the editor does and doesn't do.

The short version

Most curators we built Skrebe for don't start from an English source. They write Kriolu from a brief, paste in something a colleague drafted, or open a .md file someone already translated. Forcing those documents into a two-column view either leaves half the screen empty or invites a busywork step ("paste in the English we don't actually have"). So the editor's normal shape is a single, centered Kriolu surface, and the AI features behave as proofreaders of finished prose rather than as machine translators waiting for a source.

If you do have an English source, you can promote a document to bilingual mode from the document header chip, and the second pane appears with the translate-from-source affordances on it. Bilingual mode keeps everything Skrebe always did — it just stopped being the assumption.

What "first-class" actually changes

When monolingual is the default rather than a degraded bilingual, a few things follow that you'll feel as you use the editor.

The chrome stays out of the way. No left pane to ignore, no diff bar between two columns, no language toggles to find. The center of the screen is your Kriolu. The toolbar above it is mode-aware: in monolingual you'll see Proofread ▾, Register ▾, Check, and Export; in bilingual the AI Draft button reappears next to those.

Proofread is the only AI surface, not just the primary one. In a bilingual editor, AI Draft translates the English source into Kriolu — a separate action from Proofread, useful for a first pass. In a monolingual editor, there's no source to translate from, so that action isn't disabled or secondary — it's simply not there. Proofread ▾ and its per-paragraph sibling (the ✦ gutter button) are the only AI actions available.

The dictionary and glossary you built matter more here. A bilingual translation cycle uses your dictionary as vocabulary preferences when generating Kriolu from English. A monolingual proofread uses it differently: the model reads your Kriolu, your normative glossary policies (the must/should/avoid/prefer rules under /glossary), and the dictionary entries you've opted into translation context, then proposes revisions that respect both. The context flows the same way in both modes, but in monolingual it's doing review work, not generation work.

Why proofread is on-demand, not continuous

You'll notice Skrebe never proofreads automatically as you type. There's no underline-as-you-go, no debounced background pass, no auto-suggestion when you stop. You trigger every run yourself, either per-paragraph (✦) or whole-document (Proofread ▾). That choice is intentional for three reasons.

Cost predictability. Each model call costs something — your BYOK quota if you brought a key, Skrebe's free pool if you didn't. An always-on proofreader on a 2000-word document could fire dozens of times a minute. On-demand means one call per user gesture, and you decide when to spend.

Trust. Live proofreading invites distraction: the model interrupts your flow with a re-write before you've finished the thought. Skrebe's bet is that curators write better in one pass and review in a second pass, not in a tug-of-war with autocomplete.

Honest staleness. If the proofreader ran continuously, it would have to silently throw away suggestions you'd already half-acted on. By making each run explicit, Skrebe can be honest about what changed underneath a proposal: edit a paragraph after running proofread, and the card for that paragraph flips to 🔒 Outdated with a ↻ Re-run button. No silently-applied stale edits, no quietly-dropped ones. The same logic underpins the Accept all flow: it skips outdated cards instead of guessing.

Why two proposal surfaces, not one

When you trigger from a single paragraph (the ✦ gutter button), you get an inline diff in the editor itself: removed text struck through in red, additions in green, with a small popover for the model's rationale and a mini ✓/✕ toolbar at each change. When you trigger on the whole document (the toolbar button), the right rail opens with a queue of cards instead — one per affected paragraph, navigable with j/k, accept with y, dismiss with n.

There's no single "right" surface for both situations, so Skrebe doesn't pretend there is. Inline is where you want the diff when you're polishing one sentence — the change stays in your visual flow. The queue is where you want it when there are twelve changes across a long document and reading twelve inline overlays at once would be chaos. The shortcuts work the same way in both surfaces.

What's deliberately not here

A few things you might expect from an AI editor but won't find:

  • No silent rewrites. Every model output goes through a diff card; the editor's buffer only changes when you accept.
  • No free-text "tell the AI what to do" box. The structured knobs (Proofread, Register, Skip style) are the only inputs in v1; freeform prompts are a future consideration.
  • No streaming. Each run is one round-trip with a clean proposal set; you don't watch tokens appear.
  • No mode autodetection on the fly. Once you've started in one mode, the chip in the document header is how you switch. Bilingual → monolingual drops the English pane and asks for confirmation (because bundle.source goes with it); monolingual → bilingual just adds the pane.

These omissions aren't oversights — they're the shape of a tool built for curators who want help, not partnership. Monolingual being first-class is the part of that shape you'll see first.

Where to go from here