WEB-489-fix/add-missing-translation-keys

[shubhamkumar9199]

Description

This pr Added all missing translation keys to all 13 language files:
(e.g., labels.text.Collection Sheet, labels.inputs.Updated )

#{Issue Number}
WEB-489

Screenshots, if any

before:

after:

Checklist

Please make sure these boxes are checked before submitting your pull request - thanks!

• If you have multiple commits please combine them into one commit by squashing them.

• Read and understood the contribution guidelines at web-app/.github/CONTRIBUTING.md.

Summary by CodeRabbit

• Localization
  • Enhanced multilingual support across 12 languages by adding translations for new financial features and UI components, including Cashiers, Collection Sheet, Fund Mapping, Loans Deferred Income, Fixed Deposit Account Details, Recurring Deposit Account Details, and Shares Account General.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Note

.coderabbit.yaml has unrecognized properties

CodeRabbit is using all valid settings from your configuration. Unrecognized properties (listed below) have been ignored and may indicate typos or deprecated fields that can be removed.

⚠️ Parsing warnings (1)

Validation error: Unrecognized key(s) in object: 'pre_merge_checks'

⚙️ Configuration instructions

• Please see the configuration documentation for more information.
• You can also validate your configuration using the online YAML validator.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Walkthrough

The PR adds new translation keys consistently across all supported language locale files. These keys include UI labels for financial operations and account management features such as cashiers, collection sheets, fund mapping, loans, deposits, and shares accounts.

Changes

Cohort / File(s)	Summary
Translation key additions across all locale files src/assets/translations/cs-CS.json, de-DE.json, en-US.json, es-CL.json, es-MX.json, fr-FR.json, it-IT.json, ko-KO.json, lt-LT.json, lv-LV.json, ne-NE.json, pt-PT.json, sw-SW.json	Added new translation keys consistently across all language locales: "Updated On", "Cashiers", "Collection Sheet", "Fixed Deposit Account Details", "Fund Mapping", "Loans Deferred Income", "Recurring Deposit Account Details", "Shares Account General", "View Cashier", and "Create Saving Product" (in select locales), each paired with locale-specific translations.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Homogeneous changes across multiple files—the same translation keys are being added with only locale-specific values differing
• No functional logic, control flow, or structural changes
• Primarily requires spot-checking a few files to ensure all keys are present, properly formatted as JSON, and consistently named across locales
• Verification of translation accuracy may require domain knowledge or language expertise depending on reviewer familiarity with the locales

Possibly related PRs

• Cherry-pick dev-angular-19 changes back to dev #2865 — Adds "Collection Sheet" translation key usage across the application templates and updates related translation entries
• WEB-481 :- a translation problem in mifos home page Tooltip text shows tooltips.Collection Sheet instead of Collection Sheet #2863 — Updates a template to use the correct "Collection Sheet" translation key in tooltips

Suggested reviewers

• IOhacker
• steinwinde
• gkbishnoi07
• alberto-art3ch

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'WEB-489-fix/add-missing-translation-keys' clearly and specifically describes the main change: adding missing translation keys across multiple language files.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 3

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)

src/assets/translations/sw-SW.json (1)

2532-2532: [CRITICAL] Wrong language in Swahili translation file at line 2532.

The value "Tillgängligt utbetalningsbelopp (med överbetalning)" is in Swedish, not Swahili. This will display incorrectly to Swahili-speaking users and break the user experience.

Swedish words detected:

• "Tillgängligt" (available)
• "utbetalningsbelopp" (disbursement amount)
• "överbetalning" (overpayment)

Please replace this entry with a proper Swahili translation for "Available Disbursement Amount (with Over Applied)".

src/assets/translations/lv-LV.json (1)

354-354: Inconsistent translation detected for "Collection Sheet" key.

The translation key "Collection Sheet" appears twice in this file with two different Latvian translations:

• Line 354 (in labels.buttons): "Kolekcijas lapa"
• Line 2808 (in labels.text): "Iekasēšanas lapa"

While the two Latvian terms are similar in meaning ("Collection sheet" vs "Cashing/collection sheet"), using two different translations for the same English key within a single language file creates inconsistency and can cause confusing translations depending on which context references this key.

Please clarify:

1. Which translation should be the authoritative one?
2. Should the new additions consolidate on a single translation, or do the different contexts require different terms?
3. Are similar inconsistencies present in other language files?

Also applies to: 2808-2808

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between bdf0e71 and 54ca271.

📒 Files selected for processing (13)

• src/assets/translations/cs-CS.json (10 hunks)
• src/assets/translations/de-DE.json (10 hunks)
• src/assets/translations/en-US.json (10 hunks)
• src/assets/translations/es-CL.json (10 hunks)
• src/assets/translations/es-MX.json (10 hunks)
• src/assets/translations/fr-FR.json (10 hunks)
• src/assets/translations/it-IT.json (10 hunks)
• src/assets/translations/ko-KO.json (10 hunks)
• src/assets/translations/lt-LT.json (10 hunks)
• src/assets/translations/lv-LV.json (10 hunks)
• src/assets/translations/ne-NE.json (10 hunks)
• src/assets/translations/pt-PT.json (10 hunks)
• src/assets/translations/sw-SW.json (10 hunks)

🔇 Additional comments (39)

src/assets/translations/fr-FR.json (3)

2422-2423: Investigate potential duplicate key with inconsistent capitalization.

Lines 2422–2423 define both "Updated on" and "Updated On" with the same translation "Mis à jour le". Verify whether both keys are intentional or if one is a duplicate that should be removed. If both are needed, clarify why (e.g., context-specific capitalization).

---

2780-2780: Confirm new translation keys are consistently added across all language files.

This PR adds translation keys including Cashiers, Collection Sheet, Fixed Deposit Account Details, Fund Mapping, Loans Deferred Income, Recurring Deposit Account Details, Shares Account General, and View Cashier. Per the PR description, these should be added consistently across all 13 supported language files.

Verify that all eight new keys are present in every language file (en-US, de-DE, es-MX, es-CL, it-IT, ko-KO, lt-LT, lv-LV, ne-NE, pt-PT, sw-SW, and cs-CS), with semantically equivalent translations in each locale.

Also applies to: 2808-2808, 3002-3002, 3015-3015, 3068-3068, 3157-3157, 3218-3218, 3285-3285

---

1-3699: JSON structure and syntax are valid.

The file maintains correct JSON formatting, proper nesting, and valid UTF-8 encoding throughout. No breaking changes to existing translation keys were detected.

src/assets/translations/cs-CS.json (2)

2422-2423: Duplicate keys for "Updated" with different casing.

Lines 2422–2423 contain both "Updated on" and "Updated On" (case variation), both mapping to the same Czech translation "Aktualizováno dne". Confirm whether this duplication is intentional for supporting both casing conventions, or if one should be removed to avoid redundancy.

---

2423-2423: Approved: New translation keys added with proper Czech translations.

The following new keys have been added with appropriate Czech translations and align with the PR objective (e.g., Cashiers, Fund Mapping, Fixed Deposit Account Details, Loans Deferred Income, Recurring Deposit Account Details, Shares Account General, View Cashier, Create Saving Product, Updated On). Translations appear accurate and consistent with the document's style.

Also applies to: 2780-2780, 2861-2861, 3002-3002, 3015-3015, 3069-3069, 3158-3158, 3219-3219, 3286-3286

src/assets/translations/es-CL.json (3)

2422-2423: Potential duplicate translation key with casing variation.

Lines 2422-2423 contain both "Updated on" and "Updated On" (capitalization difference). Verify this is intentional—if both keys serve the same purpose, consolidation may be needed to avoid translation maintenance issues.

---

354-354: Inconsistent "Collection Sheet" translation across sections.

The key "Collection Sheet" appears in three different sections with three different Spanish translations:

• Line 354 (buttons): "Hoja de recuperación"
• Line 2581 (menus): "Hoja de colección"
• Line 2808 (text): "Hoja de Cobro"

Verify these translations are intentionally context-specific or if they should be unified for consistency.

Also applies to: 2581-2581, 2808-2808

---

2423-2423: Verify completeness of PR across all 13 language files.

This review covers only the es-CL.json file. The PR description states translation keys were added "across all 13 language files." Confirm that:

• All 10 marked additions in this file are present in all other language files
• Translations are consistent in meaning and style across locales
• No keys were missed in other language files

Also applies to: 2780-2780, 2808-2808, 2861-2861, 3002-3002, 3015-3015, 3069-3069, 3158-3158, 3219-3219, 3286-3286

src/assets/translations/sw-SW.json (1)

2421-2422: Verify intentionality of duplicate keys with capitalization variants.

Lines 2421 and 2422 define:

• "Updated on": "Ilisasishwa" (line 2421)
• "Updated On": "Ilisasishwa" (line 2422 - newly added)

Both keys map to identical Swahili translations. The AI summary notes "Updated On (duplicate of Updated on)". Confirm whether this capitalization variant is intentional (e.g., for different UI contexts) or if one should be removed to avoid confusion.

src/assets/translations/ko-KO.json (3)

2423-2424: Verify capitalization distinction for "Updated on" vs "Updated On"

Lines 2423–2424 show two keys with identical values but different capitalization ("Updated on" and "Updated On"). While this may be intentional to support different UI contexts, please confirm this is not a duplicate entry. If both are necessary, consider documenting the purpose of each variant.

---

2780-2780: Addition of translation keys appears appropriate, but cross-language consistency requires verification

The new translation keys (Cashiers, Collection Sheet, Fund Mapping, Create Saving Product, account details, etc.) are well-placed in the logical sections and have reasonable Korean translations. However, since this PR adds missing keys across all 13 language files, you should verify that:

1. Key naming consistency: All new key names match identically across all 13 language file files (including punctuation and capitalization)
2. Semantic consistency: The translations convey equivalent meaning across all languages
3. Placeholder alignment: If any keys contain templated values or parameters, they should be handled consistently

Consider running a diff or validation script across all 13 language files to ensure no keys are missing or misspelled in any locale.

Also applies to: 2808-2808, 2861-2861, 3002-3002, 3015-3015, 3069-3069, 3158-3158, 3219-3219, 3286-3286

---

1-3700: JSON structure is valid; approve additive translation changes

The JSON structure is syntactically valid, and all additions are purely additive (no breaking changes to existing keys). The new translation entries are organized logically and the Korean translations appear appropriate for their UI contexts.

src/assets/translations/pt-PT.json (3)

2423-2423: Verify capitalization intent for "Updated On" vs "Updated on".

Line 2423 adds "Updated On" (capitalized) while line 2422 contains "Updated on" (lowercase). Both keys now exist in the file. Ensure this is intentional and that each version is used in its appropriate UI context (e.g., form labels vs inline text). If both are genuinely needed, the distinction is appropriate; otherwise, consider consolidating to avoid duplication.

---

2780-2780: Confirm "Cashiers" and "Collection Sheet" key locations across sections.

The keys "Cashiers" (line 2780) and "Collection Sheet" (line 2808) appear in the text.Cashier Transactions section. Verify these placements align with how they're referenced in the application code. If these keys are also referenced from other sections (e.g., buttons, menus, inputs), ensure they're not duplicated elsewhere in the file or consider centralizing them.

Also applies to: 2808-2808

---

3015-3015: Translations follow established patterns—approve with spot-check.

The newly added translation keys ("Fund Mapping", "Loans Deferred Income", "Recurring Deposit Account Details", "Shares Account General", "View Cashier") follow Portuguese grammatical conventions and match the style of existing similar translations in the file (e.g., compare with lines 2855, 2944, 3002, etc.). No formatting or structural issues detected.

Also applies to: 3069-3069, 3158-3158, 3219-3219, 3286-3286

src/assets/translations/it-IT.json (3)

2423-2423: ✓ Translation keys added with correct structure and formatting.

The new translation entries follow the existing file structure and naming conventions. JSON formatting is valid, indentation is consistent, and all Italian translations appear linguistically appropriate and aligned with financial terminology used elsewhere in the file (e.g., "Mappatura dei Fondi" matches patterns seen in accounting sections; "Ricavi Differiti sui Prestiti" uses standard accounting language).

Also applies to: 2780-2780, 2808-2808, 3002-3002, 3015-3015, 3069-3069, 3219-3219, 3286-3286

---

2422-2423: Minor: Confirm intentionality of "Updated on" vs "Updated On" duplication.

Lines 2422 and 2423 define both "Updated on" and "Updated On" with identical Italian translations ("Aggiornato il"). This is likely intentional for different UI contexts (e.g., form labels vs button text), but the duplication should be documented or confirmed. Consider adding a brief comment if this pattern is intentional but non-obvious to future maintainers.

---

1-3700: Note: PR scope spans 13 language files, but only it-IT.json provided for review.

The PR description indicates that these translation keys are added consistently across all 13 supported language files. However, only the Italian locale is included in this review. To confirm completeness and consistency across all locales (cs-CS, de-DE, en-US, es-CL, es-MX, fr-FR, ko-KO, lt-LT, lv-LV, ne-NE, pt-PT, sw-SW), verification of the other 12 files would be needed. Consider requesting a summary of which files were modified or providing a diff showing all changed files.

src/assets/translations/lv-LV.json (1)

2750-3360: Approve: Translation additions are well-formed and linguistically sound.

The new Latvian translations added in the text section (lines 2750-3360) follow established patterns and appear to be accurate, idiomatic translations. Examples reviewed:

• "Cashiers": "Kasieri" ✓
• "Fund Mapping": "Fondu kartēšana" ✓
• "Loans Deferred Income": "Kredītu atliktie ienākumi" ✓
• "Recurring Deposit Account Details": "Periodiskā noguldījuma konta informācija" ✓
• "Shares Account General": "Akciju konta vispārīga informācija" ✓

The translations maintain consistency with the existing translation style and tone. JSON structure and formatting are correct.

src/assets/translations/de-DE.json (3)

2423-2423: Translation additions are properly formatted and syntactically correct.

All marked additions in the German translation file follow the established JSON structure and naming conventions. The translations appear to be professionally rendered and consistent with existing German translations in the file.

---

2780-2780: Verify translation consistency across related entries.

While the new translation keys look appropriate, I recommend verifying that:

• "Cashiers" / "Kassierer" is consistent with other UI text using similar terminology
• "Collection Sheet" / "Sammelblatt" aligns with existing financial terminology in the file
• "Create Saving Product" / "Sparprodukt erstellen" follows the same pattern as other "Create [X]" entries

Spot-check of related entries suggests consistency, but given the scope of this PR across 13 language files, consider verifying a few key terms are uniformly applied.

Also applies to: 2807-2807, 2860-2860

---

3001-3001: Complex translations are well-executed.

The following entries demonstrate solid translation work:

• Line 3001: "Fixed Deposit Account Details" → "Details zum Festgeldkonto" (appropriate compound structure)
• Line 3014: "Fund Mapping" → "Fondszuordnung" (idiomatic German rendering)
• Line 3068: "Loans Deferred Income" → "Abgegrenzte Darlehenserträge" (correct accounting terminology)
• Line 3157: "Recurring Deposit Account Details" → "Details zum wiederkehrenden Einlagenkonto" (accurate and clear)
• Line 3218: "Shares Account General" → "Aktienkonto Allgemein" (consistent with domain terminology)
• Line 3285: "View Cashier" → "Kassierer anzeigen" (action verb correctly placed)

No issues identified with these translations.

Also applies to: 3014-3014, 3068-3068, 3157-3157, 3218-3218, 3285-3285

src/assets/translations/ne-NE.json (3)

2423-2424: Verify consistency of "Updated on" vs "Updated On" translations.

Lines 2423-2424 contain both "Updated on" and "Updated On" with identical translations ("मा अद्यावधिक गरियो"). While these may be intentionally synonymous, confirm whether:

1. Both keys are needed in the UI (one for sentence context, one for title/label context)
2. The translations properly differentiate between lowercase and title case if appropriate in Nepali
3. This pattern is consistent with how other locales handle capitalization variants

Cross-reference with the en-US and other language files to ensure the same keys exist and follow parallel conventions.

---

1-3700: Confirm translation completeness and consistency across all 13 language locales.

The PR summary states that new translation keys are added "consistently across all supported language locale files" (13 locales). The AI-generated summary confirms additions across en-US, de-DE, es-CL, es-MX, fr-FR, it-IT, ko-KO, lt-LT, lv-LV, pt-PT, and sw-SW.

Verify that:

1. All new keys added to ne-NE.json also exist in the other 12 language files with appropriate translations
2. No keys were missed in any locale
3. The set of new keys is identical across all locales (allowing for legitimate translation variations)

A common risk in multi-locale updates is inconsistent key coverage across files.

---

1-50: Validate JSON syntax and structure integrity.

While the file appears syntactically valid, confirm:

1. All braces, brackets, and commas are balanced and properly placed
2. No unescaped special characters in the translated text
3. Proper UTF-8 encoding of Nepali script throughout
4. No trailing commas in objects that would cause parse failures

A quick JSON validation pass (e.g., using a JSON linter) would catch structural issues before deployment.

Also applies to: 2715-3360

src/assets/translations/en-US.json (1)

2790-2790: Additive translation keys look appropriate.

The new translation entries (Cashiers, Collection Sheet, Create Saving Product, Fixed Deposit Account Details, Fund Mapping, Loans Deferred Income, Recurring Deposit Account Details, Shares Account General, View Cashier) follow the established pattern and are consistent with the file's structure and existing keys. All values are appropriately English text for the en-US locale.

Also applies to: 2818-2818, 2871-2871, 3012-3012, 3025-3025, 3163-3163, 3253-3253, 3325-3325, 3393-3393

src/assets/translations/lt-LT.json (2)

1-100: ✅ JSON structure and translation consistency approved

The translation file is well-formed JSON with proper nesting, quoting, and syntax throughout. All newly added translation keys for financial operations and account management features are consistently placed in semantically appropriate sections (text, heading, inputs) and follow the existing naming conventions and style patterns for the Lithuanian language.

The 10 new translation keys (Updated On, Cashiers, Collection Sheet, Create Saving Product, Fixed Deposit Account Details, Fund Mapping, Loans Deferred Income, Recurring Deposit Account Details, Shares Account General, View Cashier) are properly nested, use consistent formatting with existing entries, and are contextually appropriate for the financial/banking domain.

Also applies to: 2400-2450, 2750-2850, 3000-3100, 3150-3250, 3280-3300

---

1-3700: Note: Partial context for verification

This review covers the Lithuanian (lt-LT.json) language file only. The PR objectives mention that missing translation keys have been added across all 13 supported language files (cs-CS, de-DE, en-US, es-MX, es-CL, fr-FR, it-IT, ko-KO, lv-LV, ne-NE, pt-PT, sw-SW, and lt-LT). To fully validate the PR, each of the other 12 language files should be reviewed to ensure:

1. All the same translation keys are present across all languages
2. Keys are placed in consistent locations within each language file
3. No language-specific formatting or structural inconsistencies exist

If you have access to the other language files in the PR, please confirm that the new translation keys are consistently added across all 13 language files as described in the PR objectives.

src/assets/translations/es-MX.json (11)

2424-2424: Translation key addition for casing variant is consistent.

The addition of "Updated On" (capitalized) alongside the existing "Updated on" (lowercase) is appropriate for supporting UI elements that use different casing conventions. Both keys correctly map to the same Spanish translation "Actualizado en".

---

2782-2782: Translation for Cashiers is appropriate.

The addition of "Cashiers": "Cajeros" correctly translates the English term to Spanish for financial operations.

---

2810-2810: Collection Sheet translation is domain-appropriate.

The addition of "Collection Sheet": "Hoja de Cobro" uses correct Spanish terminology for financial operations.

---

2863-2863: Saving Product translation is correct.

The addition of "Create Saving Product": "Crear Producto de Ahorro" accurately translates the key. Note that the system uses both "Saving Product" and "Savings Product" variants in different contexts, which is acceptable for supporting different UI element styles.

---

3004-3004: Fixed Deposit Account Details translation is accurate and consistent.

The addition of "Fixed Deposit Account Details": "Detalles de la cuenta de Depósito Fijo" uses correct terminology consistent with other account-related translations in the file.

---

3017-3017: Fund Mapping translation is appropriate.

The addition of "Fund Mapping": "Mapeo de Fondos" correctly translates the operational term using proper financial terminology.

---

3071-3071: Loans Deferred Income translation is accurate.

The addition of "Loans Deferred Income": "Ingresos Diferidos de Préstamos" correctly translates the accounting terminology used for deferred income recognition related to loan products.

---

3160-3160: Recurring Deposit Account Details translation is accurate.

The addition of "Recurring Deposit Account Details": "Detalles de cuenta de Depósito Recurrente" correctly translates the label. Note: Minor grammatical variation exists with similar keys (with/without definite article "la"), but both forms are acceptable in Spanish.

---

3221-3221: Shares Account General translation is accurate.

The addition of "Shares Account General": "Cuenta de Acciones General" correctly translates the label for general share account views.

---

3288-3288: View Cashier translation is consistent.

The addition of "View Cashier": "Ver Cajero" correctly translates the action label and maintains consistency with other cashier-related terminology in the file.

---

1-3702: Overall translation file quality and completeness is solid.

This file adds 10 new translation keys across the Spanish (Mexico) locale to support UI elements for:

• Cashier management ("Cashiers", "View Cashier")
• Collection operations ("Collection Sheet")
• Savings/deposit products ("Create Saving Product", "Fixed Deposit Account Details", "Recurring Deposit Account Details", "Shares Account General")
• Financial operations ("Fund Mapping", "Loans Deferred Income")
• Account metadata ("Updated On")

All translations are:

• ✓ Accurate and idiomatic Spanish
• ✓ Contextually appropriate for financial operations
• ✓ Consistent with existing terminology in the file
• ✓ Properly formatted JSON
• ✓ Well-placed within the appropriate labels subsections

The additions align with the PR objective of adding missing translation keys consistently across supported locales to expose new or previously untranslated UI elements.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Missing Czech translation for "Collection Sheet" key.

Line 2808 shows "Collection Sheet": "Collection Sheet" — the value is in English, not Czech. This should be translated to Czech. Based on the PR objective which explicitly mentions adding this key, please verify the correct Czech translation is provided (appears it should match the existing translated version elsewhere in the file, e.g., "Sbírkový list").

-      "Collection Sheet": "Collection Sheet",
+      "Collection Sheet": "Sbírkový list",

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	"Collection Sheet": "Collection Sheet",
	"Collection Sheet": "Sbírkový list",

🤖 Prompt for AI Agents

In src/assets/translations/cs-CS.json around line 2808 the value for the
"Collection Sheet" key is still in English; replace the right-hand value with
the correct Czech translation "Sbírkový list" (preserving the existing JSON
string quoting and trailing comma) and ensure there are no duplicate keys
elsewhere in the file to avoid conflicts.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Remove redundant "Updated on" / "Updated On" keys or clarify their purpose.

Both "Updated on": "Updated on" (line 2430) and "Updated On": "Updated On" (line 2431) exist in the file and differ only in capitalization. If these are intended to serve different UI contexts (e.g., sentence casing vs. title casing), document this or consolidate to a single key with consistent naming. Otherwise, remove the duplicate to avoid confusion during maintenance and reduce translation file bloat.

🤖 Prompt for AI Agents

In src/assets/translations/en-US.json around lines 2430 to 2431, there are two
keys that differ only by capitalization ("Updated on" and "Updated On");
consolidate them by choosing a single canonical key name (prefer consistent
casing used across the file, e.g., "Updated on" for sentence case or "Updated
On" for title case), update any code references to use the chosen key, and
remove the duplicate entry; if both are intentionally required for different UI
contexts, add a short inline comment documenting their purpose and keep both
with distinct, well-documented names.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

# First, let's examine the translation file to see the context
cd src/assets/translations
wc -l lv-LV.json

Repository: openMF/web-app

Length of output: 172

---

🏁 Script executed:

# Check the specific lines and surrounding context
sed -n '2420,2425p' src/assets/translations/lv-LV.json

Repository: openMF/web-app

Length of output: 172

---

🏁 Script executed:

# Search for usage of both "Updated On" and "Updated on" keys in the codebase
rg -i '"updated\s+on"' --type js --type ts --type tsx --type jsx -A 2 -B 2

Repository: openMF/web-app

Length of output: 172

---

🏁 Script executed:

# Check if there are similar patterns of duplicate keys with different capitalization in the translation file
rg ':\s*"[^"]*"' src/assets/translations/lv-LV.json | rg -i 'updated|created|modified' | head -20

Repository: openMF/web-app

Length of output: 172

---

🌐 Web query:

i18n localization best practices capitalization variants duplicate keys same translation

💡 Result:

Concise best-practices for capitalization variants and duplicate keys in i18n/localization:

1. Use semantic, namespaced keys (not UI text) so keys reflect meaning/context (e.g., common.buttons.next vs "Next"). This makes deduping and reuse safe. [1][6]

2. Centralize reusable UI labels in a shared/global namespace (ok/cancel/next) and keep context‑specific keys when tone/context differs. Don’t overuse a single global key for different meanings. [1][6]

3. Deduplicate intentionally: detect identical translations and either link/alias or merge keys so translators only translate once; keep a single source‑of‑truth key when the meaning is identical. Use tooling (Lokalise/Loco/etc.) to find and manage duplicates. [2][3]

4. Do NOT rely on concatenation of multiple keys to form sentences (word order and grammar vary by language). Create full sentence keys or use ICU/message format with interpolation. [6][3]

5. Handle capitalization as presentation, not translation, when possible:

   • Store a neutral/base form (e.g., lowercase or sentence case) as the canonical translation, and apply casing transformations in the UI layer when safe.
   • If language requires different word forms or casing rules (or title/sentence case affects grammar), provide separate translation variants (e.g., common.buttons.next.titlecase vs common.buttons.next) and let translators supply correct forms. [5][6]

6. Use ICU/plural/context features for pluralization and grammatical context instead of separate duplicated keys; prefer libraries’ built‑in resolution and context rules. [5]

7. Enforce quality with linting/CI: disallow duplicate keys within a locale, check missing keys across locales, and run duplicate/key‑format rules (e.g., intlify/vue-i18n ESLint rules). [7][4]

8. Policy summary (quick checklist):

   • Semantic names + namespaces ✔︎
   • Centralize truly identical strings ✔︎
   • Keep context-specific keys when meaning/tone differs ✔︎
   • Avoid concatenation ✔︎
   • Treat capitalization as presentation, unless language forces separate translations ✔︎
   • Use tooling to detect/merge/link duplicates ✔︎
   • Lint/CI to catch duplicate/missing keys ✔︎

Sources: Lokalise key‑naming & dedupe guidance; Lokalise duplicate‑translations help; i18next translation resolution; Loco duplicate key behaviour; best‑practice guides on deduping and casing; intlify/vue‑i18n lint rules. [1][2][5][3][6][7]

---

🌐 Web query:

translation management systems duplicate keys different capitalization code smell anti-pattern

💡 Result:

Short answer: yes — having duplicate translation keys that differ only by capitalization is a code smell / anti‑pattern in TMS/i18n. It causes silent overwrites, extra translation work, ambiguous lookups, tooling/locale parser differences, and merge conflicts. Fix it by enforcing a single key-casing convention + lint/CI checks, deduplicating and linking keys in your TMS, and using descriptive stable keys (or IDs) instead of ad‑hoc text-derived names.

Why it’s a problem (quick bullets)

• Silent overwrites or ambiguous behavior: some parsers overwrite duplicates (e.g., YAML/i18n cases) or behave inconsistently when keys differ only by case. [1][2]
• Extra work for translators: multiple keys with the same meaning force duplicate translations. TMSs provide duplicate-finder/link/merge tools because this is common and wasteful. [3]
• Tooling and platform inconsistencies: some systems are case-sensitive, others are not; that inconsistency causes bugs when moving keys between libraries, platforms, or file formats. [2][4]
• Hard to maintain and discover: inconsistent casing increases cognitive load and leads to orphan/unused keys. [5]

Recommended fixes (minimal checklist)

1. Choose and document a key naming/casing convention (e.g., snake_case or dot.nested.camelCase) and make it part of your style guide. [5]
2. Add lint rules / CI checks to detect duplicate keys and enforce casing (examples: eslint i18n plugins provide “no-duplicate-keys” and key-format rules). [1]
3. Run TMS duplicate-finder / link/merge features and collapse equivalent keys into one canonical key (or create aliases/linked keys if the TMS supports it). [3]
4. Prefer semantic, stable keys (feature/path-based) over ad-hoc text or capitalization-based keys; include translator context. [5][6]
5. Add tests that fail builds on duplicate keys or missing translations (scan YAML/JSON during CI). [2]

Sources
[1] eslint-plugin-vue-i18n — rules: no-duplicate-keys-in-locale, key-format-style.
[2] Doctolib engineering post on i18n: duplicate YAML keys, silent overwrites and enforcing simple key formats.
[3] Lokalise docs: duplicate translations, duplicate finder / linking / merging.
[4] Oracle dev docs: use capitalization deliberately in messages (guidance on case and translator expectations).
[5] Tolgee / Lang-Q guides: translation-key naming best practices and organization.

If you want, I can: (A) scan your repo for case-only duplicate keys and produce a report, or (B) give an example ESLint + CI config to enforce key casing and detect duplicates. Which would you prefer?

---

Remove duplicate translation key with alternative capitalization.

The keys "Updated On" and "Updated on" represent a code smell in i18n systems. Best practices recommend using a single canonical key with consistent casing (e.g., "Updated on") and handling capitalization transformations in the UI layer rather than duplicating translation keys. If both capitalization variants are needed in the UI, apply text transformation in the component code instead of maintaining separate translation entries. If only one variant is actually used, remove the duplicate.

🤖 Prompt for AI Agents

In src/assets/translations/lv-LV.json around line 2423, there is a duplicate
translation key differing only by capitalization ("Updated On" vs "Updated on");
remove the redundant key so only a single canonical key remains (pick the
project's preferred casing, e.g., "Updated on"), and update any UI components to
perform capitalization via presentation logic rather than adding another
translation entry; if you find code referencing the removed key, change those
references to the chosen canonical key.