Open henriquesposito opened 2 years ago
Yes, let’s try and keep this a pretty independent package, and of course we cannot rely on GitHub-only packages. Perhaps make each of these extensions an additional issue to better keep track of them? Or add them as checkboxes here:
I think this is a watershed feature for this package. Do we want to offer this as part of the package when we write up the paper, or is it a non-core addition?
I tend to agree, and I am not sure this is a core addition (I am not sure this would be getting into the paper). I think, since we are already getting spelled dates in text very well, we can think about adding or not these features at a later stage... For the future, maybe, we should contact the developer for unstruwwel and see if there are any plans to get the package on CRAN before starting to extend these functions.
Although we already do a very good job in expanding and converting dates from text, additional (more complex) types of dates in text (i.e. negative and/or historical dates, approximate dates, date ranges, and sets of dates) as
{unstruwwel}
does should also be added. The obvious choice would be to rely on the{unstruwwel}
package, but they are not on CRAN...https://github.com/stefanieschneider/unstruwwel