BKY message references not expanded in ContinuousToolbox

81 views
Skip to first unread message

Takuto N

unread,
Sep 8, 2025, 11:28:53 AM (7 days ago) Sep 8
to Blockly

Hi,

I'm using @blockly/continuous-toolbox.
When I try to localize category names in the toolbox by setting

kind: "category",
name: "%{BKY_CATEGORY_AAAA}"

I notice that in the ContinuousFlyout, the %{BKY_...} references are replaced correctly.
However, in the ContinuousToolbox, the string is shown literally as "%{BKY_CATEGORY_AAAA}" instead of being localized.

Is this expected behavior, or should ContinuousToolbox also process %{BKY_...} message references like the standard toolbox does?

Thanks!

スクリーンショット 2025-09-09 0.21.58.png

Aaron Dodson

unread,
Sep 8, 2025, 12:47:55 PM (7 days ago) Sep 8
to Blockly
Hi,

It should, and experimentally for me it seems that it does, so this is quite odd. The conversion from message reference to text is done in ToolboxCategory.parseCategoryDef_(), and the converted value gets stored in ToolboxCategory.name_. Note that, for the continuous toolbox, this would be ContinuousCategory vs ToolboxCategory, but that's just a pretty minimal subclass that defers to the superclass' implementation of this. Is your code public? I'd be happy to take a look if so, but if not, I'd suggest inspecting the name_ field of the toolbox categories, or perhaps registering a subclass of ContinuousCategory that overrides parseCategoryDef_() to ensure it is being called. This is all the more curious because the labels in the flyout are actually derived from the name of the category!

- Aaron

Takuto N

unread,
Sep 8, 2025, 6:50:28 PM (6 days ago) Sep 8
to Blockly

Hi Aaron,

Thanks for your reply! Yes, my code is public. Here is the repository:
👉 https://github.com/surahotoke/scratch-regex-editor

The related code for language switching is in ui.js lines 28–51.
What I’m seeing is that the %{BKY_...} replacement works fine in the ContinuousFlyout, but in the ContinuousToolbox the category names still appear literally as %{BKY_CATEGORY_XXXX}.

Could you please take a look when you have a chance?
Thanks again for your help!

Best regards,
Takuto N (surahotoke)


2025年9月9日火曜日 1:47:55 UTC+9 ado...@google.com:
Message has been deleted

fu6...@gmail.com

unread,
Sep 9, 2025, 10:00:15 AM (6 days ago) Sep 9
to Blockly
Hi , 

function updateBlocklyStrings(locale) {
  Object.assign(Blockly.Msg, locale)
  workspace.updateToolbox(toolbox);

  // 再描画
  const state = Blockly.serialization.workspaces.save(workspace)
  Blockly.serialization.workspaces.load(state, workspace)
}

Hope this helps and you can solve your problem.

fu6...

takut...@gmail.com 在 2025年9月9日 星期二清晨6:50:28 [UTC+8] 的信中寫道:

Takuto N

unread,
Sep 9, 2025, 10:46:25 AM (6 days ago) Sep 9
to Blockly

Thank you so much!
I tried your suggestion with workspace.updateToolbox(toolbox); and now it works perfectly. 🎉
I really appreciate your help!

Best regards,
Takuto N (surahotoke)


2025年9月9日火曜日 23:00:15 UTC+9 fu6...@gmail.com:

Takuto N

unread,
Sep 10, 2025, 12:32:30 PM (5 days ago) Sep 10
to Blockly

Hi Aaron / Blockly team,

I ran into a new issue related to localization. I added BKY message references to block TOOLTIPs for Japanese.

In the ContinuousFlyout, %{BKY_...} is displayed literally and not replaced for some tooltips.

Interestingly, some blocks (like the (?<name>{}) block) display the localized text correctly.

Dragging a block from the flyout to the workspace shows the correct tooltip.

Mutator blocks seem unaffected.

From my research, this seems related to:
https://github.com/google/blockly/issues/1964
https://github.com/google/blockly/issues/1964#issuecomment-401861394

Following the first suggested workaround appears to potentially resolve the issue, but I’m puzzled why some tooltips are localized correctly while others are not.

Do you know of a better approach to ensure all block tooltips get updated when changing language?

Thanks for your help!



Best regards,
Takuto N (surahotoke)

2025年9月9日火曜日 23:46:25 UTC+9 Takuto N:

Aaron Dodson

unread,
Sep 10, 2025, 2:37:36 PM (4 days ago) Sep 10
to Blockly
Hi Takuto,

The specific behavior you're observing is likely because the ContinuousFlyout "recycles" certain blocks for performance reasons; that is, for certain blocks, it doesn't reinstantiate them when updating its contents, but instead stashes them offscreen and reuses them later. Mutator blocks are exempt from this, hence they display the updated tooltips, and dragging a block to the workspace creates a new copy, hence the updated tooltip there. But blocks that are recycled in the flyout persist from before the language change. In general, as the bug notes, Blockly doesn't support dynamically changing the language. You don't need to go quite as far as reloading the page (disposing of the workspace and calling inject() again should be sufficient), but broadly speaking without a reinjection I wouldn't expect localizations to propagate everywhere. You might be able to work around this specific issue by calling ContinuousFlyout.setRecyclingEnabled(false), but I'd recommend just disposing and reinjecting.

- Aaron

Takuto N

unread,
Sep 10, 2025, 3:43:06 PM (4 days ago) Sep 10
to Blockly
Hi Aaron,

Thank you so much for the clear explanation!  
Your note about block recycling in the ContinuousFlyout makes perfect sense.  

I tried your suggestion and was able to get it working.  
In my case, I found that in addition to calling `workspace.dispose()`, I also needed to call `Blockly.Workspace.getAll()[1].dispose()`. With that adjustment, reinjecting now works perfectly! 🎉  

I really appreciate your help and guidance.  


Best regards,  
Takuto N (surahotoke)
2025年9月11日木曜日 3:37:36 UTC+9 ado...@google.com:
Reply all
Reply to author
Forward
0 new messages