Norwegian option missing in Time and Date format selector
|Blocks Tails - Feature #16209: Core work: Foundations Team||Confirmed|
#1 Updated by intrigeri 2019-12-15 09:34:50
- Status changed from New to Confirmed
- Type of work changed from User interface design to Research
- Affected tool set to Greeter
I’m assuming this is about the Formats in our Greeter: that’s the preferred place to choose time & date formats and I confirm Norwegian is not there. This is a regression compared to 3.16. I don’t know if it’s caused by the migration to Buster or by one of the many Greeter changes we merged in 4.0~rc1. @segfault, could you please take a look at some point?
Note that in GNOME control center → Region & Language → Formats, 3 Norwegian options are listed.
#4 Updated by intrigeri 2019-12-15 18:48:41
> That is because we only show formats (locales) for languages we support, and we don’t support Norwegian. I think it would be cheap to change that, and show formats for all languages instead. Should I do that?
I’m not sure what’s the best trade-off. @sajolida drove the move to displaying less languages in the Greeter so I’d like to know what he thinks.
#5 Updated by sajolida 2019-12-18 11:34:51
I’m not sure either but I would say that Formats are less important to
get uncluttered than Languages because they are not so critical to
getting a session that you can use. While still being annoying if you
can’t get the one that you want, though I have no idea what’s so special
about Norwegian formats for example.
- The old list of languages had 184 top-level entries while the old list
of languages had 142 top-level entries, so it’s a little bit
less cluttered :)
- A format is selected by default when you change the language.
Hopefully, this will prevent most people from having to fiddle with
the whole list in the first place.
So I’d say, let’s go and bring back the full list until we have more
arguments against it than in favor of it.
#7 Updated by segfault 2019-12-18 15:20:26
- Assignee set to segfault
- Feature Branch set to bugfix/17271-all-formats-in-greeter
I pushed a commit which adds all formats known to GNOME (i.e. returned by
GnomeDesktop.get_all_locales()) to the Greeter. But this increases the startup time of the Greeter a lot, in my test VM from 8s to 15s. I tried some optimizations, but a big part of the additional runtime simply comes from calling
GnomeDesktop.get_all_locales() (and then parsing the locales and building a giant dictionary).
IMO the UX regression of the increased startup time outweighs the UX regression of missing some formats.
One solution I see is to build the list of formats during build time and write it to the Greeter’s data directory. I don’t think that would be much work, but I still want to check with you if I should do that. (
#8 Updated by sajolida 2019-12-18 15:53:01
OMG! Things always get more complicated :)
> One solution I see is to build the list of formats during build time and write it to the Greeter’s data directory. I don’t think that would be much work, but I still want to check with you if I should do that. (
Pff, I’m not sure but I think it’s not worth it anymore
#9 Updated by intrigeri 2019-12-28 17:44:06
> OMG! Things always get more complicated :)
>> IMO the UX regression of the increased startup time outweighs the UX regression of missing some formats.
>> One solution I see is to build the list of formats during build time and write it to the Greeter’s data directory. I don’t think that would be much work, but I still want to check with you if I should do that. (
> Pff, I’m not sure but I think it’s not worth it anymore
I think it was worth giving it a try. And I think it’s good that we’re experimenting, evaluating, and are being open to giving up.
Now, we’ve shipped this change 2 months ago in 4.0 and:
- AFAIK that’s the only complain we got about this via our help desk. I know that it’s not necessarily a good indicator of how badly it affects our users, but getting such data is the primary reason why we have a Help Desk nowadays, so if we can’t use it, perhaps we should rethink our Help Desk’s mission.
- I could find no mention of this problem on https://www.reddit.com/r/tails/, where arguably many more users report issues than to our Help Desk
So if segfault’s initial attempt had worked nicely, I would be happy to see this fixed, but now that we know it’s more complicated than that, I’m leaning towards “bah, not worth it”. This being said, segfault, if you would feel better putting another hour or two into finishing this, go ahead. But if it takes more time than that, then I would find it hard to justify using more Tails resources here.