Project

General

Profile

Bug #17271

Norwegian option missing in Time and Date format selector

Added by numbat about 2 months ago. Updated 13 days ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
Internationalization
Target version:
-
Start date:
Due date:
% Done:

0%

Feature Branch:
bugfix/17271-all-formats-in-greeter
Type of work:
Research
Blueprint:
Starter:
Affected tool:
Greeter

Description

It's true.


Related issues

Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed

Associated revisions

Revision 83c2436e (diff)
Added by segfault about 1 month ago

WIP: Show all known formats in the Greeter (refs: #17271)

This adds all locales known to GNOME to the Greeter.

This increases the startup time of the Greeter by quite a lot, 15s
instead of 8s in my test VM.

History

#1 Updated by intrigeri about 1 month ago

  • 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.

#2 Updated by intrigeri about 1 month ago

#3 Updated by segfault about 1 month ago

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?

#4 Updated by intrigeri about 1 month ago

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 about 1 month ago

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.

Also:

  • 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.

#6 Updated by segfault about 1 month ago

  • Status changed from Confirmed to In Progress

#7 Updated by segfault about 1 month ago

  • 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. (@sajolida, @intrigeri)

#8 Updated by sajolida about 1 month ago

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. (@sajolida, @intrigeri)

Pff, I'm not sure but I think it's not worth it anymore

#9 Updated by intrigeri 21 days ago

Hi,

sajolida:

OMG! Things always get more complicated :)

segfault:

IMO the UX regression of the increased startup time outweighs the UX regression of missing some formats.

200% agreed!

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. (@sajolida, @intrigeri)

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.

#10 Updated by sajolida 15 days ago

It's great that you put a bit more work into this but indeed, it might be time to give up.

#11 Updated by segfault 13 days ago

  • Status changed from In Progress to Rejected
  • Assignee deleted (segfault)

Ok, closing then.

Also available in: Atom PDF