Language picker: localizedView permission filter is never applied (dead code)

[xIrusux]

Summary

The language-selection picker's localizedView permission filtering is dead code — it never actually restricts the offered languages.

Details

PermissionBasedLanguageSelectionControl → WithElementContext (assets/js/src/core/modules/element/components/language-selection/type/with-element-context.tsx) does:

const elementDraft = useElementDraft(...)
if ('permissions' in elementDraft) {
  const permissions = elementDraft.permissions ...
  // filter user.contentLanguages by permissions.localizedView
}

But useElementDraft (core/modules/element/hooks/use-element-draft.ts) returns { ...draft, element: draft.asset|dataObject|document, editorType, isLoading, isError } — permissions live under elementDraft.element.permissions (IElementDraft.permissions), not at the top level. So 'permissions' in elementDraft is always false, the filter branch never runs, and the control always offers all of the user's content languages regardless of the element's localizedView permission.

Impact

Anywhere PermissionBasedLanguageSelectionControl is used (grid column config, language comparison, etc.), languages the user has no localizedView permission for are still shown/selectable. This is a behaviour bug, not just cosmetic.

Suggested fix

Read elementDraft.element?.permissions?.localizedView (with the existing "default"/empty fallbacks). Because this changes the picker's behaviour across all element types, it should be done as its own change with QA against a user whose localizedView is narrower than their content languages — deliberately out of scope for the batch-edit multi-locale PR (#3899), which now uses user.contentLanguages directly (matching what the picker actually shows today).

Also noticed (separate, minor)

In the asset batch-edit modal (asset/listing/batch-actions/batch-edit-modal/batch-edit-modal.tsx), the error useEffect reads isFolderPatchError/folderPatchError but its dependency array is [isError, isFolderPatchSuccess], so a folder-patch failure may not be reported. Pre-existing; worth a small dependency-array fix.

[xIrusux]

What localizedView should do

localizedView is a per-workspace user permission (a comma-separated list of language codes, e.g. en,de) that controls which localized languages a user may view for elements in that workspace. The language picker (PermissionBasedLanguageSelectionControl) should therefore only offer the intersection of the user's content languages and the workspace's localizedView languages.

Intended behaviour (matches the original inline logic that never ran):

• localizedView set to specific languages → offer only those (∩ the user's content languages).
• localizedView empty or just default → no restriction; offer all of the user's content languages.

(Editing should additionally respect localizedEdit; this issue is only about the view/selection filter.)

Why this surfaced / why the batch-edit PR did not rely on it

While building the multi-locale batch edit (#3899) we added a hook so batch-edit would offer the same permission-filtered set as the picker — the goal being to never auto-add a language the user can't view/edit. We then found the filter above is effectively switched off: because permissions lives under elementDraft.element (not the top level), the localizedView branch never executes and the picker just returns all content languages.

Analogy: we built a bridge to plug into that filter, then discovered the filter was unplugged — with it off, the bridge just leads back to where we already were. So #3899 was reverted to use user.contentLanguages directly (identical real behaviour today), and this issue tracks fixing the filter's wiring on its own, since correcting it changes the picker's behaviour app-wide (all element types) and needs its own QA — e.g. a user whose localizedView is narrower than their content languages should then see a reduced language list. Once fixed here, batch-edit can adopt the permitted set for real.