[ldml_test] add experimental/sil/ldml_test

[srl295]

• test out LDML keyboards in repo
• https://github.com/keymanapp/keyman/issues/10505

same as #2864 but in same repo

Fixes: #2484.

[DavidLRowe]

The convention for the keyboards repository is to store the keyboard in a folder based on the first letter or prefix, so: release/s/sample release/sil/sil_ipa

Following that convention, I'd expect experimental/l/ldml_test OR experimental/sil/sil_ldml_test

[srl295]

The main point was to test ldml. I expected there may be updates needed for local conventions.

Would sil_ldml_test make sense? I can rename it.

[DavidLRowe]

sil/sil_ldml_test would fit the pattern.

Is this intended to be an example? If so, sil_ldml_example maybe? Or is this the first of a suite of test keyboards? maybe a new folder "test": test/test_ldml (with test_ldml_xxx to follow)?

The concern is that current policy is to not change keyboard folder/project names once they've been created.

[srl295]

It's more of a test than an example.

[mcdurdin]

From the build log:

10:56:14   ldml_test.kpj - info KM05002: Building experimental/sil/ldml_test/ldml_test.kpj
10:56:14   ldml_test.xml - info KM05002: Building experimental/sil/ldml_test/source/ldml_test.xml
10:56:14   ldml_test.xml - info KM05006: experimental/sil/ldml_test/source/ldml_test.xml built successfully.
10:56:14   ldml_test.kps - info KM05002: Building experimental/sil/ldml_test/source/ldml_test.kps
10:56:14   ldml_test.kps - info KM05006: experimental/sil/ldml_test/source/ldml_test.kps built successfully.
10:56:14   ldml_test.kpj - info KM05002: Building experimental/sil/ldml_test/ldml_test.kpj
10:56:14   ldml_test.kpj - info KM05006: experimental/sil/ldml_test/ldml_test.kpj built successfully.
10:56:14   ldml_test.kpj - info KM0500B: Project experimental/sil/ldml_test/ldml_test.kpj built successfully.

[srl295]

I like the deprecated idea. Will update this.

[srl295]

How do we mark it deprecated?

[DavidLRowe]

The usual way this is done is for a keyboard to mark another keyboard as deprecated. In Keyman Developer (v17+) this can be done in the Packaging section, Details tab: Use Add to add a related package and tick the Deprecated box to indicate that this related package should be deprecated.

@mcdurdin Is is possible for a package to deprecate itself?

[mcdurdin]

srl295 requested a review from mcdurdin 1 hour ago

Still got some changes requested (plus this is in draft, so not clear if you intended to ask for review?)

@mcdurdin Is is possible for a package to deprecate itself?

I don't know! It'd be weird, and could have other side-effects, so I don't think I'm keen on doing that. So... despite my brilliant idea, I don't think we can go this way for now.

That is a weakness in the package-deprecation pattern, but it's not an easy one to solve without repetition of data... (DEPRECATED.md is informative only at this point, but we could test for its as a possibility?) Would add complexity to the keyboards build.

[mcdurdin]

That is a weakness in the package-deprecation pattern, but it's not an easy one to solve without repetition of data... (DEPRECATED.md is informative only at this point, but we could test for its as a possibility?) Would add complexity to the keyboards build.

• #2893

[srl295]

Yes apologies I missed the remaining items

Edit it won't let me rescind the request :)

[mcdurdin]

I think we can probably close this as redundant given #2993 is a real LDML keyboard, so I think we don't need a test keyboard in the keyboards repo.

[LornaSIL]

@srl295 can this be closed or are you still needing this open?

[srl295]

@srl295 can this be closed or are you still needing this open?

I think it's not needed.