sillsdev / sillsdev/interlinearizer-extension
Only the first analysis language's glosses are ever visible
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 2
- Forks
- 0
- Avg merge
- 1d 17h
- Merged PRs (30d)
- 55
Description
A project with several analysis languages renders glosses in analysisLanguages[0] only. Every
other language's glosses are stored but unreachable, and there is no UI to switch the displayed
language.
The store's language is a mount-time seed, taken from the first tag in the list:
src/components/InterlinearizerLoader.tsx:299— draft view:draft?.analysisLanguages[0] ?? platformLanguagesrc/components/InterlinearizerLoader.tsx:1135— PT9 import view:activeProject.analysisLanguages[0] ?? platformLanguage
Those are the only two writers of analysisLanguage in the app. Everything downstream reads that
one tag — selectPhraseGloss / selectSegmentFreeTranslation (src/store/analysisSlice.ts:1184,
:1199), the gloss writes, and the analysis catalog rows — so a gloss map holding {en, fr, tpi}
renders en and nothing else.
Why now
Latent since the New dialog started accepting a comma-separated list, but until the Paratext 9
import there was always a user who typed the order and knew what they'd get. The import derives the
list from the source files — first appearance of glossLanguage in data.books, deduped first-wins
(src/converters/pt9/convertPt9Project.ts:82-104, :158-161) — so [0] is whatever the
platformScripture.Pt9Interlinear provider enumerated first. It also tells the user the hidden data
exists: the import report lists every language it converted
(src/components/modals/Pt9ImportModal.tsx:199-206), so the view visibly contradicts the report.
Copying out doesn't help either — createEditableCopy carries analysisLanguages verbatim
(src/services/projectStorage.ts:550).
Observed on a real multi-language PT9 project (PIA); it will affect any source with more than one
gloss language.
Scope
Two decisions, worth settling before implementation:
- Where the language selector lives — the view-options dropdown, the toolbar, or per-project
state that persists. Add auser-questions.mdentry for this. - Whether the import view gets the same control as the draft view. The import is read-only, but
switching the displayed language is a read, not an edit, so it should.
Implementation note: analysisLanguage is a non-reactive seed on AnalysisStoreProvider. Changing
it needs the tag folded into the provider key (src/components/InterlinearizerLoader.tsx:1133,
:1153) so the store remounts, or a reactive path into analysisSlice. Note that remounting drops
in-flight gloss edits and the catalog's scroll position, so the reactive path is probably the right
one.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the two analysisLanguage seeds in src/components/InterlinearizerLoader.tsx and the selectors and writes in src/store/analysisSlice.ts. Review the import language derivation in src/converters/pt9/convertPt9Project.ts and resolve the selector location and import-view behavior in user-questions.md. Done means every analysis language can be selected and its stored glosses are displayed in both relevant views without losing edits.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- frontend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100