Zandronum Chat on our Discord Server Get the latest version: 3.0
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003481Doomseeker[All Projects] Suggestionpublic2018-09-01 11:042018-10-27 22:54
Assigned ToZalewa 
PlatformOSOS Version
Product Version1.1 
Target Version1.2Fixed in Version1.2 
Summary0003481: Add "system default" locale to Appearance configuration
DescriptionIf the default locale of the operating system changes, and the user had chosen "system default" locale, then ideally Doomseeker should also change its locale without intervention (after program restart, at least), unless the user has chosen a specific language (locale) in the configuration menu.

This "system default" locale doesn't exist, yet. I propose it to be added.
Steps To Reproduce
  1. Start Doomseeker.
  2. Press the F5 key to open the configuration or find Options → Configuration from the top crate navigation.
  3. Navigate to "Appearance" settings.
  4. Under "Language" drop down menu, notice there may be specific language options but no option for "system locale".
Additional InformationMumble (another Qt4 software) implements this. I'd assume the system locale should also become the default locale selected in new configurations, and this is what Mumble does too.
Attached Files

- Relationships
related to 0003260closedZalewa Translation "en_US" cannot be found, unknown language definition 
child of 0003279acknowledgedWubTheCaptain List of Debian issues (misc/non-policy) 

-  Notes
User avatar (0019471)
WubTheCaptain (developer)
2018-09-01 11:43

I figured this is kind of the behavior that Doomseeker experiences already with new configurations (probably). But once you select a language, there's no going back as the "Localization" parameter is written to doomseeker.ini. I didn't test this theory, though.
User avatar (0019539)
WubTheCaptain (developer)
2018-09-18 11:51

Zalewa: Why is this ticket a "child of 0003483", which implies severity "blocking" for the Doomseeker 1.2 release?
User avatar (0019883)
Zalewa (developer)
2018-10-02 16:55

I have done some considerable work on this ticket today, but I'm not sure if it's ready for pushing just yet. There's a lot of difference between what the user sees on screen in the "Appearance" config box, the "retranslation restart" notifications, the loading of actual translations and with matching the locales. I'll have to glance over the code again with a clearer mind and see if I'm happy with it.

Nevertheless, commit for this is coming soon.
User avatar (0019907)
Zalewa (developer)
2018-10-04 21:02
edited on: 2018-10-04 21:02

Okay, so this is it: [^]

The gist of it is that "Localization" .ini variable is now settable to a "system" value. As you may suspect, this is not a real localization but a magic value that the program dynamically translates to whatever is the current locale as reported by Qt through `QLocale::system()`. IIRC on Linux I can manipulate the retval of that method by changing the LANGUAGE env. var. Doomseekes lets you enforce a specific locale and then switch back to this system-follow value from the Appearance config tab.

The "restart to retranslate" notifications should also be aware of the fact that the currently loaded language might be the same as the system language and the same as a specific language picked from the list. In other words, the notification should not appear if no actual retranslation is going to happen even if the raw value in the .ini file differs after the config gets saved.

System-follow is now also the default for new configurations which coincidentally should also fix 0003260.

Oh, and also Localization class is now a singleton, which is a bleh and a meh.

User avatar (0019925)
WubTheCaptain (developer)
2018-10-06 09:49

Passes my code review and testing on OpenBSD 6.4-current.
User avatar (0019927)
WubTheCaptain (developer)
2018-10-06 09:58

You could've updated the copyright years Zalewa, but I won't bother in this ticket.

Issue Community Support
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
Supporters: No one explicitly supports this issue yet.
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2018-09-01 11:04 WubTheCaptain New Issue
2018-09-01 11:05 WubTheCaptain Steps to Reproduce Updated View Revisions
2018-09-01 11:05 WubTheCaptain Relationship added child of 0003279
2018-09-01 11:06 WubTheCaptain Relationship added related to 0003260
2018-09-01 11:07 WubTheCaptain Description Updated View Revisions
2018-09-01 11:08 WubTheCaptain Description Updated View Revisions
2018-09-01 11:16 Zalewa Status new => acknowledged
2018-09-01 11:43 WubTheCaptain Note Added: 0019471
2018-09-10 05:29 Zalewa Relationship added child of 0003483
2018-09-18 11:51 WubTheCaptain Note Added: 0019539
2018-09-22 16:13 WubTheCaptain Status acknowledged => confirmed
2018-09-22 16:13 WubTheCaptain Target Version => 1.2
2018-09-22 19:01 Zalewa Assigned To => Zalewa
2018-09-22 19:01 Zalewa Status confirmed => assigned
2018-10-01 03:40 WubTheCaptain Relationship replaced related to 0003483
2018-10-02 16:55 Zalewa Note Added: 0019883
2018-10-04 21:02 Zalewa Note Added: 0019907
2018-10-04 21:02 Zalewa Status assigned => needs testing
2018-10-04 21:02 Zalewa Note Edited: 0019907 View Revisions
2018-10-06 09:49 WubTheCaptain Note Added: 0019925
2018-10-06 09:49 WubTheCaptain Status needs testing => resolved
2018-10-06 09:49 WubTheCaptain Fixed in Version => 1.2
2018-10-06 09:49 WubTheCaptain Resolution open => fixed
2018-10-06 09:58 WubTheCaptain Note Added: 0019927
2018-10-13 16:39 WubTheCaptain Relationship deleted related to 0003483
2018-10-27 22:54 WubTheCaptain Status resolved => closed

Questions or other issues? Contact Us.


Copyright © 2000 - 2021 MantisBT Team
Powered by Mantis Bugtracker