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?
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.
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.