"govinds" wrote:
"rftvaa" wrote:
We gave up on the RTL support because we also went with the StringReverse alternative but it became a huge challenge when we had to support multiline labels. In case that is also a requirement in your channel, you should start considering how are you going to support it as soon as possible. I can share our attempts on that later if you need.
could you share what you did to solve this? Trying to support RTL on Roku for mutiline labels is becoming so frustrating. Anybody got any good solutions for this?
You said "good solution" so maybe this isn't that. "A solution" is to assume how many characters will fit a label regardless of screen real estate. Then assign 10 labels. Each of those labels number 1 through 10. Now each of those in itself is its own label its own line. You no longer do multi-line as you must now do this in a function using each of your 10 labels or however many you need do span lines onto. You may not need all 10 of these labels for your lines. They are there if you do. You would also have to deal with handling translation placements if this wasn't within say a layout group.
Lets assume it is bound by a layout group that would handle align all the labels and eliminate needing any translation placements in the labels at all and still keep everything lined up nicely. You would probably need to write this as a component that extends the label node. Then use it to create a fake multi-line label using multiple labels. You reference it back by the layout group which would include the child nodes of the labels. Doing the math for all this to figure the right amount of characters to assume for the width of your labels would take some magic math equation. You might be able to use GetOneLineWidth() to more accurately tell when to chop the lines you feed to the labels and get pretty close to actually copy what multi-line labels do to begin with. You can't chop on bytes you have to chop on characters so hopefully the Roku can do this correctly using instr(index,$text," ") and index is the amount of characters you assume can fit the line if you can't get the GetOneLineWidth() to work with your custom fonts that work with any language such as Googles Noto. We could never make GetOneLineWidth() work reliably with right to left and string reverse. Maybe you can? Otherwise abandon it and instead count characters and assume a width-per-char to apply. You might always cut too soon but you can get it baby bear/goldilocks close. Where it is close enough for the government type of thing.
But like others said the rows don't start on the right. Scrolling doesn't start on the right. You would have to roll-your-own components for all of these too that over-ride the default behavior. Extend the component and then customize it. There may be more shortcomings to this that I do not see as I have not fully attempted this yet. It is possible though but you must go through effort to get there. Roku does not make any of this easy when you work outside their supported language set. You go off the map so to speak and have to forge your own roads.
It might also be possible to use a labellist and get the same effect as multiple labels without the limitation that wrap="true" imposes on labels? You need to try labellist and feed it cut lines as the list. This might also be possible and less math since you wouldn't need to track which label of the 10 to add data. You just append to the one labellist.
function stringReverse(input as String) as String
newStr = ""
for each char in input.split("")
newStr = char + newStr
end for
return newStr
end function
). My solution was to divide text by language regions where is RTL or LTR direction and process them separately (server-side algorithm). Than this text come to client via API ready to display, except of multi-line appearance that is implemented in application. And after all of this - there are few annoying issues in UI still there 
