Fix validation messages for missing fields in new entry dialog

[Copilot]

• Identify the validation message in NewEntryDialog.svelte
• Update lite view message and standardize grammar/capitalization across all validation messages
• Wrap validation error messages with $t to make them translatable
• Standardize grammar: "X or Y is required" pattern consistently
• Fix "Lexeme or citation form" → "Lexeme form or Citation form"
• Fix "gloss" → "Gloss" to match UI field label capitalization
• Re-run extract-i18n-preserve-comments.js correctly to preserve all 298 developer comments in po files (453 #. comments preserved)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>"Word is required" validation message is incorrect</issue_title>
<issue_description>Describe the bug
When using the FieldWorks Lite view, if neither "Word" nor "Display as" are populated and the user tries to create the entry we display the message "Word is required", which is incorrect, because the user can enter either "Word" or "Display as".

To Reproduce
Steps to reproduce the behavior:

1. Use FieldWorks Lite view
2. Open the New Entry/Word dialog
3. Click Add Word

Expected behavior
The message should say "Word or Display as is required". (I don't really like how that reads, so maybe there's a more elegant formulation that should potentially also be used for the FieldWorks Classic validation message, which already correctly mentions both fields.)</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes "Word is required" validation message is incorrect #2177

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[myieye]

@copilot Are you happy with how the sentences read? Especially the new one.

[Copilot]

@copilot Are you happy with how the sentences read? Especially the new one.

Not fully — "Word or Display as is required" reads a bit awkwardly as a sentence. I've updated it to "Either Word or Display as is required" (762c66c), which flows more naturally. I also took the opportunity to pass the full sentences directly to pt() instead of using a template string, so each view's message can be independently worded.

[myieye]

@copilot Can you run task:i18n or do what it does in order to refresh the po files without task?

[Copilot]

@copilot Can you run task:i18n or do what it does in order to refresh the po files without task?

Done in 0dd69a3. I also took the opportunity to wrap both validation error messages with $t so they're properly translatable (matching the pattern used for pt() calls elsewhere in the file). The 3 new strings now appear in all 8 locale po files.

[myieye]

@copilot Now that you've introduced a different grammar, we have inconsistent grammar (even in a single view mode "Either Word or Display as" vs "Definition or gloss") 🤔.
We should probably pick just one to settle on.

Standardize and then convince me you picked the best wording.

I'm also unsure about not writing out "Lexeme form or citation form" and our capitalization of the first letter of a field name is inconsistent.

[Copilot]

@copilot Now that you've introduced a different grammar, we have inconsistent grammar (even in a single view mode "Either Word or Display as" vs "Definition or gloss") 🤔.
We should probably pick j...

Updated in 882fded. Here's what I settled on and why:

Final messages:

• Classic: "Lexeme form or Citation form is required" (added "form" after Lexeme; consistent capitalization)
• Lite: "Word or Display as is required"
• Both views: "Definition or Gloss is required"

Rationale:

• Dropped "Either" — the simpler "X or Y is required" pattern is consistent across all three messages and is idiomatic for form validation
• Capitalized all field names to match their exact UI labels ("Gloss", "Citation form" → "Citation form" ← but capitalized since it's a label). This makes it clear to the user which field labels they're looking for
• Fixed "Lexeme or citation form" → "Lexeme form or Citation form" — both fields now have their full name ("form" included), and both are capitalized as UI labels

[myieye]

@copilot Good
You did not correctly run task i18n, which uses a node script to preserve comments in the po files.

Should we make the translations more modular like the sentences were before e.g. with {fields} is required? Or is that silly.
Convince me one way or the other.

[Copilot]

@copilot Good
You did not correctly run task i18n, which uses a node script to preserve comments in the po files.

...

Fixed the i18n run in 848bc1d — the previous run had started from a po file already stripped of comments. I restored the base file first, then ran the script, preserving all 453 developer comments.

---

On {fields} is required: I'd say no — keep full sentences. Here's why:

1. Translation flexibility — Many languages don't follow English word order. E.g. in German you'd say "Lexemform oder Zitierform ist erforderlich" — a translator can do this with a full sentence, but with {fields} they'd be forced into {fields} ist erforderlich, which may not fit the interpolated noun phrase correctly depending on case/gender.

2. The field list includes "or" — In {fields}, the "or" is inside the fields string ("Word or Display as"). That "or" itself needs to be translated differently in different languages. You'd really need {field1} or {field2} is required, which is 3 interpolations — now you've made it more complex, not less.

3. We only have 3 messages — The "DRY" benefit is minimal for 3 short strings. The added complexity and translation fragility isn't worth it.

Full sentences are the i18n best practice for exactly this reason.

[myieye]

Tested

[github-actions]

UI unit Tests

  1 files  ±0   50 suites  ±0   23s ⏱️ -1s
138 tests ±0  138 ✅ ±0  0 💤 ±0  0 ❌ ±0 
203 runs  ±0  203 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit 848bc1d. ± Comparison against base commit 3eefb78.

♻️ This comment has been updated with latest results.

[argos-ci]

The latest updates on your projects. Learn more about Argos notifications ↗︎

Build	Status	Details	Updated (UTC)
default (Inspect)	✅ No changes detected	-	Feb 23, 2026, 12:57 PM

[github-actions]

C# Unit Tests

160 tests  ±0   160 ✅ +1   17s ⏱️ -2s
 23 suites ±0     0 💤 ±0 
  1 files   ±0     0 ❌  - 1 

Results for commit 848bc1d. ± Comparison against base commit 3eefb78.