-
Notifications
You must be signed in to change notification settings - Fork 187
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Date strings not always in locale #256
Comments
What happens when you move the following lines from the
|
Looks like a good idea ;-) Tried NL DE EN and all with openweathermap and tomorrow.io. |
@SerBrynden's suggestion is the best if it works. tick() is based on QTiimer, which could be a thread or message loop based depending in specific implementation. Setting locale should work 'globally', but you're seeing evidence of two versions of it. It is possible some other time manipulation functions are overriding locale (tz=tzlocal.get_localzone()) for example. I did intentionally make DateLocale fail silently, in case the operating system does not have the locale set up. Perhaps another solution is to set locale more often in code that displays data. Thank you @BertLindeman for helping track this down. |
Setting locale more often might easily miss some place in the code where it should be. (not formulated very legible, sorry) Another side remark: I did not see this problem running python3. |
I saw the same problem in my Python3 fork, until I moved the code to qtstart(). |
pull request? or should I just make the change? |
I want to try. |
Moved set locale from tick to qtstart
Not doing enough pull requests lately. Created the pull request. Not sure if I now should close the pull request (now) |
My latest pull request #258 also fixes this. |
The localized date and times are not always translated,
see in issue 185
I think I found a reason.
In the forcast squares before the day.setText calls I added a setlocale and some prints.
Before and after the setlocale it shows:
So each time e.g. wxfinished_tm3 is called the locale is again back to the default.
The setlocale is done in the function Tick.
I assume the function
tick()
runs as a separate thread (or something like it)Could that be the reason that sometimes I saw the correct locale datea and most of the time not.
I copied the setting of the locale near line 2200 between:
I added there:
Could this be the cause?
In python3 I did not see a similar problem, but that can be a timing issue aswell.
The text was updated successfully, but these errors were encountered: