Problem Summary:
Current string resource arrays (like language, transaction_type, subject_level, etc.) and individual string entries exhibit duplication, inconsistent naming (camelCase vs snake_case), and are fragile for Kotlin code that matches or removes items by value. Several items also lack proper translation flags, and some arrays duplicate single string values that already exist in the codebase.
Details and Examples:
- Duplication and Naming Issues:
- Arrays contain both duplicated
<string> entries and items directly inside <string-array>, leading to maintenance issues and inconsistent casing (e.g., "english" vs "English").
open_With uses camelCase, but most other names use snake_case.
- Flagging Non-translatable Strings:
- Language names (like
English, नेपाली, Français in the language array) should be marked translatable="false" as they should appear in their native scripts.
- Crowdin and other tools might flag these otherwise.
- Fragile Value Matching in Kotlin Code:
- Arrays like
grade_level and subject_level use "All" as a sentinel and code compares item value, which breaks if translated. (E.g. if (it != "All") ...).
- Instead, code should match by index (index 0 = no filter) or use individual string references.
- Resource Reference Consistency:
transaction_type duplicates existing strings @string/credit and @string/debit, should instead reference these directly.
subject_level duplicates items in level array; only addition is "All" at the top.
Recommended Fixes:
- For language and similarly referenced arrays:
- Define every item as individual
<string name="lang_.." translatable="false">...</string>
- Reference these in the corresponding
<string-array> using @string/lang_...
<string name="lang_english" translatable="false">English</string>
<string name="lang_nepali" translatable="false">नेपाली</string>
<string name="lang_french" translatable="false">Français</string>
<string-array name="language">
<item>@string/lang_english</item>
<item>@string/lang_nepali</item>
<item>@string/lang_french</item>
</string-array>
- This eliminates duplication, makes items addressable, and ensures language names aren't translated accidentally.
- Add
translatable="false" to all standardized proper names and technical/medical terms (ex: diagnosis_list/ICD terms).
- Adjust arrays like
transaction_type and subject_level to reference shared items (like @string/credit, @string/debit, and values from the level array).
- Adjust Kotlin code to check array index rather than hardcoded string value for filters (e.g., for "All"), to avoid breakage if translations differ.
Impact:
- More robust localization, safer code (avoiding breakage if resource values change), easier to update/add languages, and clearer intent for translators.
Additional Notes:
team_type, contact_type, sort_by_date, and sort_member appear safe as they are display-only and not value-matched in code.
Action Items:
- Refactor resource XMLs as above for language, transaction type, subject level, grade level, etc.
- Add
translatable="false" to all relevant standard/proper names and technical terms.
- Update Kotlin code to match by index for filter logic where currently matched by string value (esp. sentinel values like "All").
- Remove resource duplication by referencing shared items.
- Adopt uniform naming for all string resources (recommend snake_case for consistency).
Problem Summary:
Current string resource arrays (like
language,transaction_type,subject_level, etc.) and individual string entries exhibit duplication, inconsistent naming (camelCase vs snake_case), and are fragile for Kotlin code that matches or removes items by value. Several items also lack proper translation flags, and some arrays duplicate single string values that already exist in the codebase.Details and Examples:
<string>entries and items directly inside<string-array>, leading to maintenance issues and inconsistent casing (e.g., "english" vs "English").open_Withuses camelCase, but most other names use snake_case.English,नेपाली,Françaisin the language array) should be markedtranslatable="false"as they should appear in their native scripts.grade_levelandsubject_leveluse "All" as a sentinel and code compares item value, which breaks if translated. (E.g.if (it != "All") ...).transaction_typeduplicates existing strings@string/creditand@string/debit, should instead reference these directly.subject_levelduplicates items inlevelarray; only addition is "All" at the top.Recommended Fixes:
<string name="lang_.." translatable="false">...</string><string-array>using@string/lang_...translatable="false"to all standardized proper names and technical/medical terms (ex:diagnosis_list/ICD terms).transaction_typeandsubject_levelto reference shared items (like@string/credit,@string/debit, and values from thelevelarray).Impact:
Additional Notes:
team_type,contact_type,sort_by_date, andsort_memberappear safe as they are display-only and not value-matched in code.Action Items:
translatable="false"to all relevant standard/proper names and technical terms.