Issue with "Holem" vs "Holem for Waw" with the SIL Hebrew Keyboard

Keyman
1

Hi,
I have an issue with Holem vs Holem for Waw with the SIL Hebrew keyboard.

Normally, typing “O” will output Holem, and typing “Shift + O” will output Holem for Waw.
I wish this mapping is consistent. However, the combination with Waw messes it up.
When I type “Waw” followed by “O”, it automatically turns into “Waw + Holem for Waw”.
I need to first type “O”, then “Waw” in order to output “Holem Waw”.

This is not how I normally type. I used to use the SBL Hebrew keyboard, and typing “O” always outputs “Holem”, even after “Waw”. I’ve always instructed my students to first time “Waw” then “Holem” for “Holem Waw”. Now, I will have to tell them NEVER to do it for “Holem Waw”. It is very important, because if students type “Holem for Waw”, their answers will be marked as incorrect by the online grading system.

Is it possible to prevent the automatic transformation?

Edit:
to make it worse, the auto transformation issue happens to the Mac version only. The windows version does not have this issue. So there is in consistency.

PS: I switched from the SBL Hebrew keyboard to Keyman, because the SBL Hebrew keyboard is inconsistent on the presentation of Shin and Sin. On Mac, the unicode value for Shin is \uFB2A and on Windows it is \u05E9\u05C1. Keyman is consistent on the presentation of Shin and Sin. But now, the “Holem” → “Holem for Waw” issue with the Mac version of Keyman is worse than the Sin/Shin issue with the SBL Hebrew keyboard in my work, I may have to painfully switch back to the SBL keyboard.

So, again, is there any way to prevent this automatic transformation of “Holem” to “Holem for Waw” after Waw on Mac?

Thanks!

2

I do not know the language nor the keyboard enough to help you, but would anything from the keyboard documentation helps.

https://help.keyman.com/keyboard/sil_hebrew/1.8.1/sil_hebrew

@Lorna Are you familiar with this keyboard?

3

Hi @makara,

Thanks for the follow up.

The documentation has both “O” and “Shift + O” marked as “Holem” (BTW, most of the vowels are not properly displayed).

image
image992×477 34.4 KB

But I’d like “O” to consistently output “Holem” (\u05B9), and “Shift + O” to consistently output “Holem for Waw” (\u05BA).

image
image757×867 36.2 KB

I just made a table to demonstrate what I meant:
image

The Expected Output is what I get from the SBL Hebrew keyboard (SIL layout).

4

There was an intentional change made to the output of holem and holem with waw in 2007. It’s probable that the SBL keyboard (which was originally created on the SIL keyboard layout) was created prior to this change.

I’ll check with our main client, but I believe this was intentional and I wouldn’t want to revert the change. We could improve the documentation to indicate this if it’s needed.

5

Hi @Lorna,

I suspect it was intentional too. But still, it is inconsistent. As the OP has mentioned, on Windows, the keyboard does not work in this way.
Also, you may remember, I made the mobile version of the same keyboard, and I did not make this intentional change.
This inconsistency is very troublesome when we want to use it for a class, in which students use different computer machines. We will have to make at least two sets of answer keys for that. I used to ask students to use the SBL Hebrew keyboard, but its Mac and Win version has different encoding for Shin and Sin. I switched to Keyman. I thought Keyman is more consistent across the platforms, but it turns out it is not. I had to make a user script to change that behavior so that students will have consistent experience across different platforms when taking quizzes and exams.

6

I didn’t see this edit until just now, sorry… From what I understand, the most important point is that the behavior is consistent between platforms, so that you can give one set of instructions to your students.

The behavior should be consistent between Windows and Mac – I have checked, and the keyboard makes no distinction between platforms, so this would be a bug.

According to the keyboard source, both o and O produce HEBREW POINT HOLAM (U+05B9), except when preceded by HEBREW LETTER VAV (U+05D5) (w key), in which case both those keys will produce HEBREW POINT HOLAM HASER FOR VAV (U+05BA). (There are some additional nuances around other diacritics but this should still be consistent.)

Makara, are you able to test and reproduce this issue on macOS? I have tested on Windows and verify that this behavior is what I see on Windows. (I am about to reboot to mac to test there now.)

7

I am seeing some inconsistent behavior with the SIL Hebrew keyboard on Keyman for Mac. Will investigate further – this won’t happen until next week at earliest as I am away from my desk until then.

8

Hi Marc,

Thanks!

I prefer that the keyboard does not convert Holem to Holem for Waw. I prefer that what the keyboard outputs is what I type.

However, I understand that it wants to make changes so that the outputs conforms to a standard. In this case, if we type Holem after Waw, we get the consonantal “Waw” followed by “Holem for Waw”, and if we type Holem before Waw, we get the vowel “Holem Waw”. This behavior is understandable and I can accept that. And yes, as you said, I want it to be consistent across the platforms.

9

This behavior is observed on macOS 11.5.1 when typing in Note, TextEdit and LibreOffice.

10

Which version of Keyman are you using?

11

Allow me to say a little bit more about this.
From my experience and my observation of limited users, when we type Waw followed by Holem, most of the time we want to type the Hebrew vowel letter – “Holem Waw”. Consonantal Waw followed by the vowel “Holem (for waw)” occur rarely in Biblical Hebrew. And in modern Hebrew, vowels are rarely typed at all. It does not make much sense to automatically change “Holem” for “Holem for Waw” because it is rarely needed in a real typing environment. It makes more sense to change “Waw + Holem” to “Holem + Waw” if the latter is the standardized sequence for the vowel letter “Holem Waw”.

Also, if the keyboard is smart enough, when the consonant before Waw does not have any vowel, e.g., בּוֺא, the sign in the middle has to be the vowel letter “Holem Waw” → “בּוֹא”, and not the consonantal “Waw” followed by “Holem for Waw”. Therefore, it makes better sense to change “Waw + Holem” to “Holem + Waw” (if sequence matters, or leave it as is if sequence does not matter) than to change it to “Waw + Holem for Waw”.

12

I’m on 14.0.279 Stable

13

It looks like the difference in behavior between macOS and Windows is a problem with Keyman and that is being addressed separately I believe.

But, I do want to give clarification on why we made the keyboard change and would not want to reverse that change. This is from our expert:

You are quite right that the behaviour is deliberate. It was part of the response to changes in Unicode 4.1:

The vowel point holam represents the vowel phoneme /o/. The consonant letter vav represents the consonant phoneme /w/, but in some words is used to represent a vowel, /o/. When the point holam is used on vav, the combination usually represents the vowel /o/, but in a very small number of cases represents the consonant-vowel combination /wo/. A typographic distinction is made between these two in many versions of Biblical text. In most cases, in which vav + holam together represents the vowel /o/, the point holam is centered above the vav and referred to as holam male. In the less frequent cases, in which the vav represents the consonant /w/, some versions show the point holam positioned above left. This is referred to as holam haser. The character U+05BA HEBREW POINT HOLAM HASER FOR VAV is intended for use as holam haser only in those cases where a distinction is needed. When the distinction is made, the character U+05B9 HEBREW POINT HOLAM is used to represent the point holam male on vav. U+05BA HEBREW POINT HOLAM HASER FOR VAV is intended for use only on vav; results of combining this character with other base characters are not defined. Not all users distinguish between the two forms of holam, and not all implementations can be assumed to support U+05BA HEBREW POINT HOLAM HASER FOR VAV.

Additionally from him:

In many mss and printed editions, there is a difference between sequence 1, consonant - holem - vocalic waw, in which the holem is positioned to the top right of the waw, and sequence 2, vowel - consonantal waw - holem, in which the holem is positioned to the top left of the waw. The difference is small, but it was sufficient for the Unicode consortium to add the code point U+05BA.

The keyboard was modified to enable users to encode that distinction in a memorable fashion. Since, in sequence 1, the holem is logically associated with the preceding consonant, the typing order was ‘ow’, whereas in sequence 2, the waw is consonantal so the holem is logically associated with that waw, and the typing order is ‘wo’.

14

Thanks, Lorna.
Yes. That was exactly what I understood the reason behind the intentional change.
However, allow me to further respond to the explanation that the expert gave.

This is not to “enable” users to make the distinction. This intentional change actually forces users to make the distinction, which many users may not appreciate, because:

  1. As the expert is fully aware of:

The cases of the consonantal Waw followed by the vowel Holem has only very small number of cases. I also mentioned it in my previous post.

  1. From my experience, there are many users who do not distinguish the typing sequence between /wo/ and /ow/. To them, they both mean the vowel letter “Holem Waw”. The auto-change forces users to make the distinction. To be fair, this is not necessarily a bad thing.

  2. The SBL Hebrew keyboard use the regular “O” key consistently for U+05B9 HEBREW POINT HOLAM and “Shift + O” consistently for U+05BA HEBREW POINT HOLAM HASER FOR VAV. To me, this is more intuitive. The keyboard mapping is as clear as it can be. Whereas with the Keyman keyboard, the keyboard mapping becomes misleading or even confusing, because it says that the key is “Holem” (presumably ‘U+05B9 HEBREW POINT HOLAM’), but when I type it after “Waw” /w/, it automatically becomes “Holem for Waw” (U+05BA HEBREW POINT HOLAM HASER FOR VAV).

All in all, as I said, this intentional design is not necessarily a bad thing. I can see that it could even be a good thing. However, I suggest two things are done:

  1. Make this behavior consistent across the platforms.
  2. Document this feature in a very obvious place of the keyboard mapping page etc., so that users are very clear about it.

Both are very important in my case, because every year in the past, I’m asking more than a hundred students to install and use the Keyman keyboard, and we use it in quizzes/exams that require Hebrew typing.

15

To avoid confusion, I’ve split the inconsistency between platforms issue into https://community.software.sil.org/t/inconsistency-between-mac-and-windows-output-for-sil-hebrew/5197 and am continuing that there. This topic can be on the keyboard design philosophy!

16

I finally decided to attempt to deal with this. @martinacc if I add this to the documentation for the Hebrew (SIL) keyboard, will that be sufficient, or do you have a preferred additional wording?

image
image1069×260 15.8 KB

I’ll have to review the mobile layout to see how it needs to change as well.

THEN, for the keyboard you want, I think I will call it Hebrew Phonetic. Will that be okay? It will be the same keyboard EXCEPT I’ll remove these rules that we added for the Hebrew (SIL) keyboard. I’ll probably ask you to test the package before I put it online.

Let me know what you think.

17

Thank you very much, @Lorna!

Thanks for this comprehensive chart. This should be enough to warn people about potential issues that we might encounter. The second to the last does not seem right though. In cases of owa, the w must be the consonant Waw/Vav. If we take the a (pathach) to go with Waw, then the o (Holem) must belong to the preceding consonant. It will have to be written to the upper-right of Waw/Vav, not to the upper-left of it. If you add another consonant before Waw, you should be able to see the correct position: בֹּוַ.

If it’s possible, I would like to see the Unicode of the O/o in another color (such as red). That way, we would be able to easily identify whether it is U+05B9 or U+05BA.

I’m completely fine with Hebrew Phonetic. However, if possible, I do prefer its name to be associated with SIL, since this generally follows the Hebrew (SIL) keyboard, and in reality, it is almost identical to the SBL Hebrew keyboard (SIL layout) from Society of Biblical Literature.
https://www.sbl-site.org/educational/BiblicalFonts_SBLHebrew.aspx

Something like SIL Original ties it closer to the SIL keyboard, but it sounds more authentic than the current Hebrew (SIL) keyboard. :joy::joy:

I’ll be glad to do that!

Blessings,
Martin

18

Basically, your concern is with what the glyph looks like in the chart. The codepoints are correct, is that right? It’s true that in isolation, without a preceding consonant, it doesn’t look right. I’m not sure I want to go any further with documenting samples of a consonant preceding it.

When you talk about o/O being red, what you really mean is you want me to make U+U+05B9 and U+05BA red, is that correct? That’s not hard to do.

Regarding the name for the second keyboard, I think I’m going to go with how MS has done it and use the term Legacy. You may not like that, but if we keep SIL in the name we have to make it clear it’s not the officially sanctioned keyboard. So, it will either be Hebrew Legacy (SIL) or Hebrew (SIL) Legacy. I haven’t figured out where I want to put it. Long keyboard names are a bit problematical when you get to a small phone and the only place the name shows up is on the spacebar, so I may go with the first.

19

If I change the paragraph direction to rtl, it looks better.

image
image1082×248 16.4 KB

20

This is exactly what I meant. It looks great! Thanks!

I’m fine with either, as long as they are kept available. These two names are also accurate.

1 Like