Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Feature request: right-to-left (RTL) support for Arabic documents

Abierto
  • ¿Algo no está bien?
#2,295 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
react, tailwindcss, typescript
Área
accessibility, frontend, internationalization

Línea de trabajo

Start in packages/ui/components/BlockRenderer.tsx, which the request names as the place to set a per-block dir; the same treatment is needed in BlockquoteBlock.tsx and TableBlock.tsx. Read the block prop shape there to see where block.content is available, then implement the RTL-vs-Latin counting rule from the issue and swap physical classes for logical ones (marginInlineStart, border-s-2 ps-4, text-start). Done means Arabic lists, blockquotes and tables flip in plan review while English output is byte-for-byte unchanged; there is no test named in the payload, so verify in the annotate and plan-review views.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

What happens

Plans and documents written in Arabic (and other RTL languages) render left-to-right in annotate and plan review (plannotator 0.28.35, Windows, Claude Code):

  • Arabic paragraphs and headings are left-aligned, and their punctuation jumps to the wrong end of the line.
  • Bullets and numbers sit on the left of Arabic list items, and nested items indent from the left.
  • The blockquote rule is on the left side.
  • Table columns run left-to-right, and headers are forced left (text-left).
  • The table of contents in the left sidebar has the same problems.
  • Inline code inside an Arabic sentence (for example Use `POST /ingest` here written in Arabic) splits the surrounding punctuation.

Agent output in Arabic is common now. The plans we review are mostly Arabic with English identifiers and code mixed in, so this affects every review.

Why dir="auto" is not enough

dir="auto" picks the direction from the first strong character. In mixed documents many Arabic lines start with an English identifier or code, for example a list item that begins with `POST /ingest` and continues in Arabic. Those lines would wrongly come out LTR. Short English-only headings inside an Arabic document (for example "Jev" or "WebSocket") also read better when they follow the document's direction.

Proposed change

  1. A direction per block. For each block, take block.content, drop the inline code spans, and compare the count of RTL letters with Latin letters:

    • The block is rtl when RTL letters are at least half the Latin count.
    • The block is ltr when it has only Latin text and at least about 30 letters.
    • Otherwise it follows the document's majority direction.

    Set the result as a dir attribute on the block root in packages/ui/components/BlockRenderer.tsx (headings, paragraphs, list items), BlockquoteBlock.tsx and TableBlock.tsx. Then lists, tables and alignment follow from the browser's own bidi handling.

  2. Logical properties instead of physical ones (Tailwind 4 supports them):

    • list indent style={{ marginLeft }} becomes marginInlineStart;
    • blockquote border-l-2 pl-4 becomes border-s-2 ps-4;
    • table headers text-left become text-start.

  3. Code stays LTR. Code blocks get dir="ltr", and inline code gets unicode-bidi: isolate so punctuation around it stays in place.

  4. Comments. The comment textarea gets dir="auto", and the TOC entries use the same direction as their heading.

No text changes, so annotation offsets and quotes are unaffected. It also adds no setting: English documents keep rendering exactly as they do today.

Optional: a textDirection: "auto" | "ltr" | "rtl" setting for people who want to force one.

Workaround in the meantime

I'm using a small userscript that applies the same idea from outside: it sets dir per [data-block-id] and adds a few CSS overrides. It works, but it relies on internal class names and inline styles, so it breaks whenever the markup changes. A built-in fix would be much more robust.

I'm happy to open a PR along these lines if this direction works for you.

Lenguaje dominante
TypeScript
Estrellas
8.7k
Forks
649
Merge medio
11 h 48 min
PR fusionados (30 d)
552

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de backnotprop/plannotator

Todos los issues de backnotprop/plannotator

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.