Letter toggle: How to double-press a letter to get a new letter?

[codo dev]

Working on a keyboard for a complex syllabic/alphabetic language. Need keys that contain multiple vowels. 

Example: 

• press "a" once = "a"
• press "a" twice = "e" (perhaps by deleting "a" then replacing with "e") 
• if user presses "a" thrice = "a" (toggles back)

So, basically, if you keep pressing the same letter, it will only toggle between the 2 vowels, because in this language it would be impossible to write two vowels (next key must always be a consonant). 

Pressing the key twice is the most natural way to modify this letter, so "Shift" or any other modifiers are not an option...

How can this be achieved? 

[Geke]

Hi Codo Dev,

The keyboard layouts in MacOS don’t allow exactly such a setup as you describe.

Such behavior probably needs more advanced software, like the "input methods" used for Chinese and Japanese.

But maybe you find a different way that can be implemented through a custom keyboard layout and thus with Ukelele.

When you open Ukelele and choose "Ukelele Manual (PDF)" from the Help menu, then go to page 13 (the number on the page is 12), section 5.4, you can read about a feature called "dead keys". Once you understand how that works, you may come up with a convenient typing method for your script that can be done through a custom keyboard layout.

Generally speaking, dead key sequences always have the same length for a given key.

However, the sequence can be interrupted, and then the "terminator" character defined for the dead key is produced.

Here are a few sentences excerpted from section 5.4 to get you started, but to really get a good idea of how it works and what is possible, please read the manual:

The essential thing is that pressing a dead key produces no output by itself, but tells the operating system to treat the next key differently, and to produce something different from what it would otherwise produce.

The most common types of dead keys are fairly simple, just modifying the next key stroke, producing output and returning to state “none”. However, it is possible to have a second dead key triggered after the first, so that you go to a second dead key state. There is no limit to the length of such a chain of dead keys, but it is rarely practical to go beyond two or three.

Another important concept with dead keys is the “terminator”. Consider the case of ⌥e producing an acute accent. What happens if the user types ⌥e followed by a digit? We don’t expect to get an accented digit, so the system does something different. Each dead key has a special string called the terminator, and it will produce the terminator when nothing is defined for that combination. So, if the terminator for the acute state is a free-standing acute accent, ́, typing ⌥e and then 5 will produce ́5. In other words, if we don’t have any sensible character to produce, we put out the terminator followed by the character associated with the key that the user typed.

Note that a terminator can be the empty (or null) string. So, if you have a dead key state with the null string for the terminator, then, when the user types a combination of the dead key plus a key that doesn’t produce any output in the dead key state, it is as though the dead key was not typed at all.

[Geke]

To give a concrete example how this could work:

Top left on the keyboard is a key labeled  ̀ (on US keyboards).

If you can spare this key, you could make it into a dead key for the second variants for the vowels.

So typing an A gives the first variant, typing  ̀ then A gives the second.

Also: typing an E gives the first variant, typing  ̀ then E gives the second.

This can be extended further by making the sequence  ̀  ̀ enter a second-level dead key state.

Then typing an A gives the first variant, typing  ̀ then A gives the second, typing  ̀  ̀ then A gives the third variant.

And: typing an E gives the first variant, typing  ̀ then E gives the second, typing  ̀  ̀ then E gives the third variant.

Etc. up to the max number of variants you need to cater for.

[Geke]

Hi Codo Dev,

I hope you don’t mind that I post your PM here, so the thread is coherent:

Thank you! I have read through the .pdf manual and still trying to think of ways to achieve this... 

Is there any way to have the keyboard enter a new dead-key state while giving an output? Perhaps I could just write a new state for every key if need be... Would it be possible to simply edit the .keylayout file afterwards using Visual Studio code?

My advice is not to squeeze too hard :)

I mean, some non-standard things may be possible by editing the XML code, but usually you end up with a freak or an unreliable thing – e.g. a layout that works in some applications and not or differently in others, or it stops working when a new OS version comes around.

As to your question: I’m pretty sure there is no way to have a keypress do both things: enter a dead-key state & producing output.

The only exception would be if you are in a dead-key state and the key you press is 1. not defined in that state and 2. itself a dead key in state 0. Then the terminator of the active dead-key state would be produced onscreen & the dead-key state of the second keypress is entered.

On Wednesday, 13 May 2020 21:43:43 UTC+2, Geke wrote:

To give a concrete example how this could work:

Top left on the keyboard is a key labeled  ̀ (on US keyboards).

If you can spare this key, you could make it into a dead key for the second variants for the vowels.

So typing an A gives the first variant, typing  ̀ then A gives the second.

Also: typing an E gives the first variant, typing  ̀ then E gives the second.

This can be extended further by making the sequence  ̀  ̀ enter a second-level dead key state.

Then typing an A gives the first variant, typing  ̀ then A gives the second, typing  ̀  ̀ then A gives the third variant –

[John Brownie]

Geke wrote on 14/5/20 13:10:

I hope you don’t mind that I post your PM here, so the thread is coherent:

Thank you! I have read through the .pdf manual and still trying to think of ways to achieve this... 

Is there any way to have the keyboard enter a new dead-key state while giving an output? Perhaps I could just write a new state for every key if need be... Would it be possible to simply edit the .keylayout file afterwards using Visual Studio code?

My advice is not to squeeze too hard :)

I mean, some non-standard things may be possible by editing the XML code, but usually you end up with a freak or an unreliable thing – e.g. a layout that works in some applications and not or differently in others, or it stops working when a new OS version comes around.

As to your question: I’m pretty sure there is no way to have a keypress do both things: enter a dead-key state & producing output.

The only exception would be if you are in a dead-key state and the key you press is 1. not defined in that state and 2. itself a dead key in state 0. Then the terminator of the active dead-key state would be produced onscreen & the dead-key state of the second keypress is entered.

There's actually no rule that a dead key can't have output. It's just an assumption I made early on, and it is actually possible given the way the XML definitions are written. But you can't do it in Ukelele, so you would have to do it by editing the XML file, which is always an error-prone process. I don't know how it works, either, never having tried out a keyboard layout that does both output and switching state.

I wonder if this is the sort of thing that Keyman would be better at. The problem is that to develop a keyboard layout, you need Keyman Developer, which is Windows only. There's also the issue that you need to have Keyman on your computer to use the keyboard layout. Find it at http://www.keyman.com/.

The reason I mention Keyman is that there used to be this sort of thing available in early linguistics software, back 25 years ago or so. I remember one app which produced up to four different symbols by pressing a key repeatedly, so this approach might have been in the mind of the developer of Keyman.

John

--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland

[codo dev]

Thanks! I actually didn't mean to send that privately, so thank you for sharing. :) 

The reason that I am working so passionately on this project is because I'm working on an Indian language where the current way of typing the original script is too complex, so only professionals (journalists, politicians, etc.) learn to type in the language. Everyone else tends to just use a transliteration keyboard or simply writes in Roman (English) characters... Many of my friends from India have forgotten how to write in their own language. I know that a better simplified typing experience can be created, but some pushing & creativity may be necessary. 

The language contains about 36 consonants, 16 vowels + virama. The language is syllabic/alphabetic & primarily written in syllables. There are about 20,000 possible combinations of syllables (which most commonly contain two consonants + one vowel). It would be better if the unicode included the secondary-form of "a" as it's own character, so that characters may easily be written in base form. And it would be even better if there were unicode for the base form of consonants.

I read about Keyman in the book "Fonts & Encodings" by Yannis Haralambous". It seems like a great software, but it's unfortunate that users would have to download something special. I would like to build something that could work on both Microsoft & MacOS, and eventually for iOS + Android. Perhaps Keyman would be better.... I know I could create a web app as well, I would just rather a keyboard - an every day tool - not be so limiting to a people. 

Thank you so much again for the suggestions! 

[Tom Gewecke]

What’s the name of the language you are talking about?

[Sorin Paliga]

I was just about to ask the same question.

> --
> You received this message because you are subscribed to the Google Groups "Ukelele Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ukelele-user...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/ukelele-users/EF881744-2C6E-4036-A619-408367CE9A2E%40gmail.com.

[codo dev]

The language is Telugu. 

On Thursday, May 14, 2020 at 2:37:50 PM UTC-4, Tom wrote:

What’s the name of the language you are talking about?

[Sorin Paliga]

Telugu has native support in macOS, isn’t it sufficient?

--
You received this message because you are subscribed to the Google Groups "Ukelele Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ukelele-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ukelele-users/77072203-109e-44e3-9705-3c3d4f4ed29e%40googlegroups.com.

[codo dev]

Unless we create a keyboard that feels as simple to use as QWERTY, it is unlikely that regular people will use it on a regular basis.

[Sorin Paliga]

Hm... I do not think that is can be ‘as simple as QWERTY’ for such a script.

--
You received this message because you are subscribed to the Google Groups "Ukelele Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ukelele-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ukelele-users/9207817f-5543-4c7a-87b3-499606cc8fee%40googlegroups.com.

[codo dev]

It can be! By looking at how current Telugu speakers use QWERTY to write their script in Roman (English) characters. There are many habitual ways of writing which are known to all speakers, so the keyboard can be condensed & arranged in a way that feels more natural to how the language is currently used. I've already created one potential layout concept..... but I'm sure it could be improved upon. 

Some examples.... in Telugu, each letter has a secondary form. So the keyboard currently looks a bit too busy. But it is possible to have a keyboard where every letter only shows the primary/base-form, but is coded to automatically output the correct form based on when it is typed.... Condition: If a vowel comes directly after a consonant, then it is secondary. If a vowel comes directly after a space, then it is primary. The only character that can follow a vowel is a consonant or a special vowel ("am" or "aha"). Syllable clusters always end in a vowel, except for at the end of a word where it can end with a consonant in base form using a virama....

Many vowels have a long-form. When Telugu is written in English, we can imagine these vowels as: a, aa, i, ii, u, uu, ru, ruu, e, ee, (ai), o, oo, (au), (am), (aha). As you can see, many of the vowels are simply a longer version and are usually written as doubled in English characters. So, what if a Telugu keyboard only had the short version: a, i, u, ru, e, o... Then the user simply taps the key once for the short version & twice for the long version. This user-experience relates the most to how Telugu is typed today using English characters - making the switch to the keyboard much more natural. It also more closely matches the experience of typing to how the characters are produced when speaking. The rhythm of typing would more closely match the rhythm of speaking. 

Also, all hard-breath consonants would simply be shift, which is how it is typically written in English texts when users can't add the dot below. It feels more natural to add something extra for a hard-breath consonant, as we add something extra when speaking. 

I am no scholar, but I did study music & percussion, which is all about how things feel... 

I believe we can find a way to make this happen. :) And I've definitely discovered a new passion through this project.

On Thursday, May 14, 2020 at 4:08:45 PM UTC-4, Cattus Thraex wrote:

Hm... I do not think that is can be ‘as simple as QWERTY’ for such a script.

On 14 May 2020, at 23:07, codo dev <codo....@gmail.com> wrote:

Unless we create a keyboard that feels as simple to use as QWERTY, it is unlikely that regular people will use it on a regular basis.

On Thursday, May 14, 2020 at 4:05:30 PM UTC-4, codo dev wrote:

The language is Telugu. 

On Thursday, May 14, 2020 at 2:37:50 PM UTC-4, Tom wrote:

What’s the name of the language you are talking about?

> On May 14, 2020, at 11:24 AM, codo dev <codo....@gmail.com> wrote:
>
>
>
> The reason that I am working so passionately on this project is because I'm working on an Indian language

--
You received this message because you are subscribed to the Google Groups "Ukelele Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ukelel...@googlegroups.com.

[Sorin Paliga]

I do not know Telugu, it is quite clear that you need an input method which cannot be created, I’m afraid, with UKELELE. Perhaps you should contact Apple engineering for this. Or Michael Everson:

http://evertype.com

To unsubscribe from this group and stop receiving emails from it, send an email to ukelele-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ukelele-users/94a92a9a-f53b-4d42-8d37-c243147a6d72%40googlegroups.com.

[codo dev]

Thanks, I will try contacting them! :) 

On Thursday, May 14, 2020 at 4:42:07 PM UTC-4, Cattus Thraex wrote:

I do not know Telugu, it is quite clear that you need an input method which cannot be created, I’m afraid, with UKELELE. Perhaps you should contact Apple engineering for this. Or Michael Everson:

http://evertype.com

On 14 May 2020, at 23:35, codo dev <codo....@gmail.com> wrote:

It can be! By looking at how current Telugu speakers use QWERTY to write their script in Roman (English) characters. There are many habitual ways of writing which are known to all speakers, so the keyboard can be condensed & arranged in a way that feels more natural to how the language is currently used. I've already created one potential layout concept..... but I'm sure it could be improved upon. 

Some examples.... in Telugu, each letter has a secondary form. So the keyboard currently looks a bit too busy. But it is possible to have a keyboard where every letter only shows the primary/base-form, but is coded to automatically output the correct form based on when it is typed.... Condition: If a vowel comes directly after a consonant, then it is secondary. If a vowel comes directly after a space, then it is primary. The only character that can follow a vowel is a consonant or a special vowel ("am" or "aha"). Syllable clusters always end in a vowel, except for at the end of a word where it can end with a consonant in base form using a virama....

Many vowels have a long-form. When Telugu is written in English, we can imagine these vowels as: a, aa, i, ii, u, uu, ru, ruu, e, ee, (ai), o, oo, (au), (am), (aha). As you can see, many of the vowels are simply a longer version and are usually written as doubled in English characters. So, what if a Telugu keyboard only had the short version: a, i, u, ru, e, o... Then the user simply taps the key once for the short version & twice for the long version. This user-experience relates the most to how Telugu is typed today using English characters - making the switch to the keyboard much more natural. It also more closely matches the experience of typing to how the characters are produced when speaking. The rhythm of typing would more closely match the rhythm of speaking. 

Also, all hard-breath consonants would simply be shift, which is how it is typically written in English texts when users can't add the dot below. It feels more natural to add something extra for a hard-breath consonant, as we add something extra when speaking. 

I am no scholar, but I did study music & percussion, which is all about how things feel... 

I believe we can find a way to make this happen. :) And I've definitely discovered a new passion through this project.

On Thursday, May 14, 2020 at 4:08:45 PM UTC-4, Cattus Thraex wrote:

Hm... I do not think that is can be ‘as simple as QWERTY’ for such a script.

On 14 May 2020, at 23:07, codo dev <codo....@gmail.com> wrote:

Unless we create a keyboard that feels as simple to use as QWERTY, it is unlikely that regular people will use it on a regular basis.

On Thursday, May 14, 2020 at 4:05:30 PM UTC-4, codo dev wrote:

The language is Telugu. 

On Thursday, May 14, 2020 at 2:37:50 PM UTC-4, Tom wrote:

What’s the name of the language you are talking about?

> On May 14, 2020, at 11:24 AM, codo dev <codo....@gmail.com> wrote:
>
>
>
> The reason that I am working so passionately on this project is because I'm working on an Indian language

--
You received this message because you are subscribed to the Google Groups "Ukelele Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ukelel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ukelele-users/9207817f-5543-4c7a-87b3-499606cc8fee%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Ukelele Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ukelel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ukelele-users/94a92a9a-f53b-4d42-8d37-c243147a6d72%40googlegroups.com.

[Sorin Paliga]

Do begin with Michael, he will probably be prompt in answering back.

To unsubscribe from this group and stop receiving emails from it, send an email to ukelele-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ukelele-users/18cb263e-9203-4ff1-84a6-c2610462368b%40googlegroups.com.

[Tom Gewecke]

Thanks for that info, the project sounds interesting.  It seems like you should be able to do something with ukelele.  Did you start from Apple’s Telugu Qwerty layout? Are you familiar with how that works?  Is your goal basically to eliminate the need to type viramas to create various forms?  

[Tom Gewecke]

> On May 14, 2020, at 1:35 PM, codo dev <codo.a...@gmail.com> wrote:
>

> Some examples.... in Telugu, each letter has a secondary form. So the keyboard currently looks a bit too busy. But it is possible to have a keyboard where every letter only shows the primary/base-form, but is coded to automatically output the correct form based on when it is typed….


Yes, I think it is possible, but perhaps too messy.

For example, right now you get the secondary form of a consonant by typing the virama before it, right? So if you make each consonant a dead key, which includes the base form plus virama, then the secondary form of the next consonant can be produced when it is the next character typed. But programming a keyboard full of deadkeys is tedious and may be hard to make work correctly in all circumstances.

[Tom Gewecke]

PS Are you familiar with the Lipika IME for Telugu?

https://github.com/ratreya/lipika-ime

https://github.com/ratreya/lipika-ime/wiki

https://github.com/ratreya/lipika-ime/wiki/Transliteration-Schemes

I have never tried it, but it may also be of interest for your project.

[codo dev]

I started with running 200million calculations on letter, double-consonant & syllable frequencies. Then I wrote the numbers on paper & tried to arrange the little squares onto the keyboard in a fashion that most-fit the letter-groups of the language (letters are grouped: vowels / consonants. Consonants are grouped by pronunciation & formation of the mouth). The arrangement would be new, but a Telugu touch-typing-tutor program would be created to help people learn the new arrangement which is more efficient based on frequencies.

It would be better to type without needing to add viramas as it's a bit of a hurdle to learn.... When the way we type is foreign in comparison to how we speak or write, it can be difficult to learn. 

On Thursday, May 14, 2020 at 5:21:53 PM UTC-4, Tom wrote:

Thanks for that info, the project sounds interesting.  It seems like you should be able to do something with ukelele.  Did you start from Apple’s Telugu Qwerty layout? Are you familiar with how that works?  Is your goal basically to eliminate the need to type viramas to create various forms?  

[codo dev]

Thanks, yeah, I think it would be a lot to code as well. The comment above about contacting Apple engineering seems best... Perhaps first I should create a keyboard via something like a Google Chrome Extension to get users, test the functionality & gain feedback. Then once there's maybe 1-2k users, present the issues to Apple, Microsoft & Unicode which need to be fixed in order to get the keyboard to function natively on all devices. 

On Thursday, May 14, 2020 at 5:38:54 PM UTC-4, Tom wrote:

[Tom Gewecke]

> On May 14, 2020, at 3:34 PM, codo dev <codo.a...@gmail.com> wrote:
>
> Perhaps first I should create a keyboard via something like a Google Chrome Extension to get users, test the functionality & gain feedback.

Let me know if you get something to test, I would be interested.

Personally I think Keyman might be the best approach in the end. Then you don’t have to worry about Apple, MS, or Unicode “fixing" anything, which I think is pretty much a hopeless endeavor.

[Patrick Chew]

Hello there!

I applaud your efforts to improve input methods for Telugu! and I wish you the best in your endeavors.

Some comments:

(1) your comment of trying to pre-calculate virama combinations is unfortunately slightly flawed—despite the overwhelming majority of consonant clusters being 2 consonants (CC), one does run across 3 consonant clusters (CCC) as well, cf స్త్రీ strī 'woman' and శాస్త్రము śāstramu 'science', ఇంద్రా Indra {a name}; this will make calculations unwieldy, especially when you have to consider not only "native" words, but also transcriptions of foreign words/names in context.

(2) there are differences in limitations with keyboarding on desktops/laptops versus mobile devices; mobile devices have it easier with press-and-hold technology that is facilitated by touch/gesture as a mindspace inherent and visually presenting subjoined/virama'd forms is easier;

(3) the Unicode Consortium, while taking input often into consideration, is *NOT* focused on input methods, but rather on ensuring that writing systems are digitally encoded in a way to be as loss-less as possible between computing devices, cf https://home.unicode.org/press/. As a participating member of the Script Ad Hoc Committee, issues of user behavior and input expectations come up all the time and are well taken into consideration when encoding a script or refining a script's extant encoding;

(4) input methods are the responsibility of the operating system, which means it usually lies in the hands of the manufacturers, ie Apple/Microsoft/etc or, in the case of open-sourced systems, in the hands of the developers.

What you're looking for, from what it sounds like, is an Input Method (similar to how Japanese kana, Korean hangeul, and Chinese characters are accessed), which a keyboard layout itself canNOT do.

Luckily for you, Apple does allow end users to create their own IMEs (just as it allows keyboard creation via tools like Ukelele), cf:
https://support.apple.com/guide/mac-help/create-and-use-your-own-input-source-on-mac-mchlp2866/mac

Unfortunately, for Telugu (and pretty much any other Dravida writing system, let alone other Indic scripts) the difficulty will lie in the dictionary lookup, given the relatively open set of an abugida, as opposed to anything syllable-delineated, e.g. a syllabary (Japanese and Tamil are good examples), a syllabo-morphic script (like Korean), or a syllable-associable script like Chinese. That said, it's not impossible...

cheers,

- Patrick

--

You received this message because you are subscribed to the Google Groups "Ukelele Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ukelele-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ukelele-users/73058a03-b229-4256-a5ac-7bfdbf4357c1%40googlegroups.com.

[codo dev]

Hi, yes, Telugu words can sometimes have more, it's just most commonly 2-consonant and even up to 5-consonants for words adapted from other languages. Luckly, the number of consonants in a cluster doesn't have too much impact on the way the keyboard would work. I've simply calculated frequencies to try to be sure that going from one-key to the next is somewhat comfortable. 

A mobile keyboard should be made available for users who prefer having identical keyboards across platforms, but I believe on mobile we can even rethink the keyboard layout yet again. As for laptops/computers, there is existing hardware we must adapt to, but on a phone, it's fully up to our imagination. 

Thank you for sharing about Unicode. I do not know very much. I'm simply passionate about improving the experience of typing in hopes of getting more people to type in the original script. But, I am no scholar, so no matter how many research papers I read or numbers I run on spreadsheets, I'll likely never know as much as the real professionals in this area. 

Korean Hangul seems to be the most related to these issues with Telugu. And I never would have thought to do something like this if I hadn't heard about how efficiently people can text in Chinese. I will research "IME's", thank you. Each new keyword learned is a path to researching more possibilities to make the keyboard happen. :) 

I'm very surprised to have found a community of people who seem so passionate about keyboards and the use of languages in technology. I wish I could have studied these things in school.... so fascinating. Thank you so much for the help! 

To unsubscribe from this group and stop receiving emails from it, send an email to ukelel...@googlegroups.com.

[codo dev]

Yes, of course, it would be very helpful to get your perspective & feedback once something is ready to test. I will checkout Keyman... And was also suggested to checkout React for creating a Telugu touch-typing-tutor. 

On Thursday, May 14, 2020 at 8:10:29 PM UTC-4, Tom wrote:

[Baskaran Sankaran]

Hi all,

Sorry to be picking up this older thread. I am currently trying something very similar for Tamil.

The goal is to keep only the basic phonemic units (vowels & consonants without virama) on the keyboard and create consonant vowels with an appropriate modifier based on the vowel that follows the consonant. codo.app.dev - would be glad to know your efforts for Telugu.

I also tried creating a custom input source (https://support.apple.com/en-in/guide/mac-help/mchlp2866/13.0/mac/13.0). Creating the rule file for the new input method was easy, and I just used UTF-8 instead of UTF-16 mentioned there. After installation, the file also appears in the "~/Library/Input Methods" folder as expected. However, it doesn't show up in the  'Input source' menu in "System Preferences > Keyboard" and I am not sure why.

Any help on either of these would be appreciated.

Thanks.

[Tom Gewecke]

> On Nov 10, 2022, at 10:38 AM, Baskaran Sankaran <bask...@gmail.com> wrote:
>
> I just used UTF-8 instead of UTF-16 mentioned there.

Why? If you used the .inputplugin format, it has to be utf-16 like says in the instructions.

[Baskaran Sankaran]

I initially tried UTF-16, which didn't work. I then realized that UTF-16 is meant for probably because of the Chinese use case in the example. So, I use the .cin format instead with the UTF-8. I have actually tried UTF-16 with LE/BE (BOM) and UTF-8 with & without BOM and none of them worked. By this, I mean I am able to install the .inputplugin or .cin file; but the input method wouldn't show up in the System Preferences.

I also tried restarting the machine a few times to see if that was the issue.

Thanks

[Tom Gewecke]

> On Nov 10, 2022, at 12:26 PM, Baskaran Sankaran <bask...@gmail.com> wrote:
>
> I use the .cin format instead with the UTF-8.

Did you actually convert your file to the .cin format? Apple’s note does not provide the info needed to do that.

[Tom Gewecke]

If you need them, instructions for the .cin format can be found at

https://chinesemac.org/pages/input_methods.html#cin

If you have like that, send me a copy and I  will see if it works for me.

[Baskaran Sankaran]

Thanks Tom. I could fix some issues with the .cin format.

Separately, I found out the reason the input source was not showing up in the Keyboard options. Basically, both .cin and .inputplugin options require at least one Chinese/ Japanese input source to be enabled. This has not been documented but is probably implicitly understood. Once I enabled the "Pinyin - Simplified" keyboard, my custom input sources got installed under that.

Here are my observations, for anyone trying out this approach for a non-CJK language.

• This approach is tied to some CJK input source to be enabled first
• Adding...
• Thirdly, the conversion doesn't happen dynamically and is triggered only when the space bar is pressed. This is a huge issue for typing in this approach for a language like Tamil.
• Both .cin and .inputplugin approaches don't seem to respect the upper and lower case differences in the mapping. However, there is some slight differences in the way these are handled by the two approaches.
• .cin: If I have separate mappings defined for 'vf' and 'vF' and it shows both the options irrespective of which of the two combinations I pressed. The options are presented below and I'll have to select the intended one thus requiring an additional effort from the user.
• .inputlogin: It seems to take the last definition for that combination. For example, I have different definitions for 'ng', 'Ng', 'nG' and 'NG' mapped to different characters. However, irrespective of the keys I pressed, it used the mapping of 'NG' as it was the last of these 4 combinations and other mappings simply got overwritten.

Attaching a few screenshots as some might find them useful.

Now that, I can rule out this, I am looking to try other options. I understand from the earlier discussions that Ukelele might not work for this case.

[Baskaran Sankaran]

One correction. When the .cin or .inputplugin files are installed, I believe they are installed under 'Chinese, Simplified' by default and not as a standalone input source. So, it is possible that I might have been looking for the custom source in the wrong place instead of under 'Chinese, Simplified'.

[Gé van Gasteren]

On Fri, Nov 11, 2022 at 8:53 AM Baskaran Sankaran <bask...@gmail.com> wrote:

Now that, I can rule out this, I am looking to try other options. I understand from the earlier discussions that Ukelele might not work for this case.

Do you know about Lipika IME?

https://www.facebook.com/groups/lipika.ime

https://opensourcelibs.com/lib/lipika-ime

[Baskaran Sankaran]

Hmm, I thought it was just based on some transliteration scheme. Didn't realize it is customizable. Will give it a try. Thanks.

[Tom Gewecke]

On Nov 11, 2022, at 12:53 AM, Baskaran Sankaran <bask...@gmail.com> wrote:

Now that, I can rule out this, I am looking to try other options. I understand from the earlier discussions that Ukelele might not work for this case.

You might want to check the Keyman app.  Unfortunately I think the Developer part only runs in Windows at the moment.

https://keyman.com