[
https://issues.apache.org/jira/browse/LUCENENET-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
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 lucene.net culture insensitive (like the java version)
> -----------------------------------------------------------
>
> Key: LUCENENET-493
> URL: https://issues.apache.org/jira/browse/LUCENENET-493
> 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 lucene.net fail if they are not run on a machine
> with culture set to US.
> In the current version of lucene.net 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 way.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
