Global variable translations bug

This is a Korean translation issue, not Japanese, but
relevant to translation methodology, so I will hang it here …

This Korean .aia arrives with broken global variable names:

I am awaiting a reply from the Original Poster if he broke the names or not.

I have come up with a hypothesis as to how translated apps can be broken …

There are at least two pathways for blocks to move from project to project:

  • Through the BackPack, and
  • By Blocks Editor Drag and Drop from downloaded block .PNG files

If blocks do not contain internal (or in .Png file) identification of their language code,
how can the language translation facility know how to represent/identify/translate them?

Can this break a project in a team environment?

Actually, it’s much worse than that. The issue appears to be that the “global” keyword is being stored along with the variable name even though that shouldn’t be the case, so the variable name isn’t “foobar” but “global foobar”, yet the former is needed to check for errors. This is definitely a bug and needs looking into.

So this one’s on me. It turns out that we’ve always saved the name of the variable into the blocks file, including the “global” keyword. However, up until a change I made in May, we never internationalized the global keyword, so even in other languages you would get “global foobar”. Now, when the internationalized version is saved it saves the translated version of the global keyword, not the character sequence “global”, which breaks the type checking in any language other than the original.

I’ve uploaded a potential fix to GitHub for review that keeps the English name internally but shows the translated name to the user (and handles the broken cases now):


This design decision might be related to populating the list of possible variable names in a get/set variable block, to get both the local and global names.

Something to double check when testing the fix.

Is the translation issue related to this tool tip nonsense?


This mis-identification of control type occurs all over the place.

– Steve

No @SteveJG, that's a different issue related to some internal changes we made to allow internationalization of the tooltips, but it had some side-effects on the English version that we're ironing out.

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.