[thejambi]

Start here: Src/LexText/LexTextControls/Avalonia/EntryGoLauncherShared.cs -- Headword(entry, out ws) now reports which writing system the headword came from; everything else carries that to the cell.

In the new UI, the Go-family results list now draws each headword in the font and direction of the writing system it came from. Before, every headword used the Headword column's font, the default vernacular one's, so since #1217 a headword found only in, say, Arabic was drawn left-to-right in the wrong font.

Headless capture (Avalonia.Headless, test data): "kalb" comes from a right-to-left writing system and flows right-to-left; "casa" keeps the column's font; the Glosses cells are untouched.

What about rows nobody updated? They behave as before. EntryGoSearchResult.HeadwordTypography defaults to null, and a null row typography falls back to the column's, so other callers that build rows, such as Insert Entry's matches search, are unaffected. The question worth your time is whether the writing system reported always matches the text returned.

Where to look

• EntryGoLauncherShared.Headword: sets ws only on the branch that returns that ws's form; null on the no-form fallback, an empty headword since LT-22883. Pinned by SharedSearch_HeadwordFromAnotherWs_CarriesThatWsTypography and SharedSearch_EntryWithNoForm_LeavesTheColumnTypography.
• Sense rows reuse their entry's headword writing system: SharedEntryOrSenseSearch_HeadwordFromAnotherWs_SenseRowsCarryThatWsTypography.
• EntryGoDialogView.BuildRow: the override reaches the Headword cell only (TypographyFor). Pinned by ResultRow_HeadwordTypography_OverridesTheColumnTypography.

Not here

• Insert Entry's Matching entries list draws every headword in the UI font; it has no writing-system typography at all. Already on main, out of scope.
• The Glosses column can mix analysis writing systems in one cell; a per-row font cannot fix that.
• Not known: whether the WinForms dialog draws such a headword in its own font; inferred from its column definition, not observed.

Stack and verification: top of the stack #1217 (LT-22671) → #1218 (LT-22883) → this PR; it merges after both. build.ps1 clean with comment and token hygiene; test.ps1 FwAvaloniaDialogsTests 298/298, LexTextControlsTests 407 passed with 3 existing skips. Manual check of the ticket's steps in the new UI: author, pending.

Next: approve, or point at a row type that should carry its own headword font and doesn't.

---

Reading this a year from now -- start here

LT-22884 is a follow-up to LT-22671 (#1217) and sits on LT-22883 (#1218). LT-22671 let the Go-family dialogs search, and show headwords from, any current vernacular or analysis writing system. This PR is the display half: the results list had one font per column, which stopped being enough once a column's values could come from different writing systems. The branch had no working documents; the only markdown change is one sentence in .claude/skills/fieldworks-avalonia-ui/references/dialog-conversion.md, which stays.

Decisions, and why

• Capture the writing system where the headword is chosen. Headword returns the text and its writing system from the same loop iteration, so they cannot disagree. Recomputing the writing system later from the text would need a second walk over the same candidates and could pick a different one when two writing systems share a form.
• Null means "use the column's". Rows built elsewhere (Insert Entry's matches search, tests) need no change, and an entry with no form in any writing system, which shows an empty headword, has no meaningful font to carry.
• TypographyFor(field) rather than a Headword special case in the view. The view asks each row for its typography per field and stays field-agnostic. Only Headword returns one today; another column can opt in by extending that one method.
• HeadwordText keeps its signature. It has other callers (Insert Entry, the description text); it now delegates to Headword(entry, out _).

Evidence

• Launcher tests (LexTextControlsTests/Avalonia/EntryGoDialogLauncherTests.cs), against a real cache with an added right-to-left vernacular writing system (ar, Scheherazade New):
  • SharedSearch_HeadwordFromAnotherWs_CarriesThatWsTypography: font and right-to-left come from ar.
  • SharedSearch_DefaultVernacularHeadword_CarriesItsTypography: a default-vernacular headword carries the default vernacular font, not null.
  • SharedSearch_EntryWithNoForm_LeavesTheColumnTypography: null.
  • SharedEntryOrSenseSearch_HeadwordFromAnotherWs_SenseRowsCarryThatWsTypography: sense mode.
• View test (FwAvaloniaDialogsTests/EntryGoDialogTests.cs): ResultRow_HeadwordTypography_OverridesTheColumnTypography asserts font family and flow direction on the overridden cell, the column default on the other row, and the column font on the Glosses cell. It writes the snapshot shown above.
• The tests assert the font name and flow direction applied to each cell, not the glyphs drawn; headless rendering falls back when a named font is not installed.

Preflight review details

Base: LT-22883-go-results-placeholders (#1218), top of the stack on #1217. Files changed: 6 against the base. Review model: Claude Opus 5.5.

Contract/API changes: added EntryGoSearchResult.HeadwordTypography and EntryGoSearchResult.TypographyFor(EntryGoResultField) in FwAvaloniaDialogs; additive, defaults preserve existing behavior. EntryGoLauncherShared.HeadwordText signature unchanged.

Findings

• Critical: none.
• Important: none.
• Minor:
  • Insert Entry's Matching entries list (LcmInsertEntryDialogLauncher.cs, InsertEntryDlgView.axaml) applies no writing-system typography, so all its headwords use the UI font. (author: already on main, out of scope for LT-22884)
  • Go-family Glosses cells can mix analysis writing systems and are drawn in the default analysis font. (author: already on main, out of scope for LT-22884)

Validation: build.ps1 -CommentHygiene -TokenHygiene clean, 0 warnings; test.ps1 -SkipNative FwAvaloniaDialogsTests 298/298 and LexTextControlsTests 407 passed, 3 existing skips, 0 failed. Manual repro of the ticket's steps: author, not yet done.

Interview notes: both Minor findings dismissed as out of scope; no other trade-offs or uncertainties flagged.

Suggested review focus

• Headword: reported writing system matches the returned form, including the fallback.
• BuildRow: row typography overrides only the Headword cell.
• Manual check with a second, right-to-left vernacular writing system.

🤖 Generated with Claude Code

---

This change is 

[github-actions]

NUnit Tests

    1 files      1 suites   8m 57s ⏱️
7 001 tests 6 916 ✅ 85 💤 0 ❌
7 010 runs  6 925 ✅ 85 💤 0 ❌

Results for commit 8f1a7f0.

♻️ This comment has been updated with latest results.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 40.43%. Comparing base (7eff4b7) to head (8f1a7f0).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1222   +/-   ##
=======================================
  Coverage   40.42%   40.43%           
=======================================
  Files        1552     1552           
  Lines      355801   355829   +28     
  Branches    41523    41529    +6     
=======================================
+ Hits       143838   143869   +31     
+ Misses     182651   182650    -1     
+ Partials    29312    29310    -2     

Files with missing lines	Coverage Δ
...ommon/FwAvaloniaDialogs/EntryGoDialogView.axaml.cs	79.52% <100.00%> (ø)
...rc/Common/FwAvaloniaDialogs/EntryGoSearchResult.cs	85.36% <100.00%> (+0.36%)	⬆️
.../LexTextControls/Avalonia/EntryGoLauncherShared.cs	85.82% <100.00%> (+2.79%)	⬆️

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mark-sil]

LGTM