CLDR-12026 kbd: add proper azerty-optimisé

[srl295]

• rename the existing fr-t-k0-azerty to fr-t-k0-test because it's really a test keyboard.

• fr-t-k0-test.xml is used in unit tests, which update

• add a proper optimisé keyboard (see ticket)

CLDR-12026

• This PR completes the ticket.

ALLOW_MANY_COMMITS=true

[srl295]

Chart so far: (updated)

[srl295]

@azmeuk any comments on this? The draft spec for this is https://cldr-smoke.unicode.org/spec/main/ldml/tr35-keyboards.html

you can see the generated chart above - \m{caret} and \m{umlaut} are markers that will combine to form ^ and ¨ modifiers.

[jira-pull-request-webhook]

Notice: the branch changed across the force-push!

• keyboards/3.0/fr-t-k0-test.xml is different
• keyboards/test/fr-t-k0-optimise-test.xml is different

View Diff Across Force-Push

~ Your Friendly Jira-GitHub PR Checker Bot

[jira-pull-request-webhook]

Notice: the branch changed across the force-push!

• tools/cldr-code/src/main/java/org/unicode/cldr/util/ElementAttributeInfo.java is different

View Diff Across Force-Push

~ Your Friendly Jira-GitHub PR Checker Bot

[jira-pull-request-webhook]

Notice: the branch changed across the force-push!

• tools/cldr-code/src/main/java/org/unicode/cldr/util/ElementAttributeInfo.java is different

View Diff Across Force-Push

~ Your Friendly Jira-GitHub PR Checker Bot

[srl295]

I'll update the chart

Chart above has been updated

[srl295]

@azmeuk I think all of the base characters are in now. (just needs transform rule)

[azmeuk]

@azmeuk I think all of the base characters are in now. (just needs transform rule)

Thank you. I will try to find some time this week or the next to review this.

[srl295]

rebased due to #3274

[srl295]

out of date, I think this is probably going to go to v45

[azmeuk]

As I finally could not find time to dedicate on this since last summer, I called people behind https://norme-azerty.fr/en/ for help.

[dan-jac]

The dot above dead key has a special case that I don't think is captured here – it should produce a dotless i (U+0131) when followed with a lowercase i.

[srl295]

TODO but that is easy to do in this format

[srl295]

@dan-jac thank you for the feedback!

[dan-jac]

@dan-jac thank you for the feedback!

No worries. Happy to help. I implemented the Windows driver based on the standard document, so I'm quite familiar with it at this point.

I must admit, I haven't yet familiarized myself with this new version of the LDML format, so my feedback is based on what I think it's saying.

For accent dead keys, is each mapping supposed to be explicitly listed? (In which case, this file is obviously not yet finished. Which is fine. 🙂) Or are they implicit (like with X11 keyboard maps), in which case special cases need special attention?

[srl295]

For accent dead keys, is each mapping supposed to be explicitly listed? (In which case, this file is obviously not yet finished. Which is fine. 🙂) Or are they implicit (like with X11 keyboard maps), in which case special cases need special attention?

I'm using combining accents where I can.

so

			<transform from="\m{umlaut}($[vowel])" to="$1\u{0308}" />

.. just puts a U+0308 after the vowel.

[srl295]

@dan-jac updated the XML, take a look

[dan-jac]

For accent dead keys, is each mapping supposed to be explicitly listed? (In which case, this file is obviously not yet finished. Which is fine. 🙂) Or are they implicit (like with X11 keyboard maps), in which case special cases need special attention?

I'm using combining accents where I can.

so

			<transform from="\m{umlaut}($[vowel])" to="$1\u{0308}" />

.. just puts a U+0308 after the vowel.

The standard requires the use of pre-composed accented characters. It also requires the use of a 'dead key' ( « touche morte » ) as the means of entry, as defined in ISO/IEC 9995-11 paragraph 5.1.

Annex E of the standard (which is normative) lists all of the required Unicode code points of the pre-composed accented characters that must be made available.

E.g.

• A with grave accent is U+00C0.
• A with aigu is U+00C1.
• A with circumflex is U+00C2.
• etc.

[dan-jac]

All of the changes introduced in this PR are good and get this closer to compliance with the standard. So in that sense, I approve! :)

As I've noted in a comment though, this doesn't mean it's actually compliant yet. (E.g. To be truly compliant, it would need to provide access to all the precomposed accented characters, not just the combining characters.)

[miloush]

@dan-jac the spec mandates everything will become precomposed during processing unless the layout opts out.

The marker is used as a dead key (key will insert marker which user cannot see and then the next output will transform it).

[srl295]

As @miloush noted this standard usually works in NFD. Each char in the "composable" set can be preceded by a marker to produce char + combining char for all base keys.

[srl295]

@miloush can I get your stamp on this also so we can merge now that @dan-jac has approved?

[srl295]

@dan-jac I don't have a copy of the standard so can't check actual compliance yet. I'd like to port some of the compliance tests I see floating around and test them here.