test: detect R.string duplicates of backend translations

[david-allison]

Note

Assisted-by: Claude Opus 4.6

Code was written by Claude, with much re-prompting for comment formatting, abstractions and code changes
Code/comments were manually refactored and made less verbose

---

A number of my recent code reviews were flagging that strings added to R.string already exist in TR (GeneratedTranslations).

Approach

• Iterate the English strings from both TR and R.string, and fail if there are duplicates not defined in one of two BASELINE_ variables
• Produce copy-pasteable BASELINE text when the backend is updated

---

This test:

• Automates my review comments
• Produces copy-pasteable output to the BASELINE when the backend is updated
  • Allowing a fast fix of the test
• Lists opportunities where we can remove duplicated strings
  • Reducing APK size
  • including .toSentenceCase() fixes
• Ensures the baseline list is updated when strings are fixed

The format of BASELINE entries lists all the R.string and TR cases:
In some cases, there can be a many:many mapping, and a developer needs
to decide which to select:

* R.string.deck_conf_general | R.string.pref_cat_general
* TR.preferencesGeneral() | TR.schedulingGeneral()

• Related to [Design] Inconsistent String Casing #15760

How Has This Been Tested?

• Test-only
• Removed 2 strings from both BASELINEs and the test error provided the correct fix

Learning (optional, can help others)

• Our editorConfig removed my nicely formatted comments
• We had a LOT more strings than expected
  • BASELINE_DUPLICATES: 78
  • BASELINE_CASE_INSENSITIVE_DUPLICATES: 41

Checklist

• You have a descriptive commit message with a short title (first line, max 50 chars).
• You have commented your code, particularly in hard-to-understand areas
• You have performed a self-review of your own code
• UI changes: include screenshots of all affected screens (in particular showing any new or changed strings)
• UI Changes: You have tested your change using the Google Accessibility Scanner