Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementation considerations #4

Open
nciric opened this issue Feb 28, 2024 · 0 comments
Open

Implementation considerations #4

nciric opened this issue Feb 28, 2024 · 0 comments
Labels
discuss Discussion item

Comments

@nciric
Copy link
Contributor

nciric commented Feb 28, 2024

While we aim at a unified API solution in #3 , we should also recognize that different companies could have partial and proprietary solutions they would like to reuse.

ICU already has prior art solving the problem, e.g. transliterator and break iterator.

There are two cases we should consider:

  1. User is fine with defaults, uses code & lexicons provided by inflection project
  2. User has a better implementation for a set of languages, and overrides defaults for those languages only, The rest falls back on inflection defaults. User solutions can range from pure lexicon lookup, heuristics to ML models for more complex cases.

Inflection code shouldn't depend on user libraries, but it should provide registration APIs where they can hook up their implementation to be used with our APIs.

@nciric nciric added the discuss Discussion item label Feb 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss Discussion item
Projects
None yet
Development

No branches or pull requests

1 participant