Tails

#1 Updated by intrigeri 2016-12-24 07:44:55

Hopefully workarounded in tails-greeter 1.0.0_beta4 by not applying the format settings.

#6 Updated by intrigeri 2017-01-30 10:20:50

alant wrote:
> I think I fixed the issue, but it still needs polishing. Some locales are have very long name, and it makes the formats box barely usable when selected. I’ll try to work on that during the next days.

Great! I’ll wait until some time on Wednesday, and then I’ll have to get ready for the Tails 3.0~beta1 release, that I want to publish on Thursday. So if the fix is not good enough yet on Wednesday (i.e. not better than hiding the formats setting in the UI), then I’ll hide the formats settings for beta1. Fair enough?

#8 Updated by intrigeri 2017-01-30 10:21:51

alant wrote:
> Some locales are have very long name, and it makes the formats box barely usable when selected.

Sounds like the GUI boxes around need to be adapted to accommodate the data we want to display, then :) Good thing that we notice this now!

#10 Updated by intrigeri 2017-01-31 10:15:15

• I’m a bit sad that the code calls “country / countries” things that really are “territory / territories”; not a blocker, but please try to stick to more standard (and more correct politically speaking) terminology in the future :)
• Wrt. “display them as ”Country (Language)" as Gnome Settings“: I could not find where GNOME displays any such thing. On my sid, the ”Region & Language" panel has separate fields for language and formats, and formats only display the territory, as I would expect. Now I haven’t tested your branch yet, so I dunno if what it actually does matches what I understand from this commit message. I’ll test this before merging into feature/stretch.

Built a package, imported into bugfix/12079-formats, now building an ISO.

#12 Updated by intrigeri 2017-02-01 11:52:57

… and actually, I just realized that the old Greeter got this right. So perhaps some of the new code can be replaced by the old one, that did the job (although I suspect that everything changed around so it may not be an option).

Anyway, we’re now past the deadline I had set on Bug #12079#note-6. I’ll decide soon if it’s worth spending time on hiding the non-working option in the Greeter, or if documenting the problem in the 3.0~beta1 release notes is enough, and then I’ll implement whichever of these I prefer.

#13 Updated by intrigeri 2017-02-01 15:31:20

I’ve documented the known issue (Feature #12207) so we’re kinda good for 3.0~beta1. Let’s aim at really fixing it in March for beta2 (March 7), or worst case during the March sprint.

#14 Updated by alant 2017-02-02 15:32:40

intrigeri wrote:
> * I’m a bit sad that the code calls “country / countries” things that really are “territory / territories”; not a blocker, but please try to stick to more standard (and more correct politically speaking) terminology in the future :)

I’m fine with changing country to territory. However, this terminology has always been in the greeter code.

> * Wrt. “display them as ”Country (Language)" as Gnome Settings“: I could not find where GNOME displays any such thing. On my sid, the ”Region & Language" panel has separate fields for language and formats, and formats only display the territory, as I would expect. Now I haven’t tested your branch yet, so I dunno if what it actually does matches what I understand from this commit message. I’ll test this before merging into feature/stretch.

From Tails, open Settings, then Region & Language, then click Formats
>So, I’ve tried this, and at first glance it feels wrong: in the Greeter I kept the default language (English US), and selected “USA - Cherokee” in the formats list. The resulting GNOME session has these locales:
> […]
> … and the UI is mostly in English, but some parts, e.g. the clock , are in another language (I assume it’s Cherokee). That’s fully expected given the above locales (I think that LC_TIME=chr_US.UTF-8 means “display time and date in Cherokee language and US format”) but I doubt it’s what we want: as I understand it, the Formats setting should really configure formats, i.e. the territory part of the locale, and not the language.
> […]
> Which seems to confirm that what I’m explaining above is correct. So, what’s the deal? Did you get it wrong, or did I miss something?

I indeed think I got something wrong, but I’m not sure what. Currently the list is grouped by territory, and let choose the languages in this territory, then set locale. Should the list be grouped by language (as the text language list) and let choose territory under each language?

> … and actually, I just realized that the old Greeter got this right. So perhaps some of the new code can be replaced by the old one, that did the job (although I suspect that everything changed around so it may not be an option).

It’s not an option, let’s rather see how the do the right thing with the new code using maintaines libraries!

> Let’s aim at really fixing it in March for beta2 (March 7), or worst case during the March sprint.

Fine with me.

#15 Updated by intrigeri 2017-02-02 16:30:23

>> * Wrt. “display them as ”Country (Language)" as Gnome Settings“: I could not find where GNOME displays any such thing. On my sid, the ”Region & Language" panel has separate fields for language and formats, and formats only display the territory, as I would expect. Now I haven’t tested your branch yet, so I dunno if what it actually does matches what I understand from this commit message. I’ll test this before merging into feature/stretch.

> From Tails, open Settings, then Region & Language, then click Formats

Thanks! Wow. I don’t know why this happens there, and not on my system. Possibly because we install locales-all or something.

> I indeed think I got something wrong, but I’m not sure what. Currently the list is grouped by territory, and let choose the languages in this territory, then set locale. Should the list be grouped by language (as the text language list) and let choose territory under each language?

What’s “the list”?

#17 Updated by intrigeri 2017-02-08 11:59:00

After thinking about it more, I must say I am deeply confused, and don’t know what the Formats field is for exactly, what exact need it satisfies, and why we need it at all.

Should it affect the language in which info like time/date is displayed? Maybe we need to go ask the UX list, unless this was specified somewhere during the design phase already (was it? I could not find anything about it on https://tails.boum.org/blueprint/greeter_revamp_UI/design_rationale_phase1/, and I suspect that the discussion we had about Formats on tails-ux@ was deeply flawed by not taking into account the actual impact of setting Formats to LANG2_TERRITORY2 when Language is set to LANG1_TERRITORY1, and LANG1 != LANG2).

If the answer is “yes”: then IIRC your branch gets it right already. I find it very confusing to be asked what my preferred language is, and then see my choice ignored for some parts of the UI; so I doubt it’s how things should work.

If the answer is “no”: then the list of choices offered in the Formats selection must be restricted to territories for which, given the already chosen Language, there’s a valid $CHOSENLANGUAGE_$TERRITORY locale, i.e. the list of territories one can see in the Language selection, in the sub-list corresponding to a given language; e.g. if one chose French ($something) language, then the valid territories are Belgique, Canada, France, Luxembourg and Suisse. But then, why do we need a separate Formats field at all? The Language setting already allows picking a territory for the language, and I’m not sure I see common use cases for picking a different territory for the formats. So I would be in favour of dropping the Formats setting entirely.

#18 Updated by intrigeri 2017-02-08 12:28:15

intrigeri wrote:
> After thinking about it more, I must say I am deeply confused, and don’t know what the Formats field is for exactly, what exact need it satisfies, and why we need it at all.
>
> Should it affect the language in which info like time/date is displayed? Maybe we need to go ask the UX list, unless this was specified somewhere during the design phase already (was it? I could not find anything about it on https://tails.boum.org/blueprint/greeter_revamp_UI/design_rationale_phase1/, and I suspect that the discussion we had about Formats on tails-ux@ was deeply flawed by not taking into account the actual impact of setting Formats to LANG2_TERRITORY2 when Language is set to LANG1_TERRITORY1, and LANG1 != LANG2).

If you want, I can start a discussion about this on tails-ux@ later this week.

#19 Updated by alant 2017-02-10 15:04:44

> After thinking about it more, I must say I am deeply confused, and don’t know what the Formats field is for exactly, what exact need it satisfies, and why we need it at all.

Basically, you are a french speaking person travelling in the US. You want your UI in french, but you’d like to have measurements, money, papersizes in the US format that is used in your environnment. So you choose French as your Text Language, English or French as your keyboard layout (depending on wether you have your frech laptop or you borrowed a computer with english keyboard, and you set Formats to United States (English).

> […] and I suspect that the discussion we had about Formats on tails-ux@ was deeply flawed by not taking into account the actual impact of setting Formats to LANG2_TERRITORY2 when Language is set to LANG1_TERRITORY1, and LANG1 != LANG2).
>
Right.

> If the answer is “yes”: then IIRC your branch gets it right already. I find it very confusing to be asked what my preferred language is, and then see my choice ignored for some parts of the UI; so I doubt it’s how things should work.
>
Perhaps we should not set LC_TIME but set the LC_NUMERIC, LC_MONETARY, LC_PAPER and LC_MEASUREMENT? The exact set of variable we set have never been discussed, it’s just copied from gnome-control-center. I’m always in favor of having the same behaviour than the same option in GNOME, but that one my deserve an exception.

> If the answer is “no”: […] I would be in favour of dropping the Formats setting entirely.

If the answer is no, then I agree this field is useless as everything is in text language. But we’d have to rename the field somehow.

> If you want, I can start a discussion about this on tails-ux@ later this week.

All this discussion about utility of formats have already happened.

• https://mailman.boum.org/pipermail/tails-ux/2014-September/002248.html
• https://mailman.boum.org/pipermail/tails-l10n/2014-September/001554.html
• https://mailman.boum.org/pipermail/tails-l10n/2014-October/001576.html

So if we want to start a new discussion (why not), we must somehow sum up the previous ones, else we’ll wast time and energy. Hopefulle this comment may be a basis…

Unfortunately the best “conclusion” I can find is:

> My question now is what do we do in the first screen? To the light of
> this argumentation I see three options:
>
> 1. We keep the interface as of today and work on making it more clear
> what this settings does. But it might be a bit tricky to make that
> information fit with the actual vertical selector.
>
> 2. We use a different interface than the Language + Keyboard combo. For
> example an horizontal dropdown list across the full screen. That would
> allow more horizontal space for the explanation and the examples. See
> screenshot in attachment. But this brings in more visual elements and
> might make the option to remember localization options a bit less clear.
>
> 3. Move this option to the advanced configuration. But I understand that
> intrigeri’s argumentation goes against this.

(https://mailman.boum.org/pipermail/tails-l10n/2014-October/001576.html)

We choosed 1 and called it “Formats”, which was validated by UX tests:

> [7]: Formats (won’t fix)
>
> I was surprised by how well understood was the “Formats” option. The
> calendar icon worked really well. Many people referred to disliking the
> American date formats

(https://mailman.boum.org/pipermail/tails-ux/2015-November/001879.html)

The exact contents of this was specified in the mockups (not that clearly):

(https://tails.boum.org/blueprint/greeter_revamp_UI/design_rationale_phase1/#index1h3)

#21 Updated by intrigeri 2017-02-10 19:16:16

> Basically, you are a french speaking person travelling in the US. You want your UI in french, but you’d like to have measurements, money, papersizes in the US format that is used in your environnment. So you choose French as your Text Language, English or French as your keyboard layout (depending on wether you have your frech laptop or you borrowed a computer with english keyboard, and you set Formats to United States (English).

OK, thanks! Now I remember making a very similar argument myself :)

>> […] and I suspect that the discussion we had about Formats on tails-ux@ was deeply flawed by not taking into account the actual impact of setting Formats to LANG2_TERRITORY2 when Language is set to LANG1_TERRITORY1, and LANG1 != LANG2).

> Right.

Thanks for confirming my guess. Too bad :/

>> If the answer is “yes”: then IIRC your branch gets it right already. I find it very confusing to be asked what my preferred language is, and then see my choice ignored for some parts of the UI; so I doubt it’s how things should work.

> Perhaps we should not set LC_TIME but set the LC_NUMERIC, LC_MONETARY, LC_PAPER and LC_MEASUREMENT? The exact set of variable we set have never been discussed, it’s just copied from gnome-control-center. I’m always in favor of having the same behaviour than the same option in GNOME, but that one my deserve an exception.

If this avoids having to reboot a discussion that has happened already (even if it was deeply flawed as said above), why not.

>> If you want, I can start a discussion about this on tails-ux@ later this week.

> All this discussion about utility of formats have already happened.

I’m aware of it, and I distinctly remembered being part of it, but I could not find it after spending quite some time searching; maybe, in the future, we should point to these discussions from the blueprint.

But as said above (and you seem to agree) it was based on wrong assumptions about the actual, practical effects of these settings. E.g. some of the examples I see used there don’t reflect what it looks like in practice. IIRC I myself insisted that it was important to allow picking a format independently from the language, but if I had known back then how it looks like in practice, maybe I would have changed my mind.

> So if we want to start a new discussion (why not), we must somehow sum up the previous ones, else we’ll wast time and energy.

Obviously. What’s the alternative? A couple of developers decide?

> Hopefulle this comment may be a basis…

Quite possibly. At least I’ve seen nothing that sums up the situation better :)

> The exact contents of this was specified in the mockups (not that clearly):

It’s good. But what I see there seems to suggest that whoever prepared these mockups lacked information about what can be implemented in practice: one can’t pick a territory without also picking a region.

So, what’s your plan?

#34 Updated by intrigeri 2017-03-18 08:12:03

code review passes.