You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
translation audit tool lack considering ordering of rules #619
In overview.yaml, there is a line - include: "SimpleSpeak_Rules.yaml"
put this line at top or bottom of overview.yaml will have a different behavior in navigating math content.
once we would consider the order, will there also be a need for a an ignore-marker for the auditing tool, e.g. for when there is an extra rule that would shift every following item back by one position?
how often is there a need to change rule order generally? can you give me some examples so I can get a feel for how that works like in practice?
@NSoiffer what do you think about how to implement such a thing? using a list instead of dict as container and then reporting the first differing index is pretty straightforward, but once you want to consider stuff like detecting extra-items etc., you start getting in the realms of minimum edit distance metrics, a la Levenshtein distance, at least from what it looks like to me
@hjy1210 items of the form - include: xyz are not yet supported, as I focused on rules of the usual name/tag/match/replace/... structure.
Is - include the only other "rule type" to consider, or are there even more?
Technically, it is not really a rule in itself, as it only points somewhere else, so I'd need to unfold that recursively in the parser to get the actual rules the include-statement points towards. bothering you again, what do you think @NSoiffer ;)
Speaking for myself, I think an altered order of the rules would be a rather rare case. The most common scenario I can think of is if you would add a new rule to your translation and accidentally place it in the wrong order, which then might affect when it is triggered. There might be exceptions where you'd deliberately want to change the order of the rules, so # audit-ignore would be good to be able to use for order as well. I can't think of any concrete examples, though.
after thinking about this for a bit, I think a pragmatic way to do this is to:
only consider rules that are present in the files for both languages, in both cases not marked as # audit-ignore
to then check if their order is exactly equal, or if not, at which index they first diverge
enable it by default, or disable with a flag like --ignore-rule-order.
Does this plan sound good? @hjy1210 is this close to what you had in mind?
this does not cover the include statement that you mentioned though. as it is not a rule like the other objects in the file, this would introduce a lot of complexity, and in 99% of cases it should be at the top of the file anyway I think.
Activity
TimArborealis commentedon Jul 1, 2026
I agree that it would be useful if the audit tool would catch differences in the order of the rules.
moritz-gross commentedon Aug 6, 2026
right now, rule order is not considered at all.
once we would consider the order, will there also be a need for a an ignore-marker for the auditing tool, e.g. for when there is an extra rule that would shift every following item back by one position?
how often is there a need to change rule order generally? can you give me some examples so I can get a feel for how that works like in practice?
moritz-gross commentedon Aug 6, 2026
@NSoiffer what do you think about how to implement such a thing? using a list instead of dict as container and then reporting the first differing index is pretty straightforward, but once you want to consider stuff like detecting extra-items etc., you start getting in the realms of minimum edit distance metrics, a la Levenshtein distance, at least from what it looks like to me
moritz-gross commentedon Aug 6, 2026
@hjy1210 items of the form
- include: xyzare not yet supported, as I focused on rules of the usual name/tag/match/replace/... structure.Is
- includethe only other "rule type" to consider, or are there even more?Technically, it is not really a rule in itself, as it only points somewhere else, so I'd need to unfold that recursively in the parser to get the actual rules the include-statement points towards. bothering you again, what do you think @NSoiffer ;)
TimArborealis commentedon Aug 11, 2026
Speaking for myself, I think an altered order of the rules would be a rather rare case. The most common scenario I can think of is if you would add a new rule to your translation and accidentally place it in the wrong order, which then might affect when it is triggered. There might be exceptions where you'd deliberately want to change the order of the rules, so
# audit-ignorewould be good to be able to use for order as well. I can't think of any concrete examples, though.moritz-gross commentedon Aug 23, 2026
after thinking about this for a bit, I think a pragmatic way to do this is to:
# audit-ignore--ignore-rule-order.Does this plan sound good? @hjy1210 is this close to what you had in mind?
this does not cover the
includestatement that you mentioned though. as it is not a rule like the other objects in the file, this would introduce a lot of complexity, and in 99% of cases it should be at the top of the file anyway I think.moritz-gross commentedon Sep 23, 2026
should be done