On 2018-06-21, Shad Storhaug wrote: > There are still many undecided issues regarding the ICU functionality. For > example:
> 1. Should we use the newly ported ICU4N > (https://github.com/NightOwl888/ICU4N) project or try to add the > functionality to the already existing icu.net project > (https://github.com/sillsdev/icu-dotnet)? Note the latter has been attempted, > but there are several issues (missing functionality, incompatibilities, > problems loading data) that make it very challenging to provide all of the > Lucene.Net.ICU functionality - it was easier to get it working by porting > from ICU4J, but will require maintaining the ICU4N project. > 2. If we use ICU4N, should we make it into a general library that benefits > all of the .NET ecosystem, or should we limit it to primarily support > Lucene.NET? I'm not doing any of the work, so take this with a big grain of salt. Right now I'd focus on what is best for Lucene.Net and try to safe the (.NET) world later. To me it looks as if going with ICU4N in its current state is the best short term option. If you want to turn ICU4N into something useful then this sounds (1) very useful and (2) like a lot of work. Most likely the people who'd want to contribute to ICU4N and Lucene.Net are not the same (apart from yourself), so I'd separate growing ICU4N from which version of ICU4N Lucene.Net should use. We can probably switch to a more full-blown version of ICU4N if/when such a beast eists. Most probably I'm missing something. > Basically, there are 3 ways to complete this: > 1. Add the required functionality to the icu.net project in order to support > the Lucene.Net.ICU features, port the missing Lucene.Net.ICU features to the > current master branch and abandon work on ICU4N. > 2. Finish up the API and fix 19 failing tests to make ICU4N good enough to > support Lucene.Net.ICU without making it into a first-rate component that > supports all ICU features. > 3. Contact the ICU team about contributing ICU4N to their repository and if > they agree, allow them to lead the direction of the API and features (with > the added possibility of their help and Unicode expertise). I'd opt for 2 - and 3 after 2 is done. But see the disclaimer above. Stefan
