Change Details

Split from bug 54022: apart from the 30 languages currently supported, rather than use the default analyzer bare we should probably use stopwords calculated in an automatic way, while we wait for a custom ones to be made. It seems cutoff_frequency setting and common_terms query may be used for this purpose. I'd say that this is currently low priority but should probably be done before expanding elasticsearch beyond the ~30 supported languages. -------------------------- **Version**: master **Severity**: enhancement **Whiteboard**: Elasticsearch_1.1 **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=54022 https://bugzilla.wikimedia.org/show_bug.cgi?id=66969

Split from bug 54022: apart from the 30 languages currently supported, rather than use the default analyzer bare we should probably use stopwords calculated in an automatic way, while we wait for a custom ones to be made. It seems cutoff_frequency setting and common_terms query may be used for this purpose. I'd say that this is currently low priority but should probably be done before expanding elasticsearch beyond the ~30 supported languages. -------------------------- **Version**: master **Severity**: enhancement **Whiteboard**: Elasticsearch_1.1 **See Also**: T56022 T68969

Split from bug 54022: apart from the 30 languages currently supported, rather than use the default analyzer bare we should probably use stopwords calculated in an automatic way, while we wait for a custom ones to be made. It seems cutoff_frequency setting and common_terms query may be used for this purpose. I'd say that this is currently low priority but should probably be done before expanding elasticsearch beyond the ~30 supported languages. -------------------------- **Version**: master **Severity**: enhancement **Whiteboard**: Elasticsearch_1.1 **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=54022T56022 https://bugzilla.wikimedia.org/show_bug.cgi?id=66969T68969