No public API to get UI culture info

Problem: Need to support different languages (Russian, English and German) in a work item control extension.

There is no public API to get locale that configured in user profile.
Old VSS SDK had API for this info:

var culture = TFS.uiCulture.toLowerCase();

New SDK does not have public methods to get configured work item form UI culture info.

In azure-devops-ui there is a function to get current culture

import { getCurrentCulture } from "azure-devops-ui/Core/Util/Culture"

defined as

/**
 * Get culture settings for the current user's preferred culture
 */
export declare function getCurrentCulture(): ICultureInfo;

...but it just doesn't work and always returns invariant culture (en-US) regardless of configured UI culture.
Because if we look at JS code for this function, we see..

var currentCulture;
/**
 * Get culture settings for the current user's preferred culture
 */
export function getCurrentCulture() {
    if (!currentCulture) {
        currentCulture = getInvariantCulture();
    }
    return currentCulture;
}

...and module variable currentCulture is nowhere and never initialized, so function getCurrentCulture always returns invariant culture info.

So to solve business problem, I forced to resort to dirty hacks such as patching SDK script to retrieve configured culture from previously private "handshake info" provided to SDK.init function internally.

/*
* Dirty hack here! 
* SDK.getPageContext() isn't available, but a function injected in SDK module JavaScript source, and then patched 
* SDK module aliased in webpack pretending to be original azure-devops-extension-sdk module
*/
function getLocale(): string {
    return SDK.getPageContext()?.globalization?.culture;
}

Such dirty hacks for solving ordinary problems is not what we would like to have from the new SDK.

Start by reviewing azure-devops-ui/Core/Util/Culture and its getCurrentCulture implementation, then compare it with the azure-devops-extension-sdk SDK.init and getPageContext references in the issue. The work is complete when extensions have a supported public API that returns the configured UI culture instead of invariant en-US.