fix(ios): match alert labels through the OS prompt strings of the preferred languages

Merged
KA
15h ago
+237-33

Summary

Since #3715, the iOS XCUITest runner taps only listed English labels. On a Japanese simulator, alert dismiss on the notification prompt 許可しない / 許可 fails with ALERT_BUTTON_NOT_FOUND.

The runner now reads the OS's own notification, privacy (including ATT), and location prompt strings once at startup. It pairs each English value with the same key in every preferred language. A localized label then matches through the English labels it translates. These are Apple's own translations, not guesses (#3627):

  • a source must be a whole button label;
  • a translation that reads as an English label keeps its English meaning;
  • a translation claimed by both actions stays unknown;
  • unreadable tables leave the English vocabulary in place.

#3922's localized launch confirmation (Ouvrir) stays uncovered: its strings are not read.

8 files. Scope: iOS simulators; physical iOS, tvOS, and visionOS keep English labels. Limrun iOS stays English-only: tree capture cannot read device string tables.

Validation

Head f6cfbb215 (base b396bd009), tree-identical to checked d28809ed8.

  • check:affected --run --head d28809ed8 (run-N8cSYR, exactCommit=true): all pass except help-conformance-sample-outputs (4, identical on base) and 4 host-load timeouts (7/7 on rerun).
  • Runner XCTest: 15 alert tests pass; macOS and device runners build.
  • Live ja-JP/en-US evidence:
    • notification dismiss → denied;
    • location accept → authorizedWhenInUse;
    • ATT dismiss → TCC auth_value=0;
    • an unknown lone button refuses with dispatched: no.

Risks: the string-table locations are undocumented and may move. If any table fails to read, matching degrades to English-only refusal and logs AGENT_DEVICE_RUNNER_ALERT_VOCABULARY_UNAVAILABLE.