Skip to content

Fix LT-22834: keep multi-string alternatives in writing systems not yet known to the cache - #406

Open
johnml1135 wants to merge 2 commits into
sillsdev:masterfrom
johnml1135:fix/LT-22834-auni-unknown-ws
Open

johnml1135 wants to merge 2 commits into
sillsdev:masterfrom
johnml1135:fix/LT-22834-auni-unknown-ws

Conversation

@johnml1135

@johnml1135 johnml1135 commented Oct 12, 2026 •

Copy link
Copy Markdown
Contributor

Fixes LT-22834. A multilingual (AUni) alternative in a writing system the cache has not seen yet is no longer dropped on load. Whether it survived used to depend on which objects happened to be activated first.

Cause. MultiUnicodeAccessor.ReadMultiUnicodeAlternative resolved the alternative's ws with GetWsFromStr, which returns 0 for an unknown writing system, so the alternative was discarded. AStr runs resolve through TsStringSerializer.GetWsForId → get_Engine, which creates the writing system on demand. So an AUni value survived only if some run in that writing system had already been read. In the Sena sample, lazy activation kept 4,515 of 4,599 ChkTerm.Name Hebrew values, while activation in file order kept all of them. In Indonesian, fr/es values that occur only in AUni fields were always dropped.

Fix. Resolve AUni writing systems with get_Engine, as runs do. One deliberate difference: an identifier that cannot become a writing system is still dropped rather than throwing, which keeps this path's existing "don't block opening the project" behaviour. The writing system is created in the cache's writing-system manager only; nothing is added to the project's vernacular or analysis lists. No schema, model version, persisted field or file format changes.

Tests.

  • New ReadMultiUnicodeAlternative_UnknownWritingSystem_IsKept, committed alone first. It fails before the fix ("alternative in an unknown writing system was dropped") and passes after.
  • net8.0, Release: SIL.LCModel.Tests 1,717 passed / 0 failed / 18 skipped, and SIL.LCModel.Core.Tests 775 / 0 / 14. net462 was not run.

Worth a FieldWorks reviewer's eye: loading a project can now create writing systems in the cache's writing-system manager for identifiers found only in AUni data, as loading AStr runs already does. If FLEx should treat such writing systems differently, for example by warning, that belongs in a follow-up.

Related: #405 (a cross-cache HVO collision found in the same investigation).

🤖 Generated with Claude Code


This change is Reviewable

johnml1135 and others added 2 commits October 12, 2026 14:56
… kept

Loading an AUni alternative whose writing system the cache has not seen yet
currently drops the alternative, because the lookup returns 0 for unknown
writing systems. AStr runs create the writing system on demand, so the result
depends on activation order. This test fails until AUni does the same.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…et known to the cache

MultiUnicodeAccessor looked AUni alternatives up with GetWsFromStr, which
returns 0 for a writing system the cache has not seen, so the alternative was
silently dropped. AStr runs create the writing system on demand, so the
outcome depended on activation order. AUni alternatives now resolve the
writing system the same way runs do. No schema or file-format change.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant