[AG-DEV] AccessGrid setting locale?

[Christoph Willing]

On 05/04/2011, at 1:29 AM, Andrew Ford wrote:

> Hi Chris,
>
> That makes sense, and I don't know of any other way to fix language  
> issues like that, but I would suggest that that call be moved  
> somewhere else if possible. Like the python docs say, it seems  
> inappropriate for a library to be setting the locale, and when you  
> just do the import agversion/agversion.select() to e.g. use the IW  
> classes to query or control the venue client, AG is effectively  
> being used as a library. Could that call be moved to somewhere like  
> when the GUI is set up? I'm not familiar enough with the AG codebase  
> to say, but it makes more sense to me to be somewhere like that  
> rather than in the very high-level general code like Toolkit.py is.


Andrew,

I'll raise it with Tom at the next Townhall - maybe he can think of  
some better place to put it.

I remember trying a few less-central places to include it but the  
logical candidates I tried at the time didn't work. Also I think there  
was more than just the gui issue i.e. printing of jabber timestamps. I  
vaguely recall a second issue - I think a time field in a particular  
format was being used by some crypto code somewhere - which depended  
on the locale setting. The quick fix was to centralise setting the  
locale; I guess no one has had the time to find a better place for it  
since then.

Could you add a bugzilla entry for this? Then there's less chance it  
will be forgotten ...


chris



> 2011/4/1 Christoph Willing <c.willing at uq.edu.au>
>
> On 02/04/2011, at 6:04 AM, Andrew Ford wrote:
>
> Hi,
>
> I noticed some interesting effects in a C++ application I'm  
> developing that calls various AG functions via the Python API. My  
> app also uses wxWidgets, and when I was experimenting with its  
> logging functions, I noticed that the timestamp format it uses  
> changes after I call a standard import agversion and  
> agversion.select(3). I looked a bit for any locale setting AG does  
> and found locale.setlocale(locale.LC_ALL, 'C') in Toolkit.py.  
> Commenting this line out prevents the timestamp (presumably the  
> associated locale settings as well) from changing; I haven't tested  
> whatever effect it may have on the venue client. I'm curious as to  
> what the rationale for this call is, as even the python docs (http://docs.python.org/library/locale.html 
> ) say it is not necessarily a good idea to set this in a context  
> like this ("It is generally a bad idea to call setlocale() in some  
> library routine, since as a side effect it affects the entire  
> program.") Any input on this issue would be great.
>
>
> Andrew,
>
> It was added so that non-english language users could use the  
> toolkit. I believe the original issue was incorrect time stamping in  
> the chat window but there was also some other side effect (which I  
> can't recall right now) that was fixed by setting the locale.
>
> If there's a better way (than setting the locale like that) to fix  
> the language issue then lets do it ...
>
>
> chris
>
>
> Christoph Willing                       +61 7 3365 8316
> QCIF Access Grid Manager
> University of Queensland
>
>

Christoph Willing                       +61 7 3365 8316
QCIF Access Grid Manager
University of Queensland