rtl language

[alior101]

Hi I'm planning to start translating snap to hebrew (rtl language) in order to do a father/son elementary school presentation (kids don't yet read english..) - just wondering if such effort already started or even possible. I did a quick and dirty try and saw that I will need some manual adjustments of the location of words. Also, is the direction of the blocks graphics changeable from right to left ? if so, can anyone point me to places where to start ? Thanks Lior

[jmoenig]

Hi @alior101 , rtl support is right now still a glaring omission in Snap's localization effort. Any help would be greatly appreciated!

[alior101]

Ok. I'm on it. It will probably involve:

1. reversing the input array in thread.js evaluate block so that the translation make sense. at RTL flag will activate this reversal upon choosing an RTL language.
2. a new lang-he.js file - I'm fighting a lot of combined RTL and LTR string issues (the %xxx params are LTR whereas the other words are RTL)
3. MAYBE - a reverse of the IDE/blocks graphical orientation (not sure it's really needed) Will let you know once I have something working Lior

On Mon, Jun 8, 2015 at 11:38 AM, Jens Mönig notifications@github.com wrote:

Hi @alior101 https://github.com/alior101 , rtl support is right now still a glaring omission in Snap's localization effort. Any help would be greatly appreciated!

— Reply to this email directly or view it on GitHub https://github.com/jmoenig/Snap--Build-Your-Own-Blocks/issues/817#issuecomment-109908345 .

[jmoenig]

excellent, thanks for starting on this important issue!

[ghost]

Why not code snippets?

var rtl = false; // set to true on RTL languages, to false on LTR languages
function calculateX(morph, point) {
  var topBlock;
  if (rtl && (topBlock = morph.parentThatIsA(BlockMorph))) {
    while (!topBlock.parentThatIsA(BlockMorph)) {
      topBlock = topBlock.parentThatIsA(BlockMorph);
    }
    return new Point(topBlock.right() + topBlock.left() - point.x, point.y).
  }
  return morph.topLeft();
}

And you use this function every time you want to translate a point.

[alior101]

thanks! will look into that as soon as I work out the difficulties of the block.spec and input parameters: for example, in Hebrew a - b is used and understood as in English (because "-" is LTR character) whereas "a mod b" is written in Hebrew as b מודולו a because the operation is in Hebrew itself so I need to switch params order ... I'm currently checking if a spec is in a dict file in order to decide if it is sensitive to RTL language and it currently looks like a good approach ..

On Mon, Jun 8, 2015 at 3:12 PM, Luís Câmara notifications@github.com wrote:

Why not code snippets?

var rtl = false; // set to true on RTL languages, to false on LTR languagesfunction calculateX(morph, point) { var topBlock; if (rtl && (topBlock = morph.parentThatIsA(BlockMorph))) { while (!topBlock.parentThatIsA(BlockMorph)) { topBlock = topBlock.parentThatIsA(BlockMorph); } return new Point(topBlock.right() + topBlock.left() - point.x, point.y). } return morph.topLeft(); }

And you use this function every time you want to translate a point.

— Reply to this email directly or view it on GitHub https://github.com/jmoenig/Snap--Build-Your-Own-Blocks/issues/817#issuecomment-109971015 .

[jmoenig]

The specs are currently hard coded in objects.js and used as keys in the localization dictionaries. It's probably a good idea to insert another level here:

identiy spec -> appearance spec -> translations

where the "appearance spec" may change the order of inputs arbitrarily. This will be good for many languages and is not even rtl specific. As the saying goes "there is no problem in CS that cannot be solved with another level of indirection" :-)

[birbilis]

I think Blockly says it supports RTL, so could check their implementation too https://github.com/google/blockly/ on what they're doing for RTL

[alior101]

Hi Jens, I looked at both blockly implementation and your suggestion of inserting another level of indirection but it was way too difficult/revolutionary for a newbie as I am and since perfect is the enemy of the good :) I decided to stick with the current implementation and correct for reversed input parameters at other stages of the code flow. What I have now is mostly working with few rough edges which will take me a long time to fix due to very busy schedule. I was thinking that it would be a good time to merge with upstream so that other people can join the effort and maybe do things the "right" way. I know there are lots of changes going on lately su you are probably very busy but if it is acceptable for you I can create a pull request (my code is checked in in https://github.com/alior101/Snap--Build-Your-Own-Blocks )

On Tue, Jun 9, 2015 at 5:05 PM, George Birbilis notifications@github.com wrote:

I think Blockly says it supports RTL, so could check their implementation too https://github.com/google/blockly/

— Reply to this email directly or view it on GitHub https://github.com/jmoenig/Snap--Build-Your-Own-Blocks/issues/817#issuecomment-110365920 .

[birbilis]

I think I have commented on this elsewhere, but why bloat the root folder of the project with all those resource string (for translation) files and not have them in a subfolder?