Closed Lucashph0241 closed 6 months ago
I don't think I can fix this until I do the work for #205, and even then it might require manual intervention. It's not smart enough to know when () is used in a different context than a pronunciation guide, although I could work on fixing it for power markers since it understands what that is.
Looking at this again. For power markers, did your game format support powers? When I try it out the color is correct when power markers are specified (like with mACF with powers), but not for formats where there are no power markers.
Oops my apologies, I forgot to switch the format to mACF with powers when screenshotting. All other issues still apply.
I think the best (least ambiguous and easiest to implement now) solution is to constrain pronunciation guides to only apply to text that is wrapped inside the two delimiters (“
”)
i.e. parentheses with quotation marks. The current parser, using delimiters of (
)
parentheses alone, is overzealous and results in substantive words that cannot be clicked on. While not common, examples from last weekend include lead(II)
and Ru(bpy)3
, which are chemical formulas, and On the Plate (Without the Plate)
, which is a work title.
Packets that use (
)
can migrate to the less ambiguous notation if they want pronunciation guides to be automatically detected by parsing tools, in my opinion.
I think the best (least ambiguous and easiest to implement now) solution is to constrain pronunciation guides to only apply to text that is wrapped inside the two delimiters
(“
”)
i.e. parentheses with quotation marks. The current parser, using delimiters of(
)
parentheses alone, is overzealous and results in substantive words that cannot be clicked on. While not common, examples from last weekend includelead(II)
andRu(bpy)3
, which are chemical formulas, andOn the Plate (Without the Plate)
, which is a work title.Packets that use
(
)
can migrate to the less ambiguous notation if they want pronunciation guides to be automatically detected by parsing tools, in my opinion.
Is it common for pronunciation guide markers to use (" and ") as the delimiters? This is technically supported today, although you have to update the game format to use them as the pronunciation guide markers. If it's common I could make it the default delimiter. A better approach would be to make game formats carry over, or get included in the packet.
Yes.
One downside is that some packets use non-formatted quotes (") and others use formatted quotes, and MDOAQ only supports one set of pronunciation guide markers, so it'll be more hit-and-miss depending on the packet formatting.
Surely this can be solved by a basic regular expression: [([][“"]
,[”"][)\]]
? I guess you'd have to change the interface from the current two comma-separated strings, or if not, just match any quotation mark like how there is toLowerCase
normalization for tags: https://github.com/alopezlago/MODAQ/blob/a2f429856550951467e86021e1b4629aeea7b715/src/parser/FormattedTextParser.ts#L81-L85
FWIW two considerations:
non-clickable bracketed instructions read slowly
, pause
, emphasize
can be handled separately. Generally don't have to use the same type of brackets as for PGs. Example (also shows unusually colored power mark):
(“foo)
or (foo”)
but this is among plenty of other typos of the same type (two opening or two closing parentheses, answerlines or notes missing a closing bracket, etc.)FWIW two considerations:
- non-clickable bracketed instructions
read slowly
,pause
,emphasize
can be handled separately. Generally don't have to use the same type of brackets as for PGs. Example (also shows unusually colored power mark):- most recent tournament I read had a decent number (5ish) of PGs with one quotation mark missing:
(“foo)
or(foo”)
but this is among plenty of other typos of the same type (two opening or two closing parentheses, answerlines or notes missing a closing bracket, etc.)
Parrt 1 is done, though I need to still make the default ("/"). I don't know if I'll tackle part 2, that adds a lot of complexity with the way it's currently handled (where pronunciation guides can be generic instead of always () or []).
Part 1 is done with ("/") being the default now. I don't think I'll handle the second point now unless it becomes high priority. I'll close this issue for now.
See title. Below is an example of this. This also occurs at power markers.