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
18 stars 5 forks source link

Localize output messages from the server #11

Closed kristiank closed 3 years ago

kristiank commented 4 years ago

Is there a technical reason why translating output messages from the server could not be solved by using the same strategy as for the block definitions? E.g. could not the server send i18n.translate("output message") instead of "output message"?

I'll try to find the relevant server side code, but you could pinpoint me to correct files. Thanks.

RichoM commented 4 years ago

could not the server send i18n.translate("output message") instead of "output message"?

Since all the translation is done on the client side we would have to call the i18n.translate function in this line, just before calling appendToOutput. Most strings coming from the server would be translated without problems, like 'Connection accepted!' or 'Compilation successful!'. Some strings, though, can have parameters (like 'Program size (bytes): {1}') but the server sends these strings already formatted. We would need keep the original string and the parameters separately and send both so that the client can first translate the string and then format it.

I'll try to make the change when I find some time but if you want to take a look at the server code, the class responsible for gathering all the output messages is UziLogger, and the code that sends the messages to the client is in UziResource>>#detail:. This last method just builds a Dictionary with all the data that will get sent to the client.

In a related note, squeak uses a different syntax for formatting strings, as you can see above. But I think we should use your %1 format in all places to simplify the code.

RichoM commented 4 years ago

I made the necessary changes to localize server messages. It works, but only if the language has been set before the message arrives to the client. If you change the language afterwards the messages already received are not updated. I think I know how to fix it but I'll probably look at it tomorrow

RichoM commented 4 years ago

Done. I ended up rebuilding the entire output panel when changing language. For that I needed to keep the original messages in memory so I decided to limit it to the last 100 lines, which I think is a sensible choice.

kristiank commented 4 years ago

This is great. Yes, I think 100 messages is a sensible choice. I'll get the translations done soon. Also I promised you Swedish and Finnish translations.

RichoM commented 4 years ago

That would be awesome. I guess we would have to split the translations.js file by language. What do you think?

kristiank commented 4 years ago

Yeah. Swedish is now added in #20. I will think about splitting the translations file by language. I am a bit concerned of how the i18n module works currently.

What I understood so far is that the translations are looked up by the current language's msg string. This can lead into strange behaviour if there are identical terms in different languages, e.g.:

en se
execute kör
run kör

I think a translation table like this can end up using the wrong translation if switching language from English to Swedish and then back to English again. Wouldn't it?

But this should be solvable by using the "language independent" indexing... which is what I want to think about a bit more. What do you think?

RichoM commented 4 years ago

I think a translation table like this can end up using the wrong translation if switching language from English to Swedish and then back to English again. Wouldn't it?

No, the translations are always looked up using the english msg string. And, except for direct calls to i18n.translate, all nodes in the html "remember" their original string so that when you change the language they can be automatically updated.

kristiank commented 4 years ago

I feel that we could split the translations to separate files a little bit later. Perhaps I should first finish defining all the blocks with a translation msg. And after that the "language independent" indexing, since each file would need to include the English msg string. Until then it might be more comfortable to work with the translations in just a single file.