Support content-aware bidirectional text in Markdown and Seer output

[CodeinScrubs]

Problem Statement

Sentry renders user-, event-, and AI-generated text that can mix left-to-right and right-to-left scripts in the same block. The Unicode Bidirectional Algorithm handles character order, but a block can still receive the wrong base direction when its first strong character does not represent the dominant language.

For example, this Persian-majority sentence starts with an English product name:

React یک کتابخانه جاوااسکریپت بسیار محبوب است.

Treating it as LTR because React is the first strong token can put punctuation and inline runs in surprising positions. The inverse problem occurs in English-majority text containing Persian, Arabic, Hebrew, or Urdu words. These cases are especially relevant to issue descriptions, logs, stack-trace annotations, and Seer-generated Markdown.

Sentry already has a useful centralized integration point in static/app/components/core/markdown/markdown.tsx, with Seer composing it through static/app/components/seer/markdown/index.tsx.

Solution Brainstorm

I would be happy to prepare a narrowly scoped PR after maintainer guidance. A safe initial implementation could:

• determine base direction independently for each rendered block using strong-character content majority rather than only the first strong character;
• apply semantic dir=ltr or dir=rtl plus unicode-bidi: plaintext at block boundaries;
• keep text alignment independent, so existing Sentry layout/alignment remains unchanged unless explicitly configured;
• exclude code blocks, inline code, URLs, paths, identifiers, and other technical spans from direction scoring;
• re-evaluate only the active block during streaming Seer output;
• leave pure-LTR content unchanged and avoid global DOM mutation or rewriting stored/source text;
• add regression tests for paragraphs, headings, lists, table cells, punctuation, streaming updates, and mixed Persian/Arabic/Hebrew/Urdu examples.

The implementation can either use a small local helper or the MIT-licensed BidiLens packages, depending on Sentry's dependency policy:

• Repository and technical overview: https://github.com/CodeinScrubs/BidiLens
• Interactive examples: https://codeinscrubs.github.io/BidiLens/
• Architecture: https://github.com/CodeinScrubs/BidiLens/blob/main/docs/ARCHITECTURE.md
• Security model: https://github.com/CodeinScrubs/BidiLens/blob/main/docs/SECURITY.md
• Known limitations: https://github.com/CodeinScrubs/BidiLens/blob/main/docs/LIMITATIONS.md

Current verification includes 396 automated tests, a 918-case multilingual corpus, three-browser visual checks, packed-package consumer tests, and native platform adapters. Known limitation: the corpus is not yet independently/native-speaker reviewed, so I would treat Sentry-specific fixtures and maintainer review as required before rollout.

Would the Sentry team be interested in a PR piloting this in the shared Markdown component, initially behind a component option or feature flag?

Product Area

Issues / Seer / Shared Markdown rendering

[linear-code]

ENG-8321

[getsantry]

Auto-routing to @getsentry/product-owners-issues for triage ⏲️