sr.json mixes Cyrillic and Latin script throughout, and there is no rule in the file deciding which one wins. Measured on main:
- 2504 strings are Cyrillic-only, 1640 are Latin-only, 987 contain both.
translations.properties alone is 31 Latin keys out of 60 — general, permissions, owner, name, path, size, type, modified, checksum — sitting next to Cyrillic siblings in the same panel.
The user-visible result is a Properties panel that reads half in one script and half in the other.
Why this is filed instead of fixed
The 46-locale linguist review proposed converting three of those Latin strings (properties.checksum, checksumVerification, checksumFolderNA) to Cyrillic, on the stated grounds that they were Latin outliers inside a Cyrillic panel. #509 rejected all three after measuring the file: they are not outliers, they are the local majority. Applying that patch would have put Контролни збир directly above Permissions and Owner — moving the inconsistency rather than closing it.
The same reasoning blocks any partial fix. Whichever three strings you convert, you make some neighbourhood worse.
What this actually needs
A decision for the whole file, taken once:
- Pick the script — Serbian digraphia is real, both are correct Serbian, and this is a product call about which one AeroFTP ships (Cyrillic is the constitutional script; Latin is what most software UIs use).
- Convert
sr.json wholesale to it, ideally with a transliteration pass that a Serbian reader checks, since the mapping is regular but proper nouns, product names, code identifiers and {placeholder} tokens must not be transliterated.
- Consider whether
sr-Latn should exist as its own locale rather than forcing one choice.
npm run i18n:validate passes today and will keep passing either way — it checks structure and completeness, not script consistency. If a rule is chosen, it would be worth asserting in scripts/i18n-validate.ts so the file cannot drift back.
sr.jsonmixes Cyrillic and Latin script throughout, and there is no rule in the file deciding which one wins. Measured onmain:translations.propertiesalone is 31 Latin keys out of 60 —general,permissions,owner,name,path,size,type,modified,checksum— sitting next to Cyrillic siblings in the same panel.The user-visible result is a Properties panel that reads half in one script and half in the other.
Why this is filed instead of fixed
The 46-locale linguist review proposed converting three of those Latin strings (
properties.checksum,checksumVerification,checksumFolderNA) to Cyrillic, on the stated grounds that they were Latin outliers inside a Cyrillic panel. #509 rejected all three after measuring the file: they are not outliers, they are the local majority. Applying that patch would have putКонтролни збирdirectly abovePermissionsandOwner— moving the inconsistency rather than closing it.The same reasoning blocks any partial fix. Whichever three strings you convert, you make some neighbourhood worse.
What this actually needs
A decision for the whole file, taken once:
sr.jsonwholesale to it, ideally with a transliteration pass that a Serbian reader checks, since the mapping is regular but proper nouns, product names, code identifiers and{placeholder}tokens must not be transliterated.sr-Latnshould exist as its own locale rather than forcing one choice.npm run i18n:validatepasses today and will keep passing either way — it checks structure and completeness, not script consistency. If a rule is chosen, it would be worth asserting inscripts/i18n-validate.tsso the file cannot drift back.