Deprecating gff.ti.gff_tigrinya

[dyacob]

The gff.ti.gff_tigrinya lexical model is based on the Unilex project's wordlist for Tigrinya. Unfortunately, the contents contain many misspellings and non-Tigrinya words that come corpus of unknown provenance and pedigree. The contents also combine conflicting spelling conventions of both Eritrea and Ethiopia which also impact the frequency counts negatively.

An approach that would better meet user expectations is to have separate wordlists for each region. PR #216 and #217 address this directly. The gff.ti.gff_tigrinya lexicon can then be deleted from the repository or moved into a legacy directory if there is interest to preserve it.

[DavidLRowe]

@mcdurdin What is the best way to proceed?

[DavidLRowe]

Note that the PRs for the new models have not yet been merged.

[mcdurdin]

We can use the deprecates field in the .model_info for the new models to mark the existing model as deprecated. Then we should be able to remove it -- there is probably not a lot of value in keeping the older model around, unlike with keyboards. (The old version will still be on the download server, but it won't be in the catalogue so users won't be offered it.)

[dyacob]

@mcdurdin , my main concern is to avoid the keyboards downloading both dictionaries. Will the dictionary server be aware of the deprecates property and prevent the older wordlist from being downloaded? If not, then deletion from the repository might be the better option.

[mcdurdin]

Will the dictionary server be aware of the deprecates property and prevent the older wordlist from being downloaded?

Yes, the only model to be downloaded should be the new one, as deprecated models are not offered in the search by language API.

[dyacob]

With the v1.0.1 versions of the respective lexical models, the deprecates statements are in place.

I can create a new PR that deletes the older Tigrinya lexical model, or leave it to the Keyman team to delete older resources at the appropriate time.

[DavidLRowe]

@mcdurdin Will it be a problem to have statements that deprecate a lexical model that no longer is present in the repository?

Or maybe it would just be tidier to remove the deprecations in the same PR that deletes the lexical model?

[mcdurdin]

It's best to leave the deprecation references in, because this allows for a clean upgrade path for users who are on the older model -- a query for updates for the deprecated model reports that a replacement model is present. (Although perhaps we need to go through and re-test this at some point, because it's been a long time since we've done anything with it, and at that point we didn't have any deprecated models...)

[dyacob]

I suppose a DEPRECATED.md file is in order then?

[DavidLRowe]

@mcdurdin Should a DEPRECATED.md file be added to the deprecated lexical model? Or just delete it?

[mcdurdin]

@mcdurdin Should a DEPRECATED.md file be added to the deprecated lexical model? Or just delete it?

I think it would be fine to delete it, as the new model lists the deprecation path. The old model is available in the git history for archival/history purposes, and as far as I can tell, we'll never want to serve it to users. So go ahead and delete it.

[dyacob]

I forgot we had this conversation in 2023. @DavidLRowe rather than process #331 , you can delete it.