Arabic and English in one note, with zero toggles.

If you have ever taken meeting notes in Arabic and English at the same time, you know the ritual: type a line of Arabic, watch the punctuation jump to the wrong end, hunt for the paragraph-direction button, fix it, type an English line underneath, and fix it again the other way. Bilingual writers do this so often they stop noticing the tax. But it is a tax, it is paid on every mixed-language note, and it exists because most editors made one quiet architectural decision decades ago: direction is a property of the document, not of the text. This post is about why that breaks bilingual notes, and the approach NoteX takes instead.

Why bilingual notes break most editors

Text direction in most software is set at exactly the wrong granularity. Some apps make it per-application: the whole interface and every document runs one way, so the minority language always lives in a hostile layout. Others make it per-document: a toggle flips the entire page, which works until your document is genuinely mixed, which for a bilingual team is every document. Almost none make it a property of the text itself, which is the only place it belongs.

The symptoms are familiar to every Arabic-English writer:

• Punctuation jumps. End an Arabic sentence in an LTR paragraph and the period, question mark, or trailing parenthesis leaps to the far side of the line. The Unicode bidi algorithm resolves neutral characters by their surroundings, and a wrongly-set paragraph direction gives it the wrong surroundings.
• Lists misalign. Arabic list items in an LTR list hang their bullets on the wrong side, indent the wrong way, and read like an accident. Nested lists compound the mess with every level.
• The cursor lies. At the seam between Arabic and English, pressing the right arrow can move the caret left, and selections stretch in ways that make visual sense to nobody.
• Numbers and names shatter. A product name, a code identifier, or "Q3 2026" inside an Arabic sentence gets visually scrambled when the base direction is wrong, because there is no correct rendering of LTR fragments in a paragraph that thinks it is LTR-first when it is not.

Per-block, first-strong-character direction

NoteX resolves direction at the level where it is actually true: the block. Every paragraph, heading, quote, list item, to-do, table cell, callout, and toggle decides its own direction, independently, using the Unicode bidi algorithm's first-strong-character rule (the P2 and P3 rules, for the standards-inclined): scan the block's text for the first strongly-directional character; if it is Arabic, the block lays out RTL, and if it is Latin, LTR.

The detail that makes this livable is what does not happen. A single Arabic word quoted inside an English paragraph does not flip the paragraph, because the first strong character is still Latin. An English product name inside an Arabic heading does not flip the heading. The document as a whole stays direction-neutral; there is no master switch to set wrong. And the decision re-evaluates as you type, so the moment a block becomes an Arabic block, it behaves like one, with no toolbar visit.

Two deliberate exceptions: code blocks and dividers always render LTR, whatever they contain, because code is an LTR notation even when its comments are Arabic. Direction detection also runs per cell inside tables, which is what lets a glossary table hold an Arabic column and an English column without either fighting the other.

What "done right" means for a bilingual wiki

Automatic direction is the foundation, not the finish line. For a team wiki that genuinely lives in two languages, the bar looks like this:

Mixing is the normal case, not the exception. A bilingual team's most important pages are the mixed ones: the policy with an Arabic summary, the runbook with English commands and Arabic context. If mixed documents are second-class, the wiki quietly splits into two wikis, and one of them rots.

Structure survives translation. Headings, checkboxes, tables, callouts, and every other block type should work identically in both directions. An RTL to-do is still a to-do; a checkbox that renders on the wrong side of Arabic text tells your Arabic writers the feature was tested in one language.

Search does not care about script. Cross-note search has to find Arabic titles as readily as English ones, and a note named in Arabic deserves its icon and its place in the sidebar tree like any other, which in NoteX it gets.

The file keeps the languages together. Because notes are files with content stored as structured text, a bilingual note exports, syncs, and diffs as one artifact. Your Arabic content is not trapped in a rendering layer; it is text you own, in a format that any tool, or any AI agent, can read. That matters more every year, for reasons we covered in Your notes are AI context now.

These pieces together are what make a team knowledge base viable for organizations that think in two languages, instead of forcing them to pick one for the wiki and lose everyone who thinks in the other.

Arabic first was never optional for us

For NoteX this was not an internationalization ticket that could slip to next quarter. Lisan is an Arabic-first company; more than 24 government entities work with Lisan, and the documents that world runs on are bilingual as a matter of daily reality: Arabic and English in the same memo, the same minutes, the same policy. We built the editor for the writers we know best, the ones who switch languages mid-thought and should never have to switch tools, or toggles, to do it.

Most editors treat right-to-left as an accommodation. We think the mixed-direction document is simply what writing looks like for a few hundred million people, and an editor that handles it without being asked is not doing anything heroic. It is doing its job.