One translation key labels two different fields on the branch form

[sridharkalaibala]

Found while seeding the language packs (#444): lang_register_title is used for two different labels in the same file.

frontend/modals/branch.html:209

<th scope="row"><lang class="lang_register_title">Pincode  </lang> :</th>

frontend/modals/branch.html:264

<th scope="row"><lang class="lang_register_title">  Low Stock Notification Range  </lang> :</th>

One key cannot correctly translate both "Pincode" and "Low Stock Notification Range" in any language — whichever word is chosen, one of the two fields is mislabelled.

It is already wrong in Tamil today: both render as பதிவுகள் ("registers"), which matches neither. A shopkeeper reading Tamil sees a field called "registers" where the form is asking for a postal code.

English readers never see this, which is why it has survived.

The fix

Give each field its own key — the name suggests lang_register_title was a copy-paste from a third place, so check where else it appears before renaming.

1. Add two keys, e.g. lang_pincode_title (which already exists — check whether it fits) and a new one for the notification range.
2. Update languages/ta.json, and any other pack that has a word for the old key.
3. node tests/tools/i18n-coverage.js and node --test tests/i18n.test.js should stay clean.

Good first issue because

It needs no knowledge of the codebase beyond the two lines above, and the change is contained to markup plus one language file. Reading Tamil helps for the second half but is not required — say so in the PR and somebody who does can check the wording.

[Sj14122004]

Hi @sridharkalaibala, I’d like to work on this issue.

My strategy is to inspect the existing translation keys and their other usages, then give the Pincode and Low Stock Notification Range fields separate keys. I’ll update the affected language entries, verify the markup, and run the i18n coverage and test suites to ensure there are no regressions.

If that approach sounds good, please assign this issue to me.

[sridharkalaibala]

Thanks for the clear plan. You are still assigned to #161, so please keep that as your one active issue for now. Once its PR is open and review feedback is settled, come back here and we can assign this translation fix.

[sonalisrisivani]

I'll take this — giving the pincode and low-stock fields their own i18n keys.

[sridharkalaibala]

Thanks for taking this on, @sonalisrisivani. I reviewed your PR #484: separating the pincode key is the right direction, but the current patch also removes lang_register_title even though the Low Stock Notification Range row still uses it. Please update that row to its own dedicated key (with all language-pack entries), keep the pincode key separate, and include the focused i18n coverage/test evidence. I’ll re-review the PR after the update.