Localization & Accessibility
Parch serves a bilingual audience: Persian speakers first, everyone else second, in that order of priority. This section documents the translation systems, formats, and testing that make software work in both, plus the accessibility baseline that applies everywhere.
Translation workflow
Gettext end to end: extraction, catalogs, plural rules, and tooling.
Persian & RTL specifics
Numerals, typography, mixed direction, and locale defaults.
Testing l10n & a11y
How to prove a build is translatable and accessible before release.
The contract
- Persian translations ship at release time for first-party apps; English is the source, Persian is not a later add-on.
- Every user-visible string goes through gettext (or the toolkit equivalent) from the first commit.
- RTL readiness is a layout property, not a translation property (see RTL & Persian in the HIG).
- Accessibility (keyboard completeness, accessible names, contrast) is a release blocker; see the HIG accessibility rules.
Architecture that scales beyond two languages
The tooling here (gettext catalogs, per-app translation domains, desktop
entries with [fa] keys) is language-agnostic. Adding Arabic, Azerbaijani,
or any LTR locale later means adding a translation file, not changing
architecture. Design decisions that would not survive a third language
(hardcoded fonts, direction assumptions, string concatenation) are bugs.