feat: add en-XE (cross-Europe English) and es-XA (cross-Latin America Spanish) surfaces

[mmiermans]

Goal

Add scheduled surfaces for cross-Europe English (en_XE → NEW_TAB_EN_XE) and cross-Latin America Spanish (es_XA → NEW_TAB_ES_XA) to the curation tool, so curators can manage ML sections for these two new markets.

Companion to Pocket/content-monorepo#397 (backend) and mozilla/content-ml-services#1243 (ML pipeline). Timezones mirror the backend: en-XE → Europe/London, es-XA → Europe/Madrid.

Follows the pattern of #1274 (de-AT / de-CH / pl-PL / fr-BE).

Changes

• helpers/definitions.ts: add both guids to the readable-name ScheduledSurfaces list.
• integration-test-mocks/getScheduledSurfacesForUser.ts: add both surfaces to the mock.
• ScheduleItemFormConnector.test.tsx: include both new guids in the surface-count assertion.

No language-picker change is needed — getLocaleForScheduledSurface infers the locale directly from the guid (NEW_TAB_EN_XE → en-XE, NEW_TAB_ES_XA → es-XA), and EN/ES already exist.

Deployment steps

• Requires the companion backend PR (content-monorepo#397) and the Mozilla Access Groups mozilliansorg_pocket_new_tab_curator_enxe / _esxa to be created, or curators will get a 403.

QA

1. Log in with a user in the new access groups (or full-curator access).
2. Confirm New Tab (EN Europe) and New Tab (ES Global) appear in the scheduled-surface picker and that sections/scheduling load for each.

[claude]

Claude finished @mmiermans's task in 1m 23s —— View job

---

Code Review

Reviewed the diff against origin/main. The mechanics are correct — inferLocaleFromGuid (helperFunctions.ts:172) parses NEW_TAB_EN_XE → en-XE and NEW_TAB_ES_XA → es-XA from the last two GUID segments, so no language-picker change is needed as noted. The test count assertion and mock are updated consistently. Two things worth addressing before merge:

• Read PR diff
• Analyze definitions & locale inference
• Check timezone/naming consistency
• Post review

---

1. Display names break the established naming convention (and contradict the PR description) — helpers/definitions.ts:89,94

Every other entry in ScheduledSurfaces uses the New Tab (xx-YY) locale-code format:

{ guid: 'NEW_TAB_EN_IE', name: 'New Tab (en-IE)' },
{ guid: 'NEW_TAB_EN_XE', name: 'New Tab (EN Europe)' },   // ← inconsistent
...
{ guid: 'NEW_TAB_ES_ES', name: 'New Tab (es-ES)' },
{ guid: 'NEW_TAB_ES_XA', name: 'New Tab (ES Global)' },   // ← inconsistent

These two use free-text labels instead. This also contradicts the PR description's QA step, which says curators should see "New Tab (en-XE)" and "New Tab (es-XA)" in the picker, and diverges from the pattern set by #1274 (de-AT / de-CH / etc.). Recommend New Tab (en-XE) and New Tab (es-XA) for consistency — and update the matching name fields in the mock (getScheduledSurfacesForUser.ts:90,96) too, so mock and definitions agree.

Fix this →

2. Mock timezones don't match the PR description — integration-test-mocks/getScheduledSurfacesForUser.ts:88,94

The PR body states timezones mirror the backend: en-XE → Europe/London, es-XA → Europe/Madrid. The mock uses different values:

{ ... guid: 'NEW_TAB_EN_XE', ianaTimezone: 'Europe/Berlin', ... },      // expected Europe/London
{ ... guid: 'NEW_TAB_ES_XA', ianaTimezone: 'America/Mexico_City', ... }, // expected Europe/Madrid

This is only a test mock, so there's no production impact and no test currently asserts on these values — but it's worth aligning with the real backend config to avoid confusing future readers (the es-XA case is a whole different continent). Low priority; your call on whether to fix now.

---

Nothing else stands out — the change is small and otherwise correct. LGTM once (1) is addressed.