Closed wanasit closed 1 year ago
One limitation is that the parsers don't provide the translated casual reference. Translation would need to be done in user-land.
Yes. I'm afraid that is the case.
Providing translation or date formatting (back into localized human-readable) is not want I am willing to support inside Chrono for now. I hope there are other libraries that are more specialized in doing that, or you have to add that on your application side.
That said, after you try adding the translation to your application, if you still think it is more fitting to support that feature inside Chrono. I'm open to the discussion.
Another option would be to turn tags into an object instead of an array.
I am also considering having a value associated with the tag (aka. defining tags
as Map
, not Set
), but that feels it could get over-complicated. If different tags from different parsers/refiners can have different values, that would be difficult to keep track of.
Let me try a few more ideas and fix the issues. I plan to release the feature next week.
Agreed.
Honestly I think tags as currently implemented are already enough (I think the naming inconsistencies discussed in the comments need to be adressed though).
Thanks for the discussion and your help 🙏
Parsing Tags
A parsing tag or just "tag" is a string attached to parsed components (and results) by parsers and refiners for additional information about the location and context where components were created or modified.
Potential Usage
Debugging Extraction:
Inside Chrono, multiple parsers and refiners work together to produce the result. Identifying which component(s) output the incorrect results is challenging.
By tagging the result with involved parsers and refiners, it should be easier to identify the area to fix from the bug report or debug log:
Recognizing results "types" (or "categories")
These is the list of example ideas: