Thanks for the thorough explanation.
From a user standpoint, I like (4), 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.
The main question I have is how many people would prefer to see, for example, a Japanese format calendar in Japan when they speak French. It seems pretty edge-case to me. Is the rationale that they want to do visual pattern matching with local other calendars?
I would think that the errors caused by unfamiliar calendar formats would outweigh the benefit of showing an unreadable local format. I know when I had a German wall calendar, for example, which starts the week on a different day than in the USA, I made errors in planning so often during that year that I had to hide the box-grid part of it. Very often, not having to do the extra mental translation is the better choice for UI controls. ("Don't Make Me Think")
Best wishes,
Susan
On Feb 18, 2017, at 11:22 AM, intrigeri <intrigeri@???> wrote:
> Hi!
>
> [meta: we need a decision by March 12; if no consensus is reached by
> then, we'll let sajolida decide (if he wants to), and if he doesn't
> I'll pick option 4 described below, that is: remove the "Formats"
> option until it's clarified how it should look like and what it
> should do.]
>
> In 2014Q4 we discussed on this mailing list (plus some bits on
> tails-l10n@) the "Formats" setting introduced in the new Greeter.
> This is in addition to the "Language" setting, that itself configures
> what language is used to display text, e.g. "Português - Brasil" or
> "Français - Canada". Note that this discussion is about the *new*
> Greeter, that will be included in Tails 3.0, whose release is
> scheduled on June 13 (the old Greeter, included in Tails 2.x, does not
> include any such "Formats" option).
>
> We decided to add this "Formats" setting to the "Language & Region"
> section. It was meant to configure units, date and time formats, paper
> size, etc. The main use case we had in mind was "I speak French and
> while traveling to the USA, I want my Tails to use local units and
> formats, in a French-speaking interface". Another way to put it could
> be "I want the formats to match those used in the country I currently
> live in, but my preferred language is another one".
>
> We did not specify how exactly this setting should behave, and we
> didn't look closely at the actual impact of this setting. (If you want
> to go look at this past discussion, Alan was kind enough to dig
> through the archives and gather links to the most relevant parts:
> https://labs.riseup.net/code/issues/12079#note-19)
>
> So far, so good. But recently, we noticed one unexpected aspect in the
> behavior of the current implementation: for example, if I speak
> French, I am traveling to Japan, I'm expected to choose "Français" as
> text language, and set "Formats" to "Japan". Then, most software will
> display text in French, as expected; and software will display
> numbers, dates and so on in Japanese format. *But* that's not all:
> there's no such thing as "displaying a date with French languages in
> Japanese format". So I will get a desktop that's 95% in French, but
> with all dates written in Japanese, e.g. the date/time in the GNOME
> top bar. If I cannot read Japanese, then this outcome is pretty bad
> for me, and is unexpected since Tails has let me pick French as the
> language to be used to display text.
>
> In other words: "Formats" and "Language" are correlated, contrary to
> what we were implicitly assuming during the initial discussion that
> lead to the current implementation.
>
> After discussing this for a while with Alan, we came up with a number
> of options. I'll sum them up below. We created a blueprint with
> screenshots demonstrating how each of them would look like in the
> Greeter, and what the result would be on the GNOME desktop:
>
> https://tails.boum.org/blueprint/greeter_revamp_UI/design_rationale_phase1/formats/
>
> Feel free to copy what follows into the blueprint if it's useful, e.g.
> if you want to collaboratively update the comparison based on
> this text.
>
> Also, note that we did not look at how other operating systems do it.
> It may be helpful if someone did :)
>
>
> 1. Current implementation: "Formats" affects time/date formats
> ==============================================================
>
> * 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).
>
> * resulting behavior: as described above, the UI is mostly in the
> chosen language but dates are written in the language corresponding
> to the chosen "Formats"
>
> * pros: matches current GNOME's behavior
>
> * pros: allows choosing arbitrary formats according to one's
> location or preference (e.g. imperial units if I'm in the USA)
>
> * cons: confusing, as described above; and the current UI has no room
> to explain what "Formats" does, unless one opens the documentation
> page, which we should probably not count too much on
>
> * implementation cost: none, unless the UI needs to be rethought and
> adjusted to clarify what the setting actually does
>
> * note: Tails 3.0~beta1 has another implementation, that is not viable
> and not worth considering here, so don't expect to check how it
> works by starting this version
>
>
> 2. Current implementation but "Formats" does not affect time/date formats
> =========================================================================
>
> * 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.
>
> * 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"
>
> * 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)
>
> * cons: IMO one major reason to choose "Formats" according to one's
> current location is to get… time/date expressed in the way it's done
> in that place; so this proposal seriously weakens the benefits of
> having a "Formats" option at all
>
> * implementation cost: very low + the time needed to choose or create
> a new icon for the "Formats" setting (the current one shows
> a calendar)
>
>
> 3. Current implementation but only allow "Formats" that match the chosen language
> =================================================================================
>
> * Greeter: we let users pick "Formats" only among those that match the
> chosen language closely enough. I won't annoy you with a formal
> definition, so here's an example instead: given I have chosen
> "French - Canada" as my preferred language, then I can choose
> "Formats" among Belgique, Canada, France, Luxembourg and Suisse.
>
> * pros: consistent text language, and in particular we don't display
> text in a language that the user cannot read; display of time/date
> matches the chosen "Formats"
>
> * cons: limiting the choice of "Formats" seriously weakens the
> benefits of offering this option, e.g. if I'm an Italian speaker
> traveling to the USA, I won't be able to get measurements in
> imperial units, nor a calendar with weeks that start on Sunday.
>
> * implementation cost: medium
>
>
> 4. Remove the "Formats" option entirely
> =======================================
>
> * Greeter: no "Formats" option whatsoever, as in Tails 2.x
>
> * resulting behavior: the "Formats" used in the GNOME session match
> those of the language + territory chosen with the "Language" setting
>
> * pros: no unexpected behavior, no resulting user confusion; gives us
> time to rethink this topic if we want
>
> * cons: Tails 3.0 won't add support for the new use cases we wanted to
> support with the new Greeter (but one still can pick one's preferred
> "Formats" once logged in, via the GNOME Settings, as in Tails 2.x)
>
> * cons: due to a bug in the underlying technologies, we will need to
> somehow artificially make the main Greeter window as high as it
> currently is; this implies to add some empty space somewhere, or
> make some elements bigger, which can take time… or look less
> polished
>
> * implementation cost: low + as much time as we want to spend on
> polishing the UI wrt. the window height problem mentioned above
>
>
> So, what shall we do?
>
> Alan and I agree with each other that options 2 and 4 are the best we
> have currently. I personally prefer option 4, i.e. postponing this new
> feature until design is clarified. Alan prefers option 2, i.e.
> keeping most of the benefits of this new setting, while limiting
> user confusion.
>
> Cheers,
> --
> intrigeri
> _______________________________________________
> Tails-ux mailing list
> Tails-ux@???
> https://mailman.boum.org/listinfo/tails-ux
>
>
