CLDR-17141 kbd: keep transform=no but document it

[srl295]

CLDR-17141

ALLOW_MANY_COMMITS=true

[mcdurdin]

I'd prefer to drop transform=no and simplify the mental model for keyboard authors. transform=no may seem simpler, but the caveats mean they have to have some grasp of transforms anyway, and then it just becomes an additional layer to remember.

[srl295]

@jahorton fyi

[jira-pull-request-webhook]

Notice: the branch changed across the force-push!

• common/supplemental/attributeValueValidity.xml is no longer changed in the branch
• docs/ldml/tr35-keyboards.md is different
• keyboards/3.0/fr-t-k0-azerty.xml is no longer changed in the branch
• keyboards/3.0/ja-Latn.xml is no longer changed in the branch
• keyboards/3.0/mt-t-k0-47key.xml is no longer changed in the branch
• keyboards/3.0/mt.xml is no longer changed in the branch
• keyboards/3.0/pcm.xml is no longer changed in the branch
• keyboards/3.0/pt-t-k0-abnt2.xml is no longer changed in the branch
• keyboards/dtd/ldmlKeyboard3.xsd is no longer changed in the branch
• keyboards/import/keys-Latn-implied.xml is no longer changed in the branch
• keyboards/import/keys-Zyyy-currency.xml is no longer changed in the branch
• keyboards/import/keys-Zyyy-punctuation.xml is no longer changed in the branch
• tools/cldr-code/src/test/java/org/unicode/cldr/unittest/TestDtdData.java is no longer changed in the branch
• tools/cldr-code/src/test/resources/org/unicode/cldr/tool/KeyboardFlatten/broken-import-missing.xml is no longer changed in the branch
• tools/cldr-code/src/test/resources/org/unicode/cldr/tool/KeyboardFlatten/broken-import-unknownbase.xml is no longer changed in the branch
• tools/cldr-code/src/test/resources/org/unicode/cldr/tool/KeyboardFlatten/broken-import-unknownver.xml is no longer changed in the branch
• tools/cldr-code/src/test/resources/org/unicode/cldr/tool/KeyboardFlatten/broken-import-wrongparent.xml is no longer changed in the branch

View Diff Across Force-Push

~ Your Friendly Jira-GitHub PR Checker Bot

[srl295]

@miloush thoughts here? @mcdurdin requesting to drop (meaning i can just remove this PR).

I agree that the complexity and limitations of transform=no make it very limited use, especially this:

the caveats mean they have to have some grasp of transforms anyway

As "syntactic sugar" it may not add a lot. Probably better to work on documentation, and tooling (including debugging and test environments, test cases, etc) for transforms.

[srl295]

@miloush Are you OK if we close this one (that is, drop transform=no) and merge #3330 ?

[miloush]

Oh sorry I meant yes, feel free to drop.

[srl295]

@miloush sorry, i merged the wrong PR 😆