My proposal is to expose the l10n API in the context parameter passed to the notebook renderer:

// Only showing new fields
export function activate(ctx: {
    l10n: {
        language: string, // For example, en-us

       t(...) => string, // Localize function. Matches what we have in VSCode api


       bundle: { ... } // Complete string bundle. Matches what we have in VSCode api
    }
})

@TylerLeonhardt was also interested in seeing if we could make l10n work more like it does for VS Code extensions. Passing around the context everywhere could be annoying, so I considered two approaches to this. However I am not sure either one can be implemented:

Fake imports: import { l10n } from 'vscode';

On web, I don't think it's possible to express this. Imports need to resolve to a resource that actually exists
Globals: vscode.l10n.t(...)

Because notebook renderers run as modules, this is not easy to do. We'd need a "global" variable that is scoped just to the current module. Either that or the global api has to take the notebook render id as a argument so that it knows which extension's strings it should return

Enable localization of notebook renderers #170919

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions