I have made an extension to Tiptap. It opens a modal and I can do stuff in the modal. So far so good.
How do I get the current variants culture? In a workspace view I would get UMB_CONTENT_WORKSPACE_CONTEXT and find the active variant. It doesn’t seem that context is available in my modal, so now what?
And how is someone supposed to know this stuff? 
/Rune
Use your browser devtools and inspect the DOM and try to get as close as you can to your extension and update the HTML to include this
<umb-debug visible dialog></umb-debug>
It will then give you a dialog you can open to then see the list of available contexts from that DOM position.
Think this issue might be related to the one I am battling with:
Fantastic. That explained a lot of things in one swoop. Doing that revealed that I have access to a UMB_VARIANT_CONTEXT which gives access to some information about culture. It does seem either buggy or inadequate. I will extend my question in another comment.
Ok. So with @warren s help I found the UMB_VARIANT_CONTEXT which gives access to four ways of getting the culture. Now the problem is, that none of them seems to give me the correct culture when in split view.
getAppCulture() ← Gives the general culture, chosen in the upper right corner.
getDisplayCulture() ← Gives the general culture, chosen in the upper right corner.
getCulture() ← Is just null
getFallbackCulture() ← Not sure. Maybe the Default culture. Never changes.
Shouldn’t one of them give me the actual culture from the split view i opened the Tiptap editor in?
You can get the variants of the content via the UMB_DOCUMENT_WORKSPACE_CONTEXT if you look in the splitView property.
e.g this will find it.
this.consumeContext(UMB_DOCUMENT_WORKSPACE_CONTEXT, async (workspaceContext) => {
if (!workspaceContext) return;
this.observe(workspaceContext.splitView.activeVariantsInfo, (_variants) => {
_variants.forEach((variant) => {
console.log('variant', variant);
});
});
});
If the user is in split view you get more than one activeVaiant.
this doesn’t return anything when there are no variants.
That work very well on my Worspace View. On my TipTap extension though, I don’t have access to the UMB_DOCUMENT_WORKSPACE_CONTEXT for some reason. 
Seems like it’s somehow disconnected from the Workspace. Here’s the list of what I have actually access to:
UmbModalContext
UmbViewContext
UmbHintContext
UmbShortcutContext
UmbAuthContext
UmbServerContext
UmbNotificationContext
UmbModalManagerContext
UmbActionEventContext
UmbInteractionMemoryContext
UmbSectionSidebarMenuGlobalContext
UmbPropertyEditorDataSourceItemStore
UmbTemporaryFileConfigStore
UmbIconRegistryContext
umbThemeContext
UmbAppLanguageContext
UmbVariantContext
UmbUfmContext
UmbLanguageDetailStore
UmbLanguageItemStore
UmbDataTypeDetailStore
UmbDataTypeTreeStore
UmbDataTypeItemStore
UmbDataTypeFolderStore
UmbWebhookDetailStore
UmbWebhookItemStore
UmbDictionaryTreeStore
UmbManagementApiServerEventContext
UMB_TAG_STORE
UmbCurrentUserHistoryStore
UmbPackageStore
UmbStaticFileItemStore
UmbWebhookEventStore
UmbCurrentUserContext
UmbCurrentUserConfigStore
UmbTemplateDetailStore
UmbTemplateItemStore
UmbScriptItemStore
UmbUserDetailStore
UmbUserItemStore
UmbDictionaryItemStore
UmbUserConfigStore
UmbDictionaryDetailStore
UmbRelationTypeDetailStore
UmbCurrentUserStore
UmbUserGroupDetailStore
UmbUserGroupItemStore
UmbTemplateTreeStore
UmbStylesheetTreeStore
UmbStylesheetFolderStore
UmbScriptDetailStore
UmbScriptTreeStore
UmbScriptFolderStore
UmbStaticFileTreeStore
UmbClipboardEntryDetailStore
UmbClipboardEntryItemStore
UmbDocumentBlueprintDetailStore
UmbDocumentBlueprintItemStore
UmbDocumentBlueprintTreeStore
UmbDocumentBlueprintFolderStore
UmbDocumentConfigurationContext
UmbDocumentItemStore
UmbDocumentRecycleBinTreeStore
UmbDocumentDetailStore
UmbDocumentTreeStore
UmbDocumentUrlStore
UmbDocumentTypeDetailStore
UmbDocumentTypeItemStore
UmbDocumentTypeTreeStore
UmbDocumentTypeFolderStore
UmbClipboardContext
UmbPartialViewDetailStore
UmbPartialViewItemStore
UmbPartialViewTreeStore
UmbPartialViewFolderStore
UmbStylesheetDetailStore
UmbStylesheetItemStore
UmbImagingStore
UmbMemberGroupDetailStore
UmbMemberGroupItemStore
UmbMemberTypeDetailStore
UmbMemberTypeItemStore
UmbMediaRecycleBinTreeStore
UmbMediaDetailStore
UmbMediaItemStore
UmbMediaTreeStore
UmbMediaUrlStore
UmbMediaTypeDetailStore
UmbMediaTypeItemStore
UmbMediaTypeTreeStore
UmbMediaTypeFolderStore
UmbMemberTypeTreeStore
UmbMemberItemStore
UmbMemberDetailStore
Yes, sorry i missed that 
.
Looking into the code (and maybe someone from the core can tell shed some light on it). the document variant never leaves that context 
the whole thing is managed by the UmbWorkspaceSplitViewManager and you can’t just new it up and find the context (i tried) .
it looks like the document context adds the variants in as part of it’s process - so they are not then shared beyond,
you can “hack” it with the route context, but from your list it looks like you don’t have that either
splitViews = new UmbWorkspaceSplitViewManager();
this.consumeContext(UMB_ROUTE_CONTEXT, (routeContext) => {
this.observe(routeContext?.activeLocalPath, (path) => {
this.splitViews.setVariantParts(path ?? '')
// read it back out, you would save it somewhere.
this.splitViews.getActiveVariants().forEach((variant) => {
console.log('variant', variant);
});
});
});
it looks like its all driven from the URL and if you can’t get to the route / url context then other than actually reaching in and getting the url from the browser i am not sure if you can do it just with contexts (and all of this would be super hacky). doesn’t observe, the url, so if the user changes there view it doesn’t reload.
// the super hack, really not the way to do it.
var end = document.URL.split('/').pop();
this.splitViews.setVariantParts(end ?? '');
this.splitViews.getActiveVariants().forEach((variant) => {
console.log('window url ariant', variant);
});
It starts to look more and more like a bug or missing feature in Umbraco. I will create an issue and see where it goes from there. I will get back with a link to the issue.
Thanks for all the help so far 
I have created a bug with this issue: