wxGUI/history: Fix date formatting

[lindakarlovska]

Fixes #3726 by removing -d (it's linux only).

[lindakarlovska]

Fixes #3726 by removing -d (it's linux only)

Implemented based on this comment (#3726 (comment)). Just to be sure, I tested it again on Windows and it is allright now..

[echoix]

I was just wondering what the minus d in the old format strings meant. As from what I read, I would expect the B specifier to work on windows.

[lindakarlovska]

I was just wondering what the minus d in the old format strings meant. As from what I read, I would expect the B specifier to work on windows.

Yes, the B specifier works on Windows and I am using it in month_name = day.strftime("%B"), the problem was only with -d

[wenzeslaus]

{0} {1} makes it difficult to translate and it is not a good practice overall. If you are using the individual date components separately, use {month_name} {day_number} or something like that and then keyword arguments with the format call.

[lindakarlovska]

{0} {1} makes it difficult to translate and it is not a good practice overall. If you are using the individual date components separately, use {month_name} {day_number} or something like that and then keyword arguments with the format call.

Ok, now it is more readable.

[wenzeslaus]

Thanks! Just consider if preparing {month_name} {day_number} ahead of time and then using it later would make the code shorter and any changes easier (in translation or in the code itself).

[wenzeslaus]

All of this needs to be wrapped in _() and the suffix makes it confusing and less flexible for the translator. The previous commit had all that right, just with duplication.

[echoix]

I thought that this PR already gone through, I was set up to test the nightly again..

But it now has a different stack trace message (in windows sandbox), even if this fix isn't in there

[lindakarlovska]

I thought that this PR already gone through, I was set up to test the nightly again..

But it now has a different stack trace message (in windows sandbox), even if this fix isn't in there

Thanks for reporting. That is strange that nobody has reported that earlier... It has nothing to do with the History tab. I am not near the computer now, but it looks like a problem in the main statusbar class which I implemented about one year ago... so we can calmly merge this PR, this issue should be solved separately.

[echoix]

I thought that this PR already gone through, I was set up to test the nightly again..
But it now has a different stack trace message (in windows sandbox), even if this fix isn't in there

Thanks for reporting. That is strange that nobody has reported that earlier... It has nothing to do with the History tab. I am not near the computer now, but it looks like a problem in the main statusbar class which I implemented about one year ago... so we can calmly merge this PR, this issue should be solved separately.

I agree, that's why I filed another issue for it. We're only waiting for Vaclav that previously requested changes, to change his review that unlocks it (or we can dismiss it if ever it gets stuck for too long, but we can still wait).

[wenzeslaus]

It lost some of the good part from the previous version. Hopefully, now I'm clear enough on what I think should happen. Let me know if not.

[wenzeslaus]

I meant to request changes.