feat(edit-content): enhanced locale selector for content editing sidebar

[adrianjm-dotCMS]

Summary

Closes #35889

Adds a new dot-edit-content-sidebar-locales-selector component that replaces the existing locale list in the edit-content sidebar with an improved UX, gated behind FEATURE_FLAG_LOCALE_SELECTOR_V2.

Screen.Recording.2026-06-10.at.2.50.39.PM.mov

Two display modes

• Simple view (≤5 locales): groups locales into Translated / Pending sections with full-width selection highlight and a divider between sections
• Enhanced view (>5 locales): tabbed interface (All / Translated / Pending) with count indicators, live search with a clear button, and a sticky "Selected:" row always visible regardless of active tab

Additional features

• "Manage locales" link rendered only for users with locales portlet access (DotCurrentUserService.hasAccessToPortlet)
• p-button [link] for the manage locales action
• Feature flag registered in FeatureFlagName.java, exposed via ConfigurationResource, and seeded in dotmarketing-config.properties
• 8 i18n keys added to Language.properties
• 30 unit tests (loading, simple view, enhanced view, search, manage locales access)

Note: $isLocaleSelectorV2 in dot-edit-content-sidebar.component.ts is currently hardcoded to signal(true) for development. Before merging, it must be wired to the real feature flag via DotPropertiesService.

Test plan

• Open edit-content with a content type that has ≤5 languages — simple view renders Translated / Pending sections
• Open edit-content with a content type that has >5 languages — enhanced view with tabs and search renders
• Search filters locales by name and ISO code; clear button resets the list
• Switching tabs always keeps the sticky "Selected:" row visible
• Clicking a locale emits switchLocale and updates the form language
• "Manage locales" link is visible only when user has locales portlet access; clicking navigates to /locales
• Run unit tests: yarn nx test edit-content --testPathPattern=dot-edit-content-sidebar-locales-selector
• Disable feature flag → old dot-edit-content-sidebar-locales renders as before

🤖 Generated with Claude Code

[claude]

Claude finished @adrianjm-dotCMS's task in 4m 20s —— View job

---

PR Review: feat(edit-content): enhanced locale selector

• Gather context and read changed files
• Review component logic and template
• Review tests
• Review backend changes
• Post findings

---

Findings

1. Null bindings passed to required inputs — committed code doesn't match the author's response

The reviewer asked about null locale bindings during loading (oidacra's last comment). The author replied they'd use ?? ({} as DotLanguage) but the committed HTML at dot-edit-content-sidebar.component.html:97-98 still passes raw values:

[defaultLocale]="defaultLocale"
[currentLocale]="currentLocale"

Both defaultLocale and currentLocale come from @let declarations that can be null when isLoadingLocales() is true. The component's own @if ($isLoading()) guard prevents actual null dereference at runtime, but Angular strict template checking will flag this because input.required<DotLanguage>() is non-nullable. The ?? ({} as DotLanguage) fallback mentioned in the review reply was never applied. Fix this →

2. setLocaleSelectorTab uses inline union instead of the exported LocaleTab

ui.feature.ts:101:

setLocaleSelectorTab(tab: 'all' | 'translated' | 'pending'): void {

The reviewer asked for a LocaleTab export and the author replied it was done. LocaleTab is now exported from dot-edit-content.model.ts and used in the component, but ui.feature.ts still holds the inline union. If LocaleTab ever gains a new value, this method's signature will silently go out of sync. Fix this →

3. $canManageLocales fires a menu HTTP request on every component instantiation

dot-edit-content-sidebar-locales-selector.component.ts:67:

readonly $canManageLocales = toSignal(this.#currentUserService.isPortletInMenu('locales'), {
    initialValue: false
});

isPortletInMenu uses shareReplay(1) in the service, so the network call is only made once per service instance — this is fine if DotCurrentUserService is singleton-scoped. The service is @Injectable() without providedIn: 'root', which means it could be provided at a non-singleton level. If the sidebar section is destroyed and re-created within the same session, the cached observable is reused and the check is correct. Just verify that DotCurrentUserService is always provided at root or module scope in the places that consume this component; otherwise the cache would be fresh-fetched on re-create.

4. Simple view: two separate p-listbox instances, both bound to $currentLocale()

When the locale that's currently selected ($currentLocale()) is in the "Pending" group, the Translated p-listbox receives a model value whose id won't match any of its options. PrimeNG's dataKey="id" comparison will silently find no match, so neither listbox shows the item highlighted — which is correct. But conversely, clicking a locale in the Translated listbox will cause (ngModelChange) to emit on the Translated listbox and switchLocale to fire. The Pending listbox's ngModel doesn't change until $currentLocale input updates from outside. The two-listbox design works, but if a user's session is in an inconsistent state where $currentLocale is not in $locales() at all, neither list will highlight anything and no error is thrown — this is acceptable silent degradation.

5. Search query is component-local, activeTab is store state — asymmetry on navigation

If the user types a search string and then navigates away (destroying the component), the search is lost on return. The tab, however, is restored from the store. This is probably the desired behavior but is worth documenting as intentional, since a user might expect both to persist equally.

Backend changes look correct — flag registered in FeatureFlagName.java, exposed through ConfigurationResource, seeded to false in dotmarketing-config.properties. The flag being off-by-default is the right default for a feature-gated change.

---

Summary: Items 1 and 2 are the most concrete — they're follow-ups the author committed to in review replies but the code doesn't reflect. Items 3–5 are lower severity and may be acceptable as-is.