Internationalization - Tool Palette

[jmenzies12]

Hey there,

We are in the process of internationalizing our application and are using nls (l10n) for all of the commands and menus contributed to vscode.

For the Tool Palette, I was wondering if it was possible to get to the values without extending the whole Tool Palette? If there is something I can do that would work for everyone I would happily contribute it.

Cheers
Jonathan

[tortmayr]

@martin-fleck-at Could you please have a look at this. (Since you were already working on i18n for GLSP previously)

[martin-fleck-at]

@jmenzies12 In the latest version (2.4.0+) we actually introduced a very simple approach to support i10n a little bit better. As a framework, we did not really want to force any particular package on the users but all messages have been factored out into a messages object¹. This object comes with two utility functions:

• updateMessages: To customize the messages stored in the object. Here, you can use your custom framework as values for the specified keys.
• onMessagesUpdated and repeatOnMessagesUpdated to execute some behavior every time messages get changed. This is the hook where you re-render the UI that needs to be updated. We do that, for instance, for the tool palette here ².

So if you are already on the latest version, simply calling updateMessages and overwriting the values with whatever nls-mechanism you use should work fine.

Footnotes

1. https://github.com/eclipse-glsp/glsp-client/pull/421 ↩

2. https://github.com/eclipse-glsp/glsp-client/blob/1f968181b21906fd80b103ac845f6245e8f95de2/packages/client/src/features/tool-palette/tool-palette.ts#L111-L117 ↩

[jmenzies12]

Hey @martin-fleck-at,

Okay great, that makes sense.

Only question I have:
Is there somewhere I can hook into when the client initializes? I need to send the l10n bundle path from the vscode extension to the client in order to config l10n. I tried setting up a new action and handler in the client and then triggering it from the editor provider, however it seems that the client is not fully initialized with it's action handlers at this point so the message is not sent.

[martin-fleck-at]

It shouldn't matter when you update the messages since we do have listeners and re-create the affected UI if the messages change. So if it doesn't happen super early on, I think everything should still get translated properly.

Unfortunately, there is currently no reliable way to defer action dispatching from the extension side until the diagram has been initialized (cf #1513). What you could try to do as a workaround for now is to wait for the client to be ready and then send the action with a timeout. So something like:

client.webviewEndpoint.ready.then(() => {
   // Use timeout since we cannot make sure that the diagram is already initialized before sending an action
   // https://github.com/eclipse-glsp/glsp/issues/1513
   setTimeout(() => client.webviewEndpoint.sendMessage({ clientId: client.clientId, action: [...] }), 500);
});

Then again, I don't think the diagram needs to be fully initialized for the messages to be updated since we are just replacing constants. You could probably just send a regular message through the messenger API without going through the GLSP action mechanism.

[jmenzies12]

Thanks @martin-fleck-at, that got me over the last hurdle.