Looking through the notes from the meeting I also found some problems with
the collator. We did specify the collatorType: search, but we didn't offer a
function that would make use of it. Mark and I are thinking about:
/**
* string - string to search over.
* substring - string to look for in "string"
* index - start search from index
* @return {Array} [first, last] - first is index of the match or -1, last
is end of the match or undefined.
*/
LocaleInfo.Collator.prototype.find(string, substring, index)
We could also opt for iterator solution where we keep the state.
The reason we need to return both begin and end part of the found string is:
Look for *gaard* and we find *g**å**rd* - which may be equivalent in Danish,
but substring lengths don't match (5 vs. 4) so we need to tell user the next
index position.
The other problem Jungshik found is that there is a combinatorial explosion
with all ignoreXXX options we defined. My proposal is to define only N that
make sense (and can be supported by all implementors) and fall back the rest
to some predefined default.
--
Nebojša Ćirić
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
