Looks fine (but obviously, I can't say anything about the hebrew part - that's 99% :)
But how are you using it as the UI doesn't support RTL? Type a letter and use the cursor keys to move back?! :)

how can i change the menu title from en_HE ?

I guess you also need to add it here:

it looks like the hebrew variable name are failing circleci, how can i fix this?

I guess Lua is fine with hebrew letters in variable name, as it works and you managed to make some screenshots. So probably a Luacheck issue, not supporting them.
But may be it's saner to keep variable names in pure ascii?

pinging @Frenzie

how are you using it as the UI doesn't support RTL? Type a letter and use the cursor keys to move back?! :)

In case you want more fun, I guess you could use a trick introduced with the koread keyboard (ko_KR_keyboard.lua), which wraps the inputbox with (very complicated) code. I guess you could use that to wrap addChar() so it does add the char, and then, if it detects its a hebrew char, just do an additional leftChar() to move the cursor before the added char.

But how are you using it as the UI doesn't support RTL? Type a letter and use the cursor keys to move back?! :)

the only thing RTL or LTR is the display,
i just type normally it just displays LTR (backwards) for example:

how can i change the menu title from en_HE ?

I guess you also need to add it here:

koreader/frontend/ui/language.lua

Lines 7 to 12 in bcceb94

	local Language = {
	language_names = {
	C = "English",
	en = "English",
	ca = "Catalá",
	cs_CZ = "Čeština",

But then, it becomes a full UI language, falling back to english I guess?

it works, i just did not add it to the language menu, like other languages that dont have a translation yet

also how can i change the menu title from en_HE ?

Note that en-HE would mean Hebrew English, a variety of English like en-US, en-UK, en-AU, en-NZ, etc. I should simply be named he.

right now the keyboard is just a extension to the english, replacing cyrillic characters with hebrew ones, so i am not sure if it should be he or en-HE i don't mind changing it either way.
this is the way i primarily use it: english ui, but also able to type hebrew characters

i just type normally it just displays LTR (backwards) for example

Oh right :) everything works in the logical order, so you must type them that way (until we really support displaying them inverted - but still keeping them in that logical order for store and search.)

right now the keyboard is just a extension to the english, replacing cyrillic characters with hebrew ones, so i am not sure if it should be he or en-HE i don't mind changing it either way.

Please keep it as he because en-HE doesn't make much sense without a special explanation.

Please keep it as he because en-HE

But he should probably have the hebrew letters on the initial keyboard map (and latin ones on another map) - if it ever gets usable if/when we have RTL support.
This one here is mainly en with another map dedicated to hebrew.
We don't have (yet) anything to handle that kind of 2nd level language.
Unless if now that we have the option to choose the keyboard layout via the menu, it becomes less of an issue, and if I ever need to enter japanese, korean or hebrew, I'd just select the keyboard I want. It's just complicated when I want to enter these different letters in a same typing session... as it's not always possible to save what I just typed, go back to menu, select another keyboad, and re-edit what I was typing.

I want something like holding or swiping on the spacebar to change layouts, out of a selection of enabled ones. But like I wrote in the other PR I've been letting it slide because that would take at least a medium time investment, not least of which experimenting with UX/UI, whereas the quick 10-minute menu switch implementation does a lot of good in little time and I should've done it a year ago.

But he should probably have the hebrew letters on the initial keyboard map (and latin ones on another map) - if it ever gets usable if/when we have RTL support.

Which doesn't change the fact that en-HE is a confusing name. en-he might kinda sorta work, especially if you make it something like en__he. I'm not entirely sure how clear that would be, but at least it's not plainly saying English of the HE variety.

@yparitcher Btw, bit of a random question but how did you mark this PR a draft? I don't think I've ever noticed that before.

Edit: ah, it's new(ish) https://github.blog/2019-02-14-introducing-draft-pull-requests/

should be fixed, he for now, has all the letters their variations (via popups), nikkud (punctution), and some (not all) cantillation marks.

@yparitcher Btw, bit of a random question but how did you mark this PR a draft? I don't think I've ever noticed that before.

when opening the PR on the submit button there is a down arrow to select a draft PR, for not ready PR's

i might add the rest of the cantillation marks via popups in a seperate PR, this one is ready for now

any comments @poire-z ?

Nope, looks fine to me.
No pb having he as a global UI language? It won't magically popup on transiflex and have more people disappointed as we don't display what they added nicely?

@poire-z Remember when you added a hundred languages for Google Translate or some such? All complete translations have contained the word Hebrew for ages. ;-)

But also the strings in question here aren't translated. Which is pretty useful when testing some stuff in Chinese. ;-)

I didn't mean the strings in this PR.
Just that now, Hebrew is a UI language. So, people may select it, and find ... english.
Then, they'd go to Transiflex translating all our english strings to hebrew, and the next day go download a nightly, where they'll see detalsnart yeht sgnirts eht lla like that ! :)

I decoupled the language names from the menu items when I added the keyboard selection. My goal was merely to access them through Language:getLanguageName() but it also happily obviates any such concerns. :-)

Oh, right, the available menu languages are in another section below in language.lua! 👍