Summary: Initialise Time for CA (Catalan) language
Reviewed By: stroxler
Differential Revision: D28455273
Pulled By: chessai
fbshipit-source-id: be9a4d61692ba4fb32986e161e9fdd6d25a357dc
Summary: There are different implementations of isRangeValid that work well for different languages, thus it makes sense to facilitate having different implementations based on the language.
Reviewed By: patapizza
Differential Revision: D28362777
fbshipit-source-id: 5f2991d54af3095c8e95cf534e2dd3b4a34dee3a
Summary: Initialise Temperature for CA (Catalan) language
Reviewed By: stroxler
Differential Revision: D28298423
Pulled By: chessai
fbshipit-source-id: 73b87d002196b6b707388e9f83f42591510f40eb
Summary:
This commit extend Spanish-language support for concatenations
of the form "<higher-order-of-magnitude> <lower>", e.g.
"doscientos tres" (203) or "cuatro mil ventiuno" (4022) to work
not just for hundreds but also for thousands and millions.
Reviewed By: chessai
Differential Revision: D27858133
fbshipit-source-id: 5c6b227ae7dad9009cd636e7ea49c209480c931a
Summary:
This commit adds two things to Spanish numeral support:
- support for millions
- support, via hooking into the `isMultipliable` logic used by EN, for
composing counts of 2-999 with either "mil" or "millones", which is
the standard way to say things like "tres mil" = 3000
Reviewed By: chessai
Differential Revision: D27858135
fbshipit-source-id: 980e95bd989f818c5ceaa2bb6c87fe81d3e08366
Summary:
This diff refactors our handling of "<hundreds> 0..99" numbers
to be more flexible by replacing `ruleNumeralthreePartHundreds`
with
- a rule for two-part hundreds like "dos cientos" (which is technically
incorrect grammar - doscientos is correct - but probably worth keeping) based
on a notion of multipliability like that used in EN rules
- a rule stating that we can compose hundreds with 0..99 additively
The resulting rules are more flexible, and they correctly parse not only
gramatically iffy phrases like "dos cientos tres", but also grammatically
correct phrases like "doscientos tres". This fixes#380.
Reviewed By: chessai
Differential Revision: D27858136
fbshipit-source-id: 4a918d84d93ac074f83f6947a8f80cfd11145115
Summary:
It's common to use dashes when spelling out times longhand,
e.g. "five-thirty am", but Duckling wasn't handling this at all.
This commit adds rules for times spelled out with dashes. The
rules explicitly forbid the second of the two times from including
digits via a negative match. This is because
- it wouldn't be at all idomatic to write five-26 or five-oh-6
- allowing that pattern clashes with time range parsing, e.g.
"9-10 am" should parse as a time range, not as "9:10 am"
Reviewed By: chessai
Differential Revision: D27848428
fbshipit-source-id: dfe8b98cb38119a16db2a19db47fd3128783e617
Summary:
This commit fixes#111, which was an open issue that any non-integer
multiple of any unit of time was being converted to seconds.
My solution is to write a recursive function `Duration.Helpers.inCoarsestGrain`
which, given a grain `g` and double value `v` finds the coarses grain `g'` such that
`v * g` - rounded to the nearest seconds - has integral units.
We call this function only in the case of non-integer multiples, and we start our
search from the given grain because nothing coarser would make sense. The code could
actually be slightly more efficient if we started at the next-smallest grain, but
in the interest of clarity I think this is probably better.
Reviewed By: chessai
Differential Revision: D27891439
fbshipit-source-id: b048310963eb71337fd91ab4ef3c840134a76e73
Summary:
While debugging an attempt to extend our handling of spelled-out
times, I realized that we are being too aggressive in our parsing of
times like "five ten", because we'll parse "five nine" as possibly
meaning "5:09", which isn't something an English speaker would say
(or rather if they did, it's more likely they mean "five (to) six"
or something similar.
Reviewed By: chessai
Differential Revision: D27848429
fbshipit-source-id: 34d783332fd60359ad9b6e7862367453bc93a1d1
