@simoncozens Was there some rhyme or reason why 943e224 changed the hyphenation patterns used for transliterated Uyghur segments from Turkish to Lithuanian?

I'm sorry, I have no recollection why I did this. :-( When I did the original Uyghur hyphenation with Thomas Milo, he was insistent that we use Turkish for the dictionary.

Yes Turkish is the obvious right thing to base this on, I'm just mystified why it was then changed to Lithuanian.

I just checked out and built 943e224 and none of this works there. A few commits before in 2f273af hyphenating Latin alphabet Turkish input, but not the Arabic script Uyghur input. I've found some clues in what is obviously debugging code about what was expected, but there doesn't seem to be an end to end test that really worked. At best the original iteration would have sort of worked after loading the ug module, but thereafter left the default typesetter forever using the wrong break algorithm for all other languages.

I might ditch this PR and fix this on top of #2249 where the module layout actually provides interfaces to wire this is properly. Everything in here is a hack trying to override private functions without any way to revert them outside of processing Uyghur input.

https://designregression.com/article/breaking-arabic

Saving this issue for later as I don't want to mix up actual test expectation changes with the API changes, and this will be easier to fix after the other merge.

c.f. The example in the gallery on our website is clearly less than ideal if it is even functioning partially right at all: https://sile-typesetter.org/examples/global/