It would be very good to get a default field type defined for Japanese in schema.xml so we can good Japanese out-of-the-box support in Solr.
I agree, we really need this for all languages, including stopwords_xx files and fieldtypes actually,
but lets start with japanese because its complicated.
I've been playing with the below configuration today, which I think is a reasonable starting point for Japanese. There's lot to be said about various considerations necessary when searching Japanese, but perhaps a wiki page is more suitable to cover the wider topic?
I think the ideal situation would be to have a single reasonable default (like the configuration you have), but then also a
full wiki page on Kuromoji explaining the different options, maybe even with alternative configurations or examples. we could
link to this page from the other wikipages about the analyzers.
In order to make the below text_ja field type work, Kuromoji itself and its analyzers need to be seen by the Solr classloader. However, these are currently in contrib and I'm wondering if we should consider moving them to core to make them directly available. If there are concerns with additional memory usage, etc. for non-Japanese users, we can make sure resources are loaded lazily and only when needed in factory-land.
Yeah I don't think having kuromoji in contrib is ideal. I think instead we should have examples for all supported languages
so its easy to get started. Currently someone has to jump thru serious hoops to segment chinese or japanese into words,
but as I mentioned before all non-english languages currently are 'hard' in that there are no fieldtypes setup for them.
but anyway, my vote is to move these analyzers to core and nuke this contrib totally. But it would be great for some
people to speak up and get consensus on this because it would only be more confusing to go back and forth between
contrib and core.
As far as the default configuration,
Christian maybe if you have some time you could look at/review the stopTags.txt we have in the analyzer right now?
I created this file from the ipadic manual (there could/likely are silly errors too), in an attempt to also document the POS tagset.
But we should also see if the uncommented POS tags in that file are appropriate for a 'good stop set'. I think i just arbitrarily
picked a few trying to be conservative.