Hello,
I'm working on addressing some performance issues that we have noticed with setrans. Overall, I'm making good progress and hope to be able to submit some patches to that effect in the future.
I'm writing now to clarify the desired behavior of trans_context().
1) It is currently possible to have some modifier words set a category c1, and have other modifier words unset the same category. Using this (and the ability for modifier words to set multiple categories at once), you can create a config that makes computing translations a pretty complicated puzzle. The current implementation does not handle this situation well. I'm wondering if it would be okay to simply forbid this situation?
2) Since modifier words can effect multiple categories, it is possible that the selection of words is ambigous. The current approach to this is to roughly to greedily follow the below rules:
- Select the word which results in use being the closest to the desired level.
- If there are multiple such words, select the one which was defined first.
If you look at the nato example, these heuristics mean that it is important that rel.conf be included before eyes-only.conf. Otherwise, you would select a single word from rel because of c200, then pick the rest of the words from eyes-only.
There are two changes I am planning on making regarding this:
- Select a word based on how much it differs from the base classification in use. This way words still get "credit" for (un)setting a category, even if another word has done so. This would make the nato example work regardless of what order rel.conf and eyes-only.conf are included.
- Iterate through categories sequentially and select words from the set that fixes the category we are looking at. This change is being done purely for reasons of efficiency. It is possible to construct a configuration where this gives a different result from selecting from the set of words that fixes any category, but I think the configs that do so are rather contrived.
3) Once the base classification and words are selected, the order they are displayed in is never explicitly defined. I'm planning on making them be displayed in the order in which they were defined in the config.
Are there any questions or concerns with any of these decisions before I go too far down this rabbit hole?
Thanks,
Brandon
