: This is exactly the scenario. Ideally what I'd like to achieve is for : Solrsharp to discover the culture settings from the targeted Solr instance : and set the client in appropriate position.
well ... my point is there shouldn't be any cultural settings on the "targeted" Solr server that the client needs to know about. the communication between the server and any clients should always be in a fixed format independent of culture. Any (hypothetical) culture specific settings the server has to have might affect teh functionality, but shouldn't affect the communication (ie: for the purposes of date rounding/faceting the Solr server might be configured to know what timezone to use for rounding to the nearest day is, or what Locale to use to compute the first first day of the week, but when returning that info to clients it should still be stringified in an abolute format (UTC) : multi-lingual systems across different JVM and OS platforms. If it *were* : the case that different underlying system stacks affected solr in such a : way, Solrsharp should follow the server's lead. if that were the case, the server would be buggy and should be fixed :) i don't know much about C#, but i can't really think of a lot of cases where client APIs really need to be very "multi-cultural" aware ... typically culture/locale type settings related to parsing and formatting of datatypes (ie: how to stringify a number, how to convert a date to/from a string, etc...). when client code is taking input and sending it to solr it's dealing with native objects nad stringifying them into the "canonical" format Solr wants -- independent of culture. when client code is reading data back from Solr and returning it it needs to parse those strings from the canonical form and return them as native objects. The only "culture" that SolrSharp should need to worry about is the InvariantCulture you described ... right? -Hoss
