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

Jump to the next segment needing attention

Abierto
  • ¿Algo no está bien?
#255 1 comentario 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
48/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript
Área
frontend

Línea de trabajo

Empieza por ViewOptionsDropdown, InterlinearNav.navigate en src/components/InterlinearNavContext.tsx, los puntos de conexión de las solicitudes de foco y deriveTokenSuggestion en src/utils/suggestion-engine.ts. Reutiliza los datos del libro cargado de useInterlinearizerBookData y alinea los predicados con #117. Se considera terminado cuando los modos de navegación elegidos cumplen los comportamientos indicados de avance, retroceso, límites, foco y coherencia de predicados, y existe una entrada de menú que se pueda descubrir.

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

Descripción

enhancement

There is no way to find where the work is. Navigation today is by reference (BookChapterControl in src/components/controls/ScriptureNavControls.tsx) or by scrolling, so a half-glossed book is walked by eye. Every other affordance we have — the catalog (#186), per-book counts (#117) — tells you what is unfinished; none of them takes you there.

Two targets, not one

"Unapproved" covers two populations that want different affordances:

  1. A pending suggestion — a token with no approved link whose form hits the pool (deriveTokenSuggestion, src/utils/suggestion-engine.ts:129-158). A review queue: everything here is one keystroke from done, and this is the natural companion to bulk approval.
  2. An unanalyzed word — a word token with no approved link and no pool match. A work queue: nothing here can be accepted, it has to be typed.

A single "next unapproved" conflates them and lands the user on whichever comes first, which is the wrong tool half the time — hunting for typing work while being stopped every third verse by an accept-able suggestion, or the reverse. Recommend two directions of one command family (or one command with a mode in ViewOptionsDropdown), and pick the default deliberately.

Third candidate population, to decide on: a token whose approved analysis has gone stale because the baseline text moved under it (#139, #136, #156). Those verses need attention more urgently than either of the above, and nothing surfaces them today. If staleness detection lands first, this command should be the thing that navigates to it.

Seams to reuse

  • InterlinearNav.navigate(ref, origin) (src/components/InterlinearNavContext.tsx:120) — moves the reference, classified internal so the segment window skips its recenter fade for a target already on screen.
  • requestFocusToken(tokenRef) / consumeFocusRequest(bookCode) (:172, :189) — the focus seam #193 already uses for jump-to-usage. Reuse it; do not add a second way to focus a token.
  • The scan itself is a pure pass over the loaded book's segments against the same resolved-analysis state the renderer reads. Both halves exist; nothing new is needed in the store.

Share the predicate with #117. "Segment contains a pending suggestion" and "segment contains an unanalyzed word" are the same predicates #117's per-book approved/suggested counts need, aggregated instead of searched. Write them once, in one place, or the count and the jump will disagree.

Design questions to settle

  • The book boundary. Only the current book is loaded — useInterlinearizerBookData fetches one BookUSJ (src/hooks/useInterlinearizerBookData.ts:55-58). Crossing into the next book is a fetch, a re-tokenize, and the cross-book fade curtain (FadePhase, RECENTER_FADE_MS), which is heavy for a key the user may hold down. Recommend stopping at the end of the book for v1 with an explicit "nothing further in this book", and treating "next book with work" as a separate, deliberate action (naturally #117's view, which already knows which books have unfinished work without loading them).
  • Scroll-group coupling. navigate writes through the host scroll-group ref, so every hop drags the Paratext editor and any other linked window along, and rapid hopping spams the group. Decide whether these hops write through at all — the view already exposes a ScrollGroupSelector, so "linked" is the user's stated intent, but a review sweep is arguably a local movement.
  • Direction and wrap. Forward and backward both, and decide wrap-around vs. stop-at-end. Wrapping silently makes "am I done?" unanswerable; stopping makes it the answer.
  • What counts as a segment. The unit is the segment, not the verse (custom boundaries, SegmentationDelta), and verse-0 superscription segments are real segments here (#223, #125). Punctuation tokens (TokenType) never count.
  • Discoverability. The value is in the keyboard. Needs a menu entry in contributions/menus.json with localized strings even if the keystroke is the real interface — same discoverability problem as #155.

Behaviors to test

  1. From a segment with pending suggestions, the command lands on the next qualifying segment, not the current one.
  2. Segments with only approved tokens are skipped.
  3. The suggestion-mode and unanalyzed-mode commands land on different segments when both populations exist between the cursor and the end of the chapter.
  4. At the last qualifying segment in the book, the command reports that and does not navigate (per the boundary decision).
  5. The landing focuses a token in the target segment via the existing focus-request seam, and the request is dropped if navigation leaves that book.
  6. A backward jump from the first qualifying segment behaves as the wrap decision specifies.
  7. The predicate driving the jump agrees with the count #117 reports for the same book.

Related

#117 (shares the predicate), #193 (shares the focus seam), #139 (would add a third target population). Pairs with #254 — a review sweep is "jump to the next verse with suggestions, approve them all, repeat".

Lenguaje dominante
TypeScript
Estrellas
2
Forks
0
Merge medio
2 d 3 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.