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

Implement RTL support

Abierto
  • ¿Algo no está bien?
#97 2 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
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
30/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
typescript
Área
frontend, internationalization

Línea de trabajo

Comienza revisando la lectura existente de document.documentElement.dir, el orden de los strips de SegmentView, los chips de tokens, las entradas de gloss y el renderizado de baseline-text. Primero determina si la dirección es global o por lado/por token; después, sigue el comportamiento RTL y bidi afectado en esas áreas. Se considera terminado cuando los layouts RTL, el contenido con direcciones mixtas, el posicionamiento CSS, la geometría de los arcos y las pruebas de cobertura funcionan con datos hebreos o árabes.

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

Descripción

Here is Claude's analysis of what needs to be done:

RTL Support — Scope Assessment

A scoping write-up for adding right-to-left (RTL) language support to the interlinearizer
extension. This is exploratory — it estimates the work, it doesn't commit to a timeline.

TL;DR: Medium-sized effort, not a rewrite. The architecture is mostly RTL-favorable already
(coordinate-based arc geometry, scrollIntoView-based scrolling, some logical CSS in place). The
single biggest decision — and the thing most likely to expand scope — is whether text direction is
one global flag or threaded per writing-system (source can be RTL while glosses are LTR).
Settle that first; everything else follows.

Current state

  • The app tracks a writingSystem (BCP 47 tag) on every token, plumbed through from the project
    setting into the tokenizer and onto each Token.
  • It reads document.documentElement.dir === 'rtl' in exactly one place (to flip the
    prev/next navigation arrows)…
  • …but it never writes dir anywhere. So in practice RTL text is currently laid out as LTR.

The team has clearly started thinking about RTL (logical CSS properties in the fade overlays, the
arrow flip, arc geometry that measures real pixel positions), but the foundation — actually
establishing direction — isn't wired up yet.

Work, by area

1. Establish direction — small code / design-heavy — DO FIRST

The keystone everything depends on. Today documentElement.dir is read but never set.

  • Add an isRtlLanguageTag(tag) util that derives direction from the BCP 47 writingSystem
    (script-subtag lookup, or Intl.Locale().textInfo.direction where available).
  • Apply dir to the DOM. Complication: source and target can have different directions
    (RTL Hebrew source, LTR English gloss). A single documentElement.dir is too coarse — this
    likely wants dir set per-strip / per-token based on each side's writing system, not one
    global flag.
  • This design decision (global vs. per-side) is the real work and ripples into every area
    below.
2. Token strip ordering — medium — highest visual risk

Both views render the token strip as a plain flex row in document order. Flexbox will reverse
visually under an RTL ancestor — but only once dir="rtl" is actually set (see #1). After that:

  • Verify SegmentView's multi-row wrapping lays out right-to-left, top-to-bottom correctly.
  • Audit the doc-order ↔ visual-order assumptions in the code/comments. The sorting logic is fine
    (it sorts by document index, correct either way), but several comments literally say "visual
    left-to-right order" and need to be re-checked so nothing actually depends on doc-order ==
    left-to-right.
3. Arc geometry — small — mostly works already, needs verification

The arc path computation measures real getBoundingClientRect() values and normalizes spans with
Math.min/max, so arcs connect boxes wherever they land — this should survive RTL "for free."
Verify rather than rewrite:

  • The gutter-side ("nearer left") choice is geometric, so fine — confirm the reserved left/right
    gutter padding lands on the correct visual side once boxes flip.
  • Split-button positioning and de-confliction are pixel-based; should be fine but untested under RTL.
4. Physical → logical CSS — small, mechanical

A handful of physical left/right styles remain and should become logical (start/end):

  • Token chip remove-badge -right-1.5 → -end-1.5.
  • Baseline-text segment text-left → text-start.
  • The view-options dropdown anchors with physical right + window.innerWidth - rect.right —
    needs RTL-aware positioning.
  • A few modals use text-left / mr-1.
  • Centered elements using left-1/2 -translate-x-1/2 are direction-neutral — no change needed.
5. Bidi correctness in mixed content — medium — easy to under-scope

The subtle one QA will catch late if ignored:

  • Token chips carry no dir/lang despite each token having a writingSystem. RTL baseline with
    LTR glosses (or numerals/punctuation) will mis-order without per-element hints. Setting dir +
    lang per token from writingSystem is the clean fix.
  • Gloss input fields need their own direction matching the analysis language, independent of the
    baseline.
  • The verse-label + baseline concatenation in baseline-text mode needs bidi isolation so a numeric
    label doesn't reorder against RTL text.

Rough sizing

Area Size Risk
1. Establish direction (incl. global-vs-per-side decision) S code / design-heavy Foundational
2. Strip ordering M High visual risk
3. Arc geometry S (verify + test) Low
4. Physical → logical CSS S Low
5. Bidi / mixed-content correctness M Easy to under-scope

Overall: on the order of a week-ish of focused work plus QA with real Hebrew/Arabic data,
assuming the per-side direction question in #1 is settled early. Note the test suite enforces 100%
coverage, so every component touched needs RTL test cases added.

Recommended first step

Decide #1: global vs. per-side direction. That single call determines whether dir is one flag
or threaded per writing-system through tokens, glosses, and strips — and therefore the true size of
everything else.

Lenguaje dominante
TypeScript
Estrellas
2
Forks
0
Merge medio
2 d 5 h
PR fusionados (30 d)
46

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 sillsdev/interlinearizer-extension

Todos los issues de sillsdev/interlinearizer-extension

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.