Add 15 new locales to Android resource and build config

[JorgeMucientes]

Summary

Adds the 15 new Android locale declarations to the app build/resource configuration:

• resConfigs in WooCommerce/build.gradle
• WooCommerce/src/main/res/xml/locales_config.xml
• WooCommerce/src/main/res/values/available_languages.xml

This PR only makes the locales available to Android. It does not add generated app-string resources, the AI translation engine, CI wiring, or Play Store metadata.

Follow-up review fix included:

• Locale declarations are sorted consistently across resConfigs, available_languages.xml, and locales_config.xml, keeping English first.

Current Stack

Open PRs in the current stack:

1. Add 15 new locales to Android resource and build config #15961 - declare the 15 new Android locales.
2. Add self-contained AI translation engine (GlotPress replacement) #15962 - add the GlotPress-independent AI translation engine, Fastlane lanes, Buildkite wiring, release-sweep/hotfix hooks, metadata engine, docs, and rollout controls.
3. Seed manifest + sidecar baseline for the 16 existing locales #15974 - seed sidecar baseline files and manifest records for the 16 existing human-translated locales.
4. Backfill Play Store metadata for the 15 new locales #15983 - backfill Play Store listing metadata for the 15 new locales.
5. Backfill 15 new locales via Claude Sonnet subagents #16004 - backfill Android app-string resources for the 15 new locales.
6. Add PR-time AI translation pipeline fixture #16011 - draft PR-time AI translation pipeline fixture.

The locale declarations in this PR should ship together with the app-string backfill in #16004 so the newly selectable app languages do not fall back mostly to English.

Test Plan

• Confirmed this PR only changes Android locale/build config.
• Confirmed all new locales appear consistently in resConfigs, locales_config.xml, and available_languages.xml.
• Parsed available_languages.xml and locales_config.xml with REXML.
• Restacked the open child branches after the review-fix commits.

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce Android by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce Android
	Platform	📱 Mobile
	Flavor	Jalapeno
	Build Type	Debug
	Build Number	750
	Version	24.8-rc-1
	Application ID	com.woocommerce.android.prealpha
	Commit	d3ee046
	Installation URL	1q9a0lcco7mk8

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[JorgeMucientes]

Addressed both Danger errors: added status: feature-flagged, type: enhancement, and category: tooling labels to all six stacked PRs (#15961–#15966). status: feature-flagged makes the milestone check non-blocking, which is appropriate here: the AI translation pipeline is dormant until the API key is wired in CI and the PR-time check is flipped from soft_fail to required (see #15964 / #15965). Re-running Danger via the label-change event.

[toupper]

Thanks for the careful staging here — splitting the locale declaration off from the translation engine, sidecar baseline, and Play Store metadata into its own atomic PR is the right move and made this very easy to verify.

I checked the three changed files against the localeConfig registered in AndroidManifest.xml, the existing LocaleProvider, the Fastfile's SUPPORTED_LOCALES, and the wear app's build config. Nothing here looks like a blocker.

Suggestions

• WooCommerce/src/main/res/values/available_languages.xml — The new entries are appended to the end of the array (bg, cs, … vi) rather than alphabetized with the existing ones. The legacy block keeps en_US pinned first and then runs alphabetically from ar to zh_TW. Two minor consequences: (a) anything that consumes this array in display order would now show the new locales grouped at the bottom rather than interleaved, and (b) future maintainers diffing this list will have a harder time spotting duplicates. I couldn't find a Kotlin consumer for R.array.available_languages anywhere in WooCommerce/src/main/kotlin/, so this seems to be informational only (the actual system language picker is driven by xml/locales_config.xml). If that's correct, the ordering is a stylistic nit; if the array is consumed downstream by the translation engine in #15962, it might be worth interleaving alphabetically to keep diffs clean. Same observation applies to the ordering chosen in resConfigs and locales_config.xml, though those are clearly machine-consumed and order doesn't matter functionally.

• fastlane/Fastfile — SUPPORTED_LOCALES (line 101) still lists only the 16 existing locales. I see from the PR description that GlotPress / metadata wiring is intentionally split into #15962 and #15983, so this is expected — flagging only so we don't forget that without those follow-ups, Android resources will know about the 15 new locales but no Fastlane lane (e.g. download_translations, screenshots) will. A short comment in the Fastfile pointing to the follow-up PRs could help, but it's optional.

• No values-xx/ directories yet for the new locales — confirmed intentional per the PR description (translation backfill comes via #16004). The runtime effect today: if a user picks e.g. Polish from the system language picker, the app will render English strings because Android resource fallback kicks in. That's fine for an interim state, but worth being aware of in case this PR ships ahead of #16004. Consider holding the rollout (or guarding the new entries) until the backfilled strings.xml files land so users don't end up with a "Polish" selection that produces English text.

Positives

• Single-purpose PR with a tight diff (32 LOC across 3 files) — easy to reason about and easy to revert if needed.
• The three files stay in lockstep: every new locale appears in resConfigs, locales_config.xml, and available_languages.xml. I cross-checked the 15 new codes in all three and they match.
• Android-format codes are correct throughout: pt-rBR / pt-rPT use the -r region prefix for resConfigs (Gradle/AAPT format) while locales_config.xml uses pt-BR / pt-PT (BCP 47), which is exactly how Android wants those two files to differ. Same for zh-rCN / zh-CN.
• nb (Norwegian Bokmål) chosen over no — correct, since no is ambiguous between Bokmål and Nynorsk and Android prefers the specific variant.
• supportsRtl="true" is already set in AndroidManifest.xml, so no extra RTL wiring is needed (none of the 15 new locales are RTL anyway — Arabic and Hebrew were already in place).
• Comments next to each locale entry in locales_config.xml make the file self-documenting.

Reviewed on behalf of @toupper — drafted by Claude Code, please confirm before merging.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 41.98%. Comparing base (50168ff) to head (d3ee046).
⚠️ Report is 169 commits behind head on trunk.

Additional details and impacted files

@@            Coverage Diff            @@
##              trunk   #15961   +/-   ##
=========================================
  Coverage     41.98%   41.98%           
  Complexity    13529    13529           
=========================================
  Files          2512     2512           
  Lines        145990   145990           
  Branches      21152    21152           
=========================================
+ Hits          61297    61298    +1     
  Misses        78448    78448           
+ Partials       6245     6244    -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[JorgeMucientes]

Thanks @toupper. I pushed a small follow-up for the locale ordering feedback.

Changed:

• Sorted the Android locale declarations in resConfigs, available_languages.xml, and locales_config.xml, keeping English first.

Not changed:

• I did not add the Fastlane/metadata wiring in this PR because that belongs to the follow-up PRs in the stack.
• I also did not add a runtime gate here; the stack should be merged/released together with the string backfill so users do not get mostly-English fallback for the new languages.

[wpmobilebot]

Version 25.0 has now entered code-freeze, so the milestone of this PR has been updated to 25.1.

[wpmobilebot]

Version 25.1 has now entered code-freeze, so the milestone of this PR has been updated to 25.2.

[wpmobilebot]

Version 25.2 has now entered code-freeze, so the milestone of this PR has been updated to 25.3.

[wpmobilebot]

Version 25.3 has now entered code-freeze, so the milestone of this PR has been updated to 25.4.

[wpmobilebot]

Version 25.4 has now entered code-freeze, so the milestone of this PR has been updated to 25.5.