Bug #17271

Norwegian option missing in Time and Date format selector

Added by numbat 2019-11-29 09:21:48 . Updated 2020-04-15 06:02:28 .

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:
Welcome Screen
Deliverable for:

Description

It’s true.


Subtasks


Related issues

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

History

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

#2 Updated by intrigeri 2019-12-15 09:35:08

#3 Updated by segfault 2019-12-15 18:03:38

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

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 2019-12-18 15:07:52

  • Status changed from Confirmed to In Progress

Applied in changeset commit:tails|83c2436e1d7ff101f1154323f0b8f3eca9c8c365.

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

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

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

#9 Updated by intrigeri 2019-12-28 17:44:06

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 2020-01-03 16:11:36

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 2020-01-05 18:11:19

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

Ok, closing then.

#12 Updated by intrigeri 2020-04-15 06:02:28

  • Affected tool changed from Greeter to Welcome Screen