Add Swedish and Uzi syntax translations

[kristiank]

I also added and improved some Estonian translations

[kristiank]

I took adding Uzi syntax translations as a good way for me to learn the language.

Some notes that could be helpful in finding good "language independent" lookup keys for the translation messages (job being done in #12):

1. The sonar block's Uzi code uses distance_mm, distance_cm and distance_m, this could be in the directions of a good label for the translation. Although I could prefer a more laconic label such as distance unit meter. I made the change to resolve collision with lookup keys m (for meter) and m (for minute).
2. something that could add more contex to the translations and lookup keys would be to use labels for the inputFields, e.g. to use %distance_unit instead of %1. This change in the initBlock code would be pretty straightforward and only require changing inputFields to an Object instead of Array and changing the regular expression.

What do you think?

[kristiank]

I added a language independent lookup label in 33f7a47. It is based on the English translations (and some Uzi syntax until I find better more English-looking labels.

I already feel this independence of any of the shown/translated languages allows greater flexibility. For example in 37bb10f it enabled me to define the delay block without conflicting with the translation string of the wait block. But I ran into some further problems with adding the Uzi syntax translation for the delay block.

As it is set up now, some strings (e.g. time units for milliseconds, seconds and 'minutes) are translated independently of the blocks they are used in. I see a clear rationale behind this, and I sympathize with it, but as much as the Uzi syntax is concerned, the dropdown selection for the time unit actually specifies the Uzi function ('delayMs, delayS etc). One way to tackle adding the Uzi syntax translation would be to add several translation strings that are block-specific, like delay_milliseconds, wait_milliseconds. How many that are needed would depend on the Uzi syntax and if there still is a translation string that is "shared" between many blocks, we could name it something more general, like time_unit_milliseconds (or why not with whitespace instead time unit milliseconds). I feel this drifts a bit away from focus of the Physical BITS into a translation thingy, but probably there is not too much work from the translation side of simply copying "milisegundos" into each of the block specific translation? How do you feel?

[RichoM]

Yes, I see the problem. I think your idea of using block specific strings should work fine. And I have no problem with copying "milisegundos" as many times as needed.

[RichoM]

Great work, by the way. Let me know when you want me to merge this pull request.

[kristiank]

Thanks for encouraging me. The last commit successfully demonstrates that it works to translate the delayMs() and related functions into Uzi syntax. This is a great way to learn Uzi for me :-)

[kristiank]

I noticed the block name toggle_variable maybe should be name toggle_pinstate, but don't really know how much it matters and how to keep track of these small things...

[kristiank]

I can't really figure out why this sometimes happens and sometimes doesn't happen: currently the block number_divisibility is shown as split into two rows in all translations. But in the for block it happens only for Estonian language. I will investigate the initBlock function during the weekend.

[RichoM]

I noticed the block name toggle_variable maybe should be name toggle_pinstate, but don't really know how much it matters and how to keep track of these small things...

Yes, naming is hard. In my first attempt at defining the blocks I didn't understood blockly so I ended up making duplicates for each block that had a pin as argument: one with a dropdown and another with a value (these ones had the _variable suffix). Later I added the pin block and learned about shadow blocks so I removed all the dropdown duplicates. Unfortunately I was too lazy to rename the remaining blocks.

You can rename any block if you want. You just have to be careful to also rename it in the toolbox.xml and blocks2ast.js files. The toolbox is easy, it just follows the blockly rules. The blocks2ast.js is a little more complicated because it contains all the rules to generate code from blocks. But you shouldn't have any problem. There is an object called dispatchTable which uses the block names as keys, it's not pretty but it works :)

https://github.com/GIRA/UziScript/blob/a70dea48045c0163040077578755b01d2a51055c/web/ide/blocks2ast.js#L242-L1110

If you want to rename the blocks it would be great but I suggest we merge these changes first. I'm starting to worry about conflicts.

[kristiank]

Yeah, okey. Probably I don't need to add all the Uzi translations before merging, so let's make a merge and start clean again. I'll check and resolve the conflicts on wednesday morning. Tomorrow I'm rather busy.

[kristiank]

I am a little confused how to solve the conflicts. I first thought that I should add into a new commit all the code that you have added, but this is probably wrong because it then would show me as author of all the changes you made(?) If I instead click on the Resolve conflicts buttons here on this page, it shows for the blocks.js just a very small portion of the code where we both have made changes. So probably I should only change that part in my blocks.js code?

When looking at the conflicting changes in the translations.js file, I have to really go through it line-by-line. In this I will work I will add the semantics from your changes, e.g. I will change all translations mentioning tone so that it instead says note. Isn't that correct?

Nice to be in a mess and learn from it :-)

[kristiank]

Ah, after further thinking I think I got a hang of it. I am using a graphical three-way diff editor (Meld) and in it I see three versions of the blocks.js file: 1) to the left is my local branch with all my edits 2) in the middle is the new resulting file from the merge (that I need to edit) and 3) to the right is all upstream changes (e.g. your changes).

My strategy need to be the following:

1. I don't merge in any of the new code you have written (this will be done automaticall by fast-forwarding of Git)
2. I do merge in all of the new code that I have written
3. I pay special attention in the part where both you and I have made changes

This sounds logical, but I wanted to share my small-step-revelations with you. I'll have the merge ready tomorrow morning.

[RichoM]

Yes, I think your strategy is correct. I wouldn't worry too much about my changes to the translations file. I think I only added a few strings for the new blocks so I won't mind doing it again, if needed.

[kristiank]

I have now resolved the conflicts. It turned out that atleast if I use my graphical diff-editor as git mergetool, then I need to add (well, merge) all the changes, both from my local branch and from the branch that I am merging. It seemed that if I would have not used mergetool but simply merge, then all that was conflicting was the two lines both you and me had edited. Anyway, going through all the changes on both sides using the mergetool made me much more aware of all the changes that had been done.

I was not able to (in a simple manner) to merge all the edits you had done in the translations.js file, so they seem to have been lost. I noticed there were translations for quite a few new blocks, so if you don't mind, you could add the translations again. I can afterwards add the Uzi, Estonian and Swedish translations for these.

[kristiank]

I strike my last, it won't be too much of a hassle for me to add the new translations. In this way it will be easier and I can simply add the other language's translations at the same time.

[kristiank]

I have now tried to incorporate all new translations from your side. I'm sure some of them has "wrong" labels and won't be found, but I can adjust this tomorrow. From my point of view you can merge this and I will start with a fresh branch from master afterwards.

I have checked that all blocks are displayed and I am quite confident all is correctly merged. During the merge the was at several occasions something not working, so now that I have re-done so many times and see that everything is displayed nicely it just feels right. But of course, you could double check this.

[RichoM]

Nice! I haven't tested it thoroughly yet but, at a first glance, it looks great. I'll merge right away. Thanks!