feat: add Device localization support

[benjam-es]

Summary

• Add localization() method to Device returning an immutable Localization value object
• Exposes locale, language code, region code, timezone, currency code, and preferred language via the Device.GetLocale bridge function
• Add Localization data object under Native\Mobile\Data namespace
• Update Device facade docblock

[benjam-es]

Linked PR: NativePHP/mobile-device#1

[benjam-es]

Working example

[benjam-es]

This adds build-time locale support to go alongside the Device::localization() method from the previous commit.

What it does:

On iOS, if your app doesn't declare CFBundleLocalizations in Info.plist, the system scopes Locale.current to just the bundle's development region — so even if the user's phone is set to French, your app sees English. This fixes that by injecting the localizations array into both Info.plist files during the build.

On Android, Locale.getDefault() already works fine regardless, but Android 13+ has a per-app language picker in system settings that only shows up if the app ships a locales_config.xml. This generates that file and wires it into the manifest.

How to use it:

Add the locales your app supports to config/nativephp.php:

'locales' => ['en', 'fr', 'es', 'de'],

If the array has fewer than two entries (or is empty), nothing happens — it's fully opt-in and a single locale is a no-op on both platforms.

What changed:

• config/nativephp.php — new locales key
• BuildIosAppCommand — updateLocalizationConfig() injects CFBundleLocalizations into plists
• PreparesBuild — updateLocalizationConfiguration() generates locales_config.xml and updates the manifest
• tests/Unit/LocalizationConfigTest.php — 6 tests covering injection, replacement, skip behaviour, cleanup, and idempotency
• tests/Concerns/MocksPreparesBuildDependencies.php — extracted the shared trait stubs that were duplicated across test files

[simonhamp]

Wouldn't intl support in PHP take care of this more cleanly?

[benjam-es]

@simonhamp Tested this — without CFBundleLocalizations, the app always returned English regardless of device language. iOS scopes the locale at the process level to the bundle's development region, so intl would hit the same wall since it reads from the same OS source.

The build-time config tells iOS "this app supports these languages" which unblocks correct locale reporting for everything inside the app. Without it, the App Store listing also only shows the development region language, and the app won't appear in the iOS 16+ per-app language settings.

On Android, Locale.getDefault() works without it, but locales_config.xml enables the per-app language picker on 13+.

intl is useful for formatting once you have the locale, but the native config is needed upstream so the OS actually reports the right one.

[benjam-es]

Also worth noting — as we lean more into native UI elements (Edge components, native navigation, etc.), the app needs to be locale-aware at the native layer, not just in PHP. Having the device report the correct locale is foundational for that.

[simonhamp]

I'm not sure that's a fair test yet. We don't have intl support in iOS currently

I do agree that having it at the native layer does also make sense