search

GIRA / PhysicalBits

A web-based programming environment for educational robotics that supports live coding and autonomy using a hybrid blocks/text programming language.
https://gira.github.io/PhysicalBits/
MIT License
19 stars 5 forks source link

Define all blocks using i18n #18

Closed kristiank closed 4 years ago

kristiank commented 4 years ago

I ran into the expected problem of row breaking not occurring in the forever block. But I might have some thoughts later this evening. Feel free to comment if you already have some thoughts on this :-)

RichoM commented 4 years ago

Maybe we can extend the format syntax to allow a symbol to represent a "newline" and change the initBlock function to append a dummy input whenever it founds this symbol. I did the simplest thing I could think of and used the %0 for dummy inputs. See 912db02c1d6268e722240887c697d6a9d74d7a3f This fixes the issue with the forever block but it also seems useful for another blocks, like the number_modulo. What do you think?

kristiank commented 4 years ago

I can't see more than changes of the message strings to contain %0 in your commit -- didn't you have to change anything in the initBlock() code also?

The only drawback I can think of is that your use of %0 might not be very understandable for translators. But then again, that might not be a critical goal to achieve? I was myself thinking something more in the veins of adding a newline separator (perhaps %% or ## or '//') and split the msg-string into parts and run initBlock for each part. But I'd still like to see whether you had to change anything in the initBlock code.

kristiank commented 4 years ago

I tried out the strategy of using a newline separator ^^ and I think it works. Of course I would put the msgParts loop inside initBlock, but I feel lazy today. What do you think?

RichoM commented 4 years ago

I can't see more than changes of the message strings to contain %0 in your commit -- didn't you have to change anything in the initBlock() code also?

I'm sorry, I did the change in two separate commits but forgot to reference the one with the initBlock function. This is it: 2025f6500f672bc5f95ee0a6c80cc8737e4bd930

The only drawback I can think of is that your use of %0 might not be very understandable for translators. But then again, that might not be a critical goal to achieve? I was myself thinking something more in the veins of adding a newline separator (perhaps %% or ## or '//') and split the msg-string into parts and run initBlock for each part. But I'd still like to see whether you had to change anything in the initBlock code.

Yeah, I chose the %0 because it was the simplest change I could think of (just two lines of code!). But originally I was thinking of something like \n. I don't care much about the symbol we choose, though, and I don't know the usual conventions for translators. So I leave it to you to decide.

kristiank commented 4 years ago

I now chose \n as line separator and moved the row splitting code into the initBlock function. I'm quite satisfied of it, how do you feel?

Still, I consider the need to use a new line at the end of the number_modulo block a bug, but I haven't had time to investigate it. What do you think, is it a bug or feature?

kristiank commented 4 years ago

Could I use this Pull Request for implementing the "language independent" indexing for the translations? I noticed the wait and delay blocks will have colliding msg strings without it.

Feliz Navidad!

RichoM commented 4 years ago

I now chose \n as line separator and moved the row splitting code into the initBlock function. I'm quite satisfied of it, how do you feel?

Nice, I didn't even think of calling initBlock multiple times to achieve the newline behavior.

Still, I consider the need to use a new line at the end of the number_modulo block a bug, but I haven't had time to investigate it. What do you think, is it a bug or feature?

Maybe "unintended feature"? ;-)

I don't know, it seems to be how Blockly works (see this) The only way I found to keep the number_modulo in one row is to force its inputs to be inline. But that would take away the freedom from the translators so even though it's not very elegant I'm fine with it.

RichoM commented 4 years ago

Could I use this Pull Request for implementing the "language independent" indexing for the translations? I noticed the wait and delay blocks will have colliding msg strings without it.

Let me merge this pull request so you can start working on that from the base branch instead.

Feliz Navidad!

Merry christmas :)