Sort entry list by vernacular writing systems - #2618
Conversation
Add sort options for each vernacular writing system (excluding audio) to the FwLite viewer's entry list, alongside the existing default-headword sort. The chosen writing system now flows through to the query order (the backend already supported it) instead of always sorting by 'default'. When sorting by a specific writing system, the headword shown in the entry list (simple mode) switches to that writing system, preferring it but falling back to another vernacular value so rows aren't left blank. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Warning Review limit reachedNext included review available in 12 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (18)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
Bot
added
the
💻 FW Lite
|
The latest updates on your projects. Learn more about Argos notifications ↗︎
|
Revert the sort dropdown to its original headword/relevance options, and add a separate badge/pill dropdown for choosing the writing system to sort and display by. It lists the vernacular writing systems (excluding audio) and defaults to the first (the default vernacular) — matching today's behavior. The pill is hidden when a project has only one such writing system, so nothing to choose means no extra control. The chosen writing system is merged into the sort passed to the entry list, so both the query order and the displayed headword follow it, as before. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
@myieye It looks like FLEx sometimes shows the region in a dropdown for picking a writing system as it helps disambiguate. Originally in the dropdown I just showed the name, with wsId muted. However this meant that we never displayed the abbreviation, which is what people are used to seeing, so I changed around how it works. I could even see making the abbreviation the primary and the full name the muted value. |
Show the abbreviation (falling back to the wsId) as the muted text in the sort writing-system dropdown instead of the wsId. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Drop the now-unnecessary SortConfig cast (the interface accepts the object literal directly) and use function declarations for the test locator helpers to satisfy func-style. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
I think it looks good. 👍🏻 I'm wondering: should we filter the writing systems in the list based on the current view? I thought of it, because a team recently asked (via Sara) why the dictionary preview shows WS's that are excluded from the editor (via a custom view). It seems reasonable to me that everything should be aligned based on the view. |
|
Yeah that's probably a good idea. Should we apply that here you think? or just do it all at once in another PR? |
|
@hahn-kev Yeah, another PR is fine. I'm still curious about potentially using a single split badge. Up to you |
One vernacular + one analysis (the common project) — no headings at all:
|
|
@myieye what's up? |
3 participants
We've had backend support for a long time, we just never brought it to the frontend.
Per our team meeting we decided that WS should be a separate selection since it's also can effect the best match sort order. It still effects how rows are displayed.
WS Select (vernacular only):
The selected value shows the abbreviation, falling back to the name. In the dropdown it just shows the full name, with the abbreviation as the muted text (falling back to the wsId)
Fallback when the selected WS has no value:
🤖 AI summary
Brings the backend's existing per-writing-system sort to the FwLite viewer's entry list. Sorting/displaying by a writing system was always supported server-side (
ISortOptions.writingSystem→entry.Headword(order.WritingSystem)); the viewer hardcoded'default'. Frontend-only change.Per team feedback, writing-system selection lives in its own pill, separate from the sort field/direction:
SortMenuis unchanged from before this PR — Auto / Best match / Headword ↑ / Headword ↓.SortWritingSystemMenu(new) is a badge/pill dropdown listing the vernacular writing systems (excluding audio), defaulting to the first (the default vernacular) — i.e. today's behavior. It's hidden when a project has only one such writing system.BrowseViewmerges the pill's writing system into theSortConfigit passes to the list, so both the query order and the displayed headword follow it.EntryRowshows the headword for the selected writing system viaWritingSystemService.sortedHeadword(entry, ws), which prefers that writing system but falls back to another vernacular value so rows aren't left blank. The strictheadword(entry, ws)(search filtering, duplicate detection) is unchanged.entry-loader-servicepasses the selected writing system to the query order instead of always'default'.Considered and rejected
Test plan
frontend/viewerUI tests (tests/ui/sort.test.ts): the sort menu no longer lists writing systems; the pill lists the vernacular writing systems and excludes audio; selecting one switches the displayed headword to that writing system's form. Full viewer UI suite green (62 passed).pnpm run check(svelte-check) — 0 errors.pnpm run i18n:extract— new "Sort writing system" string extracted across locales.