Hi,
[meta: the deadline to make a decision is in a week from now; an
updated proposal of mine follows, that tries to take into account the
input sent by Susan and Alan.]
Alan:
> intrigeri:
>> Susan:
>>> or if I understand it correctly, (2) making the
>>> choice 2-step, opt-in, where first the person chooses to match the UI language to
>>> their own preference (French), then sees the French calendar and opts to change that
>>> to Japanese format with a second control if they want to.
>>
>> This is an interesting idea, I hadn't thought of it. I like it!
>>
>> One potential problem though: I have no idea how the GNOME Settings
>> would behave in this situation (it might be that they would tell the
>> user that Japanese formats are already enabled, and then it might not
>> be crystal clear how one can switch from "Japanese formats except
>> time/date" to "Japanese formats everywhere"). Alan, could you please
>> prototype this quickly and show us how this would look like? If you
>> can't, just let me know and I'll do it myself :)
> In the Greeter, I choose:
>
> - "Language" > "Français (France)"
> - "Formats" > "United States (English)"
> [...]
> So I see no way to change the calendar to US once logged.
Thanks for testing, this is very useful data!
> But there is a trick (no idea how easy it would be to implement that
> this is triggered by whatever DBus communication GNOME Settings do when
> clicking "Restart"):
> $ export LC_TIME=en_US.UTF-8
> $ gnome-shell -r
Just to be clear: does this successfully apply the chosen time format
both to the date/time displayed in the top bar, and to the calendar
displayed when one clicks on this date/date?
Note: I think this will apply the new time format settings to GNOME
Shell and to *some* programs started from the Applications menu after
this restart, but not to any already running program, nor to any
programs started from the Apps menu with D-Bus activation (e.g.
gedit and Files). I may be wrong, I'd welcome more testing.
So this potential, previously unforeseen advantage of Option 2 comes
with:
* a bonus, hard to predict implementation cost
* unclear yet advantages (as stated above, I doubt the time format
settings chosen in the GNOME session will apply everywhere)
… which makes it quite different from the original Option 2.
I'll therefore call it Option 5:
5. Current implementation but "Formats" does not affect time/date
formats, plus allow choosing the calendar format in the GNOME settings
=========================================================================
* Greeter: we let users pick whatever "Formats" they want, even those
that don't match their chosen language at all (e.g. French language
and Japanese formats), as done in the current implementation.
* in-session GNOME settings: we let users pick whatever "Formats" they
want
* resulting behavior: the UI is fully displayed in the chosen
language; everything that "Formats" affects follows from the chosen
"Formats" setting, except time/date display that follow from the
chosen "Language", unless one changes it later in the GNOME
settings, which applies the newly chosen time/date format to some
(but likely not all) applications
* pros: consistent text language, and in particular we don't display
text in a language that the user cannot read
* pros: allows choosing arbitrary settings for most formats according
to one's location or preference (e.g. imperial units if I'm in the
USA)
* implementation cost: unknown + the time needed to choose or create
a new icon for the "Formats" setting (the current one shows
a calendar)
>From a user standpoint, I now prefer:
5 (if it applies the time/date format everywhere consistently)
over 4
over 5 (if it doesn't apply the time/date format consistently)
over 2
With my Tails 3.0 release manager hat, keeping in mind that I want
some guarantees this problem will be fixed by March 18, and that
I also need Alan's limited time for other matters related to
Tails 3.0, my preferred plan now is:
1. Implement Option 4 mid-March, without putting too much energy into
polishing it; i.e. fix the critical problem we're currently facing
without taking the risk of having *no* fully implemented solution
by the end of our March Stretch sprint, but without investing too
much into this hopefully temporary solution either.
2. Once the immediate problem is fixed, whenever he has no
higher-priority Stretch-related task on his plate, Alan
investigates Option 5 a bit further, and reports back about the
resulting behaviour and expected implementation cost.
3. Depending on Alan's estimates and testing results, UX people can
decide whether it's worth spending time on Option 5, or if Alan'd
better focus on some other Greeter UX improvements instead.
What do you think?
Cheers,
--
intrigeri
