Arguably that is not the purpose of the global variable. Hook onLanguageGetTranslatedLanguageNames can be used for providing translated language names.

The CLDR extension already provides two mechanisms for overriding translated language names:

1. LocalNames/ PHP files — per-language overrides that take precedence over CLDR data (requires code deploy)
2.  onLanguageGetTranslatedLanguageNames  hook — programmatic overrides at runtime

The gap identified here is ease of configuration — neither approach is accessible to wiki admins without PHP access.

Proposed solution (within the CLDR extension, no core changes needed):

A new config variable  $wgExtraTranslatedLanguageNames  that the CLDR extension reads in its hook handler. Shape:

$wgExtraTranslatedLanguageNames = [
    'fr' => [
        'als' => 'alémanique',
        'gsw' => 'alémanique',
    ],
    'en' => [
        'als' => 'Alemannic',
    ],
];

This would be checked in  LanguageNames::loadLanguage()  (or in the  Hooks  class), taking precedence over both CLDR data and LocalNames/ files.

Questions before implementation:

1. Is this the right shape for the config? (Outer key = UI language, inner key = language code being named, value = display name.)
2. Should it take precedence over LocalNames/ overrides, or sit between CLDR data and LocalNames/?
3. Is there a concrete deployment where this would be used? The  als  vs  gsw  inconsistency mentioned in the description would be a good test case.
4. An alternative approach using system messages (e.g.,  MediaWiki:Cldr-language-name-gsw/fr) is also possible via the existing i18n message system, but would require the CLDR extension to check for message overrides at runtime, which has performance implications.

An alternative approach using system messages (e.g.,  MediaWiki:Cldr-language-name-gsw/fr) is also possible via the existing i18n message system, but would require the CLDR extension to check for message overrides at runtime, which has performance implications.

See also: T231755#11884157