Skip to content

Complete Arabic and Hebrew localization coverage - #113

Open
codesbygom wants to merge 6 commits into
hbashton:mainfrom
codesbygom:feature/arabic-hebrew-localization
Open

codesbygom wants to merge 6 commits into
hbashton:mainfrom
codesbygom:feature/arabic-hebrew-localization

Conversation

@codesbygom

Copy link
Copy Markdown

Summary

  • Strings.ar.resx and Strings.he.resx were both only 109/619 keys deep (~18%); the rest silently fell back to English at runtime. Translated the remaining 510 keys in each, following the terminology already established by the existing human-translated entries in those same files (e.g. Controller, Profile, Rumble, Trigger) to keep vocabulary consistent with what was already shipped.
  • Created Properties/Resources.ar.resx and Properties/Resources.he.resx from scratch (339 keys each) for the legacy Properties.Resources.* call sites used across ~15 files. Neither language had any coverage there before — same gap already fixed for Farsi in Add Farsi localization, RTL flow-direction sync, and fix language-pack save bug #110.
  • Registered both new Resources.*.resx files in the csproj (DependentUpon metadata), matching the existing language entries.

Follow-up to #110 (Farsi), done as a separate PR/branch per request.

Test plan

  • Build the WPF app and switch the language pack to Arabic, confirm previously-English panels (Settings, dialogs, status messages) now show Arabic text.
  • Repeat for Hebrew.
  • Spot-check a few RTL-sensitive strings (ones with embedded English terms/placeholders like *number*, {0}) render correctly.

arash added 6 commits September 16, 2026 13:21
Port Strings.fa.resx and the content-only FlowDirection sync
(App.xaml/App.xaml.cs, LanguagePackControl, UpdaterWindow,
WelcomeDialog) from the codesbygom DS4Windows fork.
Global.Save() was commented out in ChangeLanguagePack(), so a new
language selection only lived in memory: the "restart required"
prompt fired, but the saved config still had the old UseLang, so
the app came back up in the previous language every time.
Twelve panels (About, ControllerOverview, AudioHaptics, ViiperSetupPrompt/
Progress, MappingLiveInput, TriggerLab, SwipeProfilesEditor,
Switch2StickCalibration, LogMessageDisplay, StickCalibration,
TouchButtonUserControl) had zero WPFLocalizeExtension bindings, so their
text stayed English regardless of the selected language pack. Wired all of
them to {lex:Loc}/Properties.Resources, keeping license text, proper nouns,
usernames, URLs, and unit suffixes (ms, Hz) untranslated as appropriate.

Also:
- Added the 4 keys missing from Strings.fa.resx and translated 2 tooltips
  that were copied verbatim from English.
- Created Properties/Resources.fa.resx (the legacy resx family used by
  ~200 Properties.Resources.* call sites) and uncommented
  DS4WinWPF.Properties.Resources.Culture = ci; in SetUICulture, which was
  never actually switching that resource family's culture.
- Registered Strings.fa.resx and Resources.fa.resx in the csproj
  (DependentUpon metadata) to match the other language entries.
- Fixed a latent bug in TriggerLabControl's MakeMeter: the slider's
  internal property key ("Start"/"Wall"/"Force") was reused as the
  display label, so localizing the label would have silently broken
  meter updates. Split them into separate parameters.

Net: 170 new Strings.resx/Strings.fa.resx keys, 156 new
Properties/Resources.resx/Resources.fa.resx keys, all translated.
Both Strings.ar.resx and Strings.he.resx only had 109 of 619 keys
translated (the rest silently fell back to English). Translated the
remaining 510 keys in each, using the existing human-translated
entries in those same files as the terminology reference (Controller,
Profile, Rumble, Trigger, etc.) to keep vocabulary consistent with
what was already shipped.

Also created Properties/Resources.ar.resx and Resources.he.resx from
scratch (339 keys each) for the legacy Properties.Resources.* call
sites -- neither language had any coverage there before, same gap
fixed for Farsi in the previous commit. Registered both in the csproj.
Resources.resx was edited directly (not through Visual Studio's
designer), so the PublicResXFileCodeGenerator custom tool never ran
and Resources.Designer.cs still only exposed the pre-existing string
properties. Every Properties.Resources.* call site added for the
localization work failed with CS0117 as a result. Added the missing
156 properties by hand, matching the generator's existing pattern.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant