CLDR-17202 kbd: add Bengali (bn) keyboard

[srl295]

CLDR-17202

• This PR completes the ticket.

ALLOW_MANY_COMMITS=true

[miloush]

Where are the key ids from? They seem to be in some sort of transliteration scheme but then there is ch, sh, w etc.

[srl295]

Where are the key ids from? They seem to be in some sort of transliteration scheme but then there is ch, sh, w etc.

wikipedia

[miloush]

heh that page is tagged with this issue, also from the Talk page:

this article needs serious cleanup, it appears to be using some sort of home-grown transliteration scheme at present.

I would be quite uncomfortable having this scheme, could we use one of the established ones? (ISO15919 if it was up to me, or I could live with ALA-LC too)

[srl295]

heh that page is tagged with this issue, also from the Talk page:

this article needs serious cleanup, it appears to be using some sort of home-grown transliteration scheme at present.

I would be quite uncomfortable having this scheme, could we use one of the established ones? (ISO15919 if it was up to me, or I could live with ALA-LC too)

ok. i might use ala-lc as i have worked with that one.

[srl295]

I'll use the ALA-LC table at https://www.loc.gov/catdir/cpso/romanization/bengali.pdf

One of the test failures seems to be a CLDR bug, tracking at https://unicode-org.atlassian.net/browse/CLDR-17204

[miloush]

I checked and the only substantial difference between ALA-LC and ISO15919:2001 is sha in ALA-LC and ṣa in ISO-15919.

EDIT: other difference is ṁ vs. ṃ for anusvara

[srl295]

will need to borrow this one from the Assamese table

<key id="wa" output="ৱ" /> <!-- Assamese-->

[miloush]

ISO15919 has this one:

[srl295]

Chart so far

[miloush]

could just be id="candrabindu" and avoid comment

[srl295]

This is per romanization table

[miloush]

just wanted to double-check we want encourage people to be entering E+AU LENGTH MARK rather than VOWEL SIGN AU (the spec says length mark exists for compatibility and does not have a meaning on its own)

[srl295]

I wasn't able to verify this one yet.

[srl295]

You're right ,Not sure what that one was doing here. I'll remove it.

[miloush]

Just to make it clear, the situation is:
A -> SIGN AA
SHIFT+A -> AU MARK

Q, A -> LETTER A
Q, SHIFT+A -> LETTER AA

(notably Q and long sign produce short letter unlike Q in combination with everything else)

[srl295]

This does match the upstream

[miloush]

OK I checked the assignments. It's a bit difficult to review though, why would you order the keys in bag in layout order rather than [Brahmic] alphabetical order?

This probably should have a rupee sign.

[srl295]

Still todo

• Tests
• Add reorder rules

[srl295]

OK I checked the assignments. It's a bit difficult to review though, why would you order the keys in bag in layout order rather than [Brahmic] alphabetical order?

It was for ease of entry. I can sort them now though.

This probably should have a rupee sign.

So as with a number of other comments: this is a port of an existing keyboard file (see link in xml). I'm fine with improving it, just noting that step 1 is a port.

Thanks for the comments and thorough review. I'll keep working on it.

[srl295]

here's a screenshot of a Windows system typing using this keyboard.

[jira-pull-request-webhook]

Hooray! The files in the branch are the same across the force-push. 😃

~ Your Friendly Jira-GitHub PR Checker Bot

[srl295]

rebased and should build clean. @miloush or anyone can I get an approval on it?

[srl295]

• comment transforms / reorder

[jira-pull-request-webhook]

Hooray! The files in the branch are the same across the force-push. 😃

~ Your Friendly Jira-GitHub PR Checker Bot

[srl295]

@miloush and @mhosken i've attempted to document the reorder rules.

[jira-pull-request-webhook]

Notice: the branch changed across the force-push!

• keyboards/3.0/bn.xml is different

View Diff Across Force-Push

~ Your Friendly Jira-GitHub PR Checker Bot

[srl295]

i'm tracking a build issue causing kbd-check to not work in keymanapp/keyman#10111

[miloush]

Did we say the processing turns everything into NFD? Are the reordering matches done before or after that? Or are the match expressions also normalized? Because 9CB O/9CC AU which are under right side vowels decompose into left+right side vowels, in the latter case the right one being 09D7 AU LENGTH MARK which is not part of the rules.

We don't care about characters not entered through the keyboard (like using Alt+Numpad), correct? (especially thinking about Vedic marks)

[srl295]

I'm working on a document for review on normalization https://unicode-org.atlassian.net/browse/CLDR-17192

Did we say the processing turns everything into NFD?

We will say that the match acts as if it's in NFD.

Are the reordering matches done before or after that?

Matches will be in NFD

Or are the match expressions also normalized?

and the expression will be normalized also.

Because 9CB O/9CC AU which are under right side vowels decompose into left+right side vowels, in the latter case the right one being 09D7 AU LENGTH MARK which is not part of the rules.

I think I, earlier, removed 09D7 due to normalization. But I should re-add it for this reason.

We don't care about characters not entered through the keyboard (like using Alt+Numpad), correct? (especially thinking about Vedic marks)

The reorder rules (being script specific) are eventually supposed to be imported data separate from the keyboard proper. But besides that, someone might enter something with Alt-numpad and then click and type. Just like I could type e and then click after it, and then type a combining grave. I don't think the transform rules per se need to handle everything in the script but they should handle everything that the language is likely to encounter. The reorder rules should (though perhaps not in this keyboard) handle everything in the script.

[srl295]

@miloush PTAL, U+09D7 is now included in the reorders

[srl295]

@miloush OK to merge?

[srl295]

@miloush thanks!