Hebrew language problem

[meir]

Hello

I long very interested in purchasing the product.

I'm from Israel, and wants to turn it on for clients from Israel Hebrew language users,

But there is a problem with HTML5, view

With the client's language stands for English, and server-side stands in Hebrew,

When they try to write some characters written to him in Hebrew, and some in English.

Examples:
He wants to write {ת} written him [,]

{ף} [:}
{ץ} [.]

My question is why can't we identify on which language the computer,

That if he writes in this URL to write him in English
And he writes it in the RDP window to write the Hebrew part, some special symbols

And it's a very big issue for us.

Please if you can give a solution (the solution of the language toolbar isn't good for me, because you can get all sorts of settings of the server!

Thank you
Waiting to hear soon

meir

[juwagn]

>>With the client's language stands for English, and server-side stands in Hebrew
You can open the link
http(s)://your-server/software/language.html
and forcibly set the language to Hebrew he_he

After starting new session the language inside should show hebrew and when you type, your local language should be set to hebrew too, so for best 1:1 working the languages have to be synchronized.
I attach picture with the meaning.

[meir]

Hello

Based on the advice you gave doesn't help,

I never know what language is for client side,

But server-side all the time, Hebrew

And once the client is English
And Hebrew Server
Characters used for Hebrew letters and special symbols, then it will generate the symptoms bother me that the client wants to write in Hebrew,

Have perfect push?!

I also know a few friends who are interested on this issue,
And to purchase
Because the problem of typing the Hebrew language.

Thank you very much.

[juwagn]

>>Based on the advice you gave doesn't help,
>>And once the client is English
>>And Hebrew Server
I advised to set both to hebrew.
But since you personally insist to use english on client and hebrew inside rdp session, than my suggestion in this case is to use native client.

[meir]

But I can't control the client side HTML5
What language it is,

If there is code in JavaScript or ASP. NET or any source code.

I know what language it is client side.

Then pass the RDP
The language in which the client resides.

I hope you understand my problem.
meir

[juwagn]

Hello,

>>>If there is code in JavaScript or ASP. NET or any source code.
Browsers do not allow that level of access to change these parameters on client environment.
I wonder that you ask about, since it is basic option if you login into your Windows system, you should see the task bar with calendar and language bar by default.
Usually it get's changed by shift+alt or by clicking on target language directly.

PS: the main rule is, for 1:1 or closest 1:1 conversion languages have to be synchronized.
If you run english on your environment while focusing browser, than do not wonder that you get ,.: instead hebrew char. I can more or less handle A-Z buttons, but no OEM buttons, because they differ between different browsers, chrome, ie, ff, and even different browser versions, between systems win, mac, linux, so OEM buttons can not be handled on it's keycode and I have to retrieve char from it to handle it correctly, and if you use english as main language on your system, but hebrew inside rdp session, and when OEM buttons come into game play, than the program will convert .,: to matching scan codes to make it as close as possible to hardware keyboard simulation. But since .,: are present in hebrew conversion table, the program won't assume that you use english as input, but it assumes you use hebrew as set inside rpd session and accordingly convert those to scancodes for hebrew.
Technically I could meet agreement with user, that he uses locally english keyboard and enforce always english conversion table even for hebrew, in such case it could be technically possible to achive your effect. But in most cases I have experienced the user use always same language as good in their local environment as inside session, so evidently synchronizing is better.