-
Notifications
You must be signed in to change notification settings - Fork 23
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
Refactor shaping and encoding checks structure #175
Comments
We would like to move to a more general model for checks that would entail:
We prefer to run these checks automatically based on the language definitions rather than list those checks for each language. The advantage is better scalability and resistance to human errors (we welcome non-technical contributors). |
My idea for this was to implement different kind of checks as python classes with a common signature. The checks would have access to the Shaper to implement any checks as needed when passed a set of characters. To avoid over-explicit definitions of what checks should run for what languages, I was considering a kind of matching mechanism where each check out define a set of conditions. When a check's conditions are met for a language, run it. Such conditions could be:
So for example, a general encoding check would trigger for any presence of One additional thought could be returning more nuanced verdicts than just pass/fail, or return pass/fail plus textual information. E.g. for conjunct checks a pass may be based on a threshold, so informing the user about those details might be necessary. |
This is implemented but WIP in this branch. |
No description provided.
The text was updated successfully, but these errors were encountered: