grrr ... so I was testing some locale changes for TB health checks: namely that the languages are exactly what they should be: i.e supported, correct case, correct order. And that the locale matches (language !== locale is not good enough, e.g. it-IT language uses it locale), also correct case. I am excluding android for now as I believe that we don;t have parity and/or there is something going on with case (e.g. en-us, or even what is used, e.g. en vs en-US .. blah blah)
So I was messing around adding languages. Whilst in en-US, I added French, then Danish
and when I added Danish, I got the apply and restart, so I did - and this is what happened
so my locale matches Danish, but my languages were never set correctly. The languages in the UI are as per the first pic
So now I decide to go back to en-US and replicate my steps for you, so I choose to change to english and apply and restart and this is what I get - NOTE I cannot remove Dansk or Francais ... and after some more fiddling, can't remove Espanol, Cestina
So not only does the UI become borked, but looking at the first image, we fubar the fingerprint. I think when we apply a language change we need to properly reset the UI and navigator properties edit AND locale
OK, the UI is a red herring ... in my TB-alpha-lang [1], where I have been testing all the languages, I have every single language in the UI - so as long as we are controlling navigator.language and navigator.languages and the HTTP header then the UI doesn't really matter?
[1] I run a separate TB-alpha always set to en-US which is the one I used in OP
pic
Thorinchanged title from language change doesn't properly set languages or locale to language change doesn't always properly set languages and/or locale
changed title from language change doesn't properly set languages or locale to language change doesn't always properly set languages and/or locale
I've tried to add Italian, and I had it-IT added to the accepted languages with spoofing English off.
Then I've added Spanish, but it wasn't added again to the list (the behavior I didn't like of 102).
I'm very confused, and I don't think I got STR right.
But I think the easiest solution would be to dump the locale list (get that button out of about:preferences), and:
if you have spoof English, do everything in en-US
if you don't have spoof English, just use the first language you have
We could hack the preferences page to do so and automatically reset the users to this behavior once.
Then, if they preferred the old one (why?) and they mess up with about:config, let them be, and fix it the next time they change the language with the preferences.
The alternative is to force the list for accepted locales at each restart, but I wonder if forcing something eventually ever works.
I can confirm that the remove button stays disabled.
The logic to allow removing a language is:
!packagedLocales.has(code)
But this hasn't changed from 12.5.1, you can only add the packaged locales, but never remove them.
The delete button in the UI language is inconsistent, but with the appropriate order unpleasant surprises can be avoided, so we don't have to care about this and let upstream solve it or discuss it on Bugzilla anyway (for completeness, Firefox has a property for last fallback and it's always en-US: we could check that instead of packagedLocales.has).
Do we have an issue about removing the choose the languages for display already?
If we do, I'll remove UX from this issue, and keep it for other nonsense we might find here instead, even though I think it would be the ultimate solution to these problems.
And it's good. We don't want to expose users' settings for the UI.
So, not modifying the web page languages if you change a language except the first one works for me.
Letting the first language change the fingerprint is also okay, because it happens only when you don't enable spoof English.
It's what a user wants, eventually.
Not being able to remove a UI language kinda sucks, but it isn't a big deal either.
Upstream might be doing something, because I can't choose my language at all in Nightly.
If they aren't changing anything, we can move to Bugzilla, solve it upstream and then port downstream.
I don't follow. The add alternatives in TB only lets you add languages that we cover (38 of them). And it doesn't (bugs, if any, aside) so anything more than using the combobox next to add alternatives
wait ... the web content one is below that Choose your preferred language for displaying pages - my bad - I mixed app vs content - so the add alternatives is for the app .. got it (still don't understand why anyone would want mixed languages in the app - is this really a thing, I guess so, FF has it)
Letting the first language change the fingerprint is also okay, because it happens only when you don't enable spoof English. It's what a user wants, eventually.
noooo. that's just crazy talk ... users shouldn't be allowed to change anything
Agreed. In the application's add alternatives, sure, if the first one is Spanish you would probably want the app to match (except where they opted into spoof english). This is what threw me, I was using the app change to change the prefers languages (because I do not ever use spoof english)
that also explains the mixed languages in the UI in one of my other issues: re burmese
still don't understand why anyone would want mixed languages in the app - is this really a thing, I guess so, FF has it
In case of incomplete languages:
E.g., you know French or Spanish better than English, you can set your mother language as first, French/Spanish as second and English as third.
By re-reading this I admit I wasn't clear enough.
I was thinking to the case of countries that were French colonies at a certain point of their history, so, even though they have a first language that isn't French now, French is still the second language (I expect to be more than one).
I don't know if we support any in Tor Browser, but I guess Firefox does.
Thorinchanged title from language change doesn't always properly set languages and/or locale to app language change somehow changed webcontent locale ???
changed title from language change doesn't always properly set languages and/or locale to app language change somehow changed webcontent locale ???
I got confused because (yes the UX is bad), but mainly because I have trained myself (because spoof english is always off) to use the app language UI to flip content languages - i.e to reset them as per a new install for testing
still miffed I can't repro - it changed locale but not language (100% sure I was on en-US and the restart and apply was because it was asking to be set to danish), so weird
OTOH, I couldn't find the issue about deleting the confusing and risky button. I found #41339 (closed) and I made it a Meta, because I think it hasn't an action to do, but many interesting information.
I think the only way to change fingerprint is the second button, the one for the web languages
you mean change the FP from expected (all 38 of them), because clearly I can flip content language (excluding situation in op) via app language when spoof english is off. But I know what you mean ...
that second button is a nightmare - we have tickets for tightening all this up
Thorinchanged title from app language change somehow changed webcontent locale ??? to app language change (no spoof english) missed changing content languages but got locale
changed title from app language change somehow changed webcontent locale ??? to app language change (no spoof english) missed changing content languages but got locale