Thanks for the comments Hoss. More notes embedded below... On 10/17/07, Chris Hostetter <[EMAIL PROTECTED]> wrote: > > > : However, SolrSharp culture settings should be reflective and consistent > with > : the solr server instance's culture. This leads to my question: does > Solr > : control its culture & language settings through the various language > : components that can be incorporated, or does the underlying OS have a > say in > : how that data is treated? > > As a general rule: > 1) Solr (the server) should operate as culturally and locally agnostic > as possible. > 2) Solr Clients that want to act "culturally appropriate" should > explicitly translate from "local" formats to "absolute" concepts that > it sends to the server. (ala: the absolute unambiguous date format) > > Ideally you should be able to take a Solr install from one box, move it to > another JVM on a different OS in a different timezone with different > Locale settings and everything will keep working the same.
I fully understand that approach. Going back to C#/Windows, this is known as an Invariant culture setting, which we're incorporating into Solrsharp (along with configurable culture settings as appropriate.) (I think once upon a time i argued that Solr should assume the > charencoding of the local JVM, and wiser people then me pointed out that > was bad). > > There may be exceptions to this -- but those exceptions should be in cases > where: a) the person configuring Solr is in completley control; and b) the > exception is prudent because doing the work in the client would require > more complexity. Analysis is a good example of this: we don't make the > clients analyze the text according to the native language customs -- we > let the person creating the schema.xml specify what the Analysis should > be. > > As i recal, the issue that prompted this email had to do with C# and the > various cultural ways to specify a floating point number: 1,234 vs 1.234 > (comma vs period). this is the kind of thing that should be translated in > clients to the "canonical" floating point representation. ... by which i > mean: the one the solr server uses :) 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. *IF* Solr has the behavior where setting the JVM local to something random > makes Solr assume floats should be in the comma format, then i would > consider that a Bug in Solr ... Solr should allways be consistent. This would be an interesting discovery exercise for those who deal with 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. -Hoss > >
