Ask the language chooser, not LibPalaso, whether a sign language name is custom (BL-16760)

[andrew-polk]

Problem

Choosing a sign language from the Publish tab can record the language's own name in the
collection settings as though the user had typed a custom name for it. Choosing the very same
language from Collection Settings records it correctly. SignLanguageIsCustomName is Bloom's
record of "the user deliberately gave this language this name, so never replace it with a
looked-up one", so setting it when nothing was typed is simply wrong data. The error also runs the
other way: a name the user really did type is recorded as not custom whenever it happens to
match LibPalaso's name for the tag.

Cause

PublishApi decided the question by setting the writing system's Tag — whose setter derives
Name through LibPalaso — and then comparing that derived name against the chooser's
DesiredName. That predates the new language chooser: when the code was written
LanguageChangeEventArgs had no DefaultName to compare against, and be892652b carried the
workaround across verbatim. LibPalaso and the chooser do not always agree; for mzc LibPalaso
says "Madagascar Sign Language" and the chooser says "Malagasy Sign Language".

Fix

• PublishApi's sign-language handler now asks args.IsCustomName, which compares only the two
  names the chooser itself sent — the same rule all four Collection Settings sites already use.
• The <remarks> on LanguageChangeEventArgs.IsCustomName no longer describe the divergence as
  intentional; it now says this is the only rule a caller should use, and why.
• LanguageChangeEventArgsTests loses the test that deliberately pinned the divergence and gains
  two that pin the agreed answer in both directions, using the real mzc names.

Verified in a running Bloom: picking Malagasy Sign Language from the Publish tab now writes
SignLanguageIsCustomName=false, and typing "Madagascar Sign Language" over it writes true
(that case used to come out false).

(Depends on LanguageChangeEventArgs.IsCustomName from #8236, now cherry-picked onto
Version6.5, so this is a single commit on top of it.)

Ref: https://issues.bloomlibrary.org/youtrack/issue/BL-16760

Devin review

---

This change is 

[greptile-apps]

Greptile Summary

This PR makes the Publish tab use the language chooser’s own custom-name decision instead of recomputing it through LibPalaso.

• Passes LanguageChangeEventArgs.IsCustomName to the sign-language writing system.
• Clarifies that chooser-provided default and desired names are authoritative.
• Adds regression coverage for both directions of the mzc naming disagreement.

Important Files Changed

Filename	Overview
src/BloomExe/web/controllers/LanguageChangeEventArgs.cs	Clarifies the existing IsCustomName contract without changing its implementation.
src/BloomExe/web/controllers/PublishApi.cs	Aligns Publish sign-language persistence with the chooser contract and existing Collection Settings handlers.
src/BloomTests/web/controllers/LanguageChangeEventArgsTests.cs	Replaces divergence-pinning coverage with regression cases for untouched and deliberately customized mzc names.

_{Reviews (2): Last reviewed commit: "Ask the language chooser, not LibPalaso,..." | Re-trigger Greptile}

[andrew-polk]

[Claude Opus 5] Consulted Devin on 2026-08-26 up to commit b4ff50359ecc618759d7bb067cc011e493a475c7. Clean: no Bugs and no Investigate flags. One Informational item ("Sign-language handler now matches the dialog") — an observation, not an action item, so not mirrored as a thread.

[andrew-polk]

[Claude Opus 5] Consulted Devin on 2026-08-26 up to commit a5cbae864 (rebased onto master after #8236 merged). Clean: no Bugs and no Investigate flags. One Informational item ("Sign-language handler now matches the dialog") — an observation, not an action item.