Re: JUnit sc_complex fails in Localized enviroment

2012/2/28 Stephan Bergmann <sbergman@redhat.com>:
> On 02/28/2012 11:38 AM, Markus Mohrhard wrote:
> > Let me take this over. I think that we might miss a step in our java
> > tests that forces the some parts of formulas. We had problems with
> > this already in our c++ based tests but were able to force them to
> > en-US too.
> >
> > I think this might be another case that we need to force it like in
> > test/source/bootstrapfixture.cxx:95 and 96
>
>
> Not sure if something like that can also be done from remote (which would be
> necessary for that sc_complex test).  Setting LC_ALL within the relevant
> makefile is possible, but can get nasty wrt multi-platform. (Another option
> would be to migrate that test from a qadevOOo based one to a single-process
> one.)

This is not the only qaDevOOo test that assumes en_US in calc. Nearly
all tests aussme it in some way, either in sheet names, separators,
date formatting, ... I hope that there is a way to force this through
UNO.

> > IMHO it is not a good idea to change the tests so that they no longer
> > use the sheet names because we have them all over the place and it
> > will make the test code more complex tha necessary.
>
>
> That would of course keep the test failing for the OP with --with-lang
> lacking en-US.  Not sure if we want to support that, though.

It is not the only calc test failing if you build without en_US. I
think we once defined building with en_US as a requirement otherwise
we need to rethink the whole calc test concepts. They all assume that
en_US is present and set. It is otherwise not possible to test correct
import of anything (different formula names, different separator,
different default number formats, ...)

IMHO we should execute all tests in en_US and assume that everyone
builds with en_US.

Markus