lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Currens (JIRA)" <>
Subject [jira] [Resolved] (LUCENENET-493) Make culture insensitive (like the java version)
Date Fri, 22 Jun 2012 21:54:42 GMT


Christopher Currens resolved LUCENENET-493.

    Resolution: Fixed

This should be fixed now.  Added a test to LocalizedTestCase (different from the patch above)
so that it will run some or all tests (if no specific tests were selected) under all installed
cultures on the machine.  This should be the same behavior as Java, except for that it is
running all tests in one, instead of individually.  However, when a test fails, it will output
which test failed and which culture it failed it.  I discovered issues in DateTools.cs in
the "ar" culture, where DateTimeToString was returning culture specific formatting.

I think we can resolve this now that we can confirm that the tests pass.  If any future culture-sensitive
bug appear, new issues can be created, and then specific tests can be written to check for
those issues.

> Make culture insensitive (like the java version)
> -----------------------------------------------------------
>                 Key: LUCENENET-493
>                 URL:
>             Project: Lucene.Net
>          Issue Type: Bug
>          Components: Lucene.Net Core, Lucene.Net Test
>    Affects Versions: Lucene.Net 3.0.3
>            Reporter: Luc Vanlerberghe
>              Labels: patch
>             Fix For: Lucene.Net 3.0.3
>         Attachments: Lucenenet-493.patch, UpdatedLocalizedTestCase.patch
> In Java, conversion of the basic types to and from strings is locale (culture) independent.
For localized input/output one needs to use the classes in the java.text package.
> In .Net, conversion of the basic types to and from strings depends on the default Culture.
 Otherwise you have to specify CultureInfo.InvariantCulture explicitly.
> Some of the testcases in fail if they are not run on a machine with culture
set to US.
> In the current version of there are patches here and there that try to correct
for some specific cases by using string replacement (like  System.Double.Parse(s.Replace(".",
CultureInfo.CurrentCulture.NumberFormat.NumberDecimalSeparator)), but that seems really ugly.
> I submit a patch here that removes the old workarounds and replaces them by calls to
classes in the Lucene.Net.Support namespace that try to handle the conversions in a compatible

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message