Closed parker57 closed 6 years ago
Good point.
It was mainly for #8. The main example I can think this would be useful is:
$ python -m ety -t america America
No origins found for word: america
America (English)
└── Americus (English)
But I agree that we should probably revert this change.
For the API, I'd probably suggest case-sensitive always.
For the CLI, could possibly have a "did you mean ... ?".
Yeah I agree, although for use via the Python API I think having an ignore_case
/case_insensitive
or something param would be a good addition
I'm not sure about making the module case insensitive like in #39, It might be a good idea to have a case insensitive option or to look for a lowercase version of an English word if the version presented yields no results. There are however a few words I can think of that have distinct etymologies but would be identical if rendered in lowercase.
Here are a few examples,
wasp annoyingly isn't in the data but WASP (acronym for white anglo-saxon protestant) is.
Turkey refers to a country, we get the word turkey from Turkey but it's the large guinea fowl that I guess Turkish people sold.
wed is a verb, "to marry", Wed is an abbreviation for the third day of the week from Woden
There are over a thousand such examples in the English language and it's important to remember that most of the words in the data aren't English, I don't know how important case sensitivity is for the other 255 languages.
Personally, for now I would leave it case sensitive, users can always make the words they parse into our functions lowercase if they want to anyway.