fix native language initial config and persistence #308

Open
denys wants to merge 1 commits from denys/akkoma-fe:fix-native-language into develop
Contributor

Fixes #305

Fixes #305

i'm not sure this one quite works

a browser's languages will be listed in priority order, for example i have mine set to en-GB, ja-JA

the way this is currently implemented works for non-native-english-speakers, but not native english speakers that speak another language - since it will select the first non-english, in my case, ja-JA, when i would expect en-GB, it being my primary language and all

i'm not sure this one quite works a browser's languages will be listed in priority order, for example i have mine set to `en-GB, ja-JA` the way this is currently implemented works for non-native-english-speakers, but not native english speakers that speak another language - since it will select the first non-english, in my case, `ja-JA`, when i would expect `en-GB`, it being my primary language and all
denys force-pushed fix-native-language from 98a1f44024 to ae6fe3c5c8 2023-05-08 16:08:34 +00:00 Compare
Author
Contributor

Added a respective branch, please try.

Added a respective branch, please try.
Mergan added the
Bug fix
label 2023-07-17 19:08:45 +00:00
Contributor

For the record:

  • the setting not persisting is just a UI bug where the storage call is not dispatched and can be worked around (see #305 (comment) )
  • imho the special-casing and filtering out of English locale entries done in this patch is a bad idea. Even with the added check a user browser config like ja-JA; en-GB; fr-FR and instance language set of en; it; would still yield unexpected results afaict.
  • i also have doubts about defaulting to a language not understood by instance admins. It might give new users the impression/expectation their native language is understood by admins and if the user doesn’t have any language in common with admins, joining a different instance might be better for both sides
For the record: - the setting not persisting is just a UI bug where the storage call is not dispatched and can be worked around *(see https://akkoma.dev/AkkomaGang/akkoma-fe/issues/305#issuecomment-11137 )* - imho the special-casing and filtering out of English locale entries done in this patch is a bad idea. Even with the added check a user browser config like `ja-JA; en-GB; fr-FR` and instance language set of `en; it;` would still yield unexpected results afaict. - i also have doubts about defaulting to a language not understood by instance admins. It might give new users the impression/expectation their native language is understood by admins and if the user doesn’t have any language in common with admins, joining a different instance might be better for both sides
Author
Contributor

Thanks for your review! I can reproduce the dispatch lack that you're describing, and I didn't notice it at the time of writing the patch. However, my patch addresses another part of the issue, namely client-side persistence for users who are not members of the instance but read it once in a while, for example by clicking links from another instance to open complete original threads in background tabs. Instances can reject guest state storage with a 403, but the cookie survives through that, and also the cookie can help the static renderer (I think). And I'd like to add emphasis that special-casing English is what de facto happens by neglecting the user's language, rushing to fall back to English as early as possible. While I read mainly international instances with mostly English-language posts, that doesn't mean I expect their UI to disregard my preference for my language, which I explicitly configure my browser to ask every website for.

Thanks for your review! I can reproduce the dispatch lack that you're describing, and I didn't notice it at the time of writing the patch. However, my patch addresses another part of the issue, namely client-side persistence for users who are not members of the instance but read it once in a while, for example by clicking links from another instance to open complete original threads in background tabs. Instances can reject guest state storage with a 403, but the cookie survives through that, and also the cookie can help the static renderer (I think). And I'd like to add emphasis that special-casing English is what de facto happens by neglecting the user's language, rushing to fall back to English as early as possible. While I read mainly international instances with mostly English-language posts, that doesn't mean I expect their UI to disregard my preference for my language, which I explicitly configure my browser to ask every website for.
Contributor

if it wasn’t clear btw, my opinion has no influence on what gets merged, i’m just offering my point of view here

And I'd like to add emphasis that special-casing English is what de facto happens by neglecting the user's language, rushing to fall back to English as early as possible.

That’s not what happens atm though. It takes a look at the list of languages configured in the user’s browser and the list of languages supplied by the instance admin and takes the first entry in the user’s list which overlaps with the instance languages. If they have no entry in common, the most preferred language of the instace admin gets chosen. None of this is hardcoded to English.

The only "special-casing" of English in the current code are afaiu:

  • for a brief moment before the search for overlapping languages starts things are initialised to en; since this is almost immediately overwritten again, it doesn’t matter in practice
  • The “instance language” config in the backend defaults to listing only English. This makes sense, since it is the project’s primary language and bias. Every new string is first added in English and only later localised by translators; it is thus the only guaranteed to be complete and consistent language.
    Ofc, this doesn’t suit everyone, which is why instance admins can and should customise this to match what’s being understood and used on the instance. The ["en"] default is only used when admins didn’t configure this.

Your current patch meanwhile, blindly assumes no users want’s to see English if it’s not their first entry. As pointed out above this leads to nonsense results in all cases where English appears at a different place.

namely client-side persistence for users who are not members of the instance but read it once in a while

I have no issue and think it’d be a good idea to persist explicit configuration by logged-out users, e.g. in the browser’s storage or some other local form. However:

the [userLangauge] cookie survives through that

Does it? When I edit the cookie on my end (when not logged in) to use a different langauge and match your adjustments, then reload the page it always gets overwritten again with the value from the frontend config.
Have you tried persisting a value not in your browser locales?

Frontend settings are stored as a JSON blob in the browser’s indexdb, but atm get discarded after the session. I believe, if you could figure out why they get discarded and make them persist instead (while not breaking configs for users logging in), this seems like the ideal outcome to me.
Stuff will default to the common denominator between admins and the user, probably also somewhat matching the primary post languages, but explicit configuration for other interface languages persists even for logged-out users.

if it wasn’t clear btw, my opinion has no influence on what gets merged, i’m just offering my point of view here > And I'd like to add emphasis that special-casing English is what de facto happens by neglecting the user's language, rushing to fall back to English as early as possible. That’s not what happens atm though. It takes a look at the list of languages configured in the user’s browser and the list of languages supplied by the instance admin and takes the first entry in the user’s list which overlaps with the instance languages. If they have no entry in common, the most preferred language of the instace admin gets chosen. None of this is hardcoded to English. The only "special-casing" of English in the *current* code are afaiu: - for a brief moment before the search for overlapping languages starts things are initialised to `en`; since this is almost immediately overwritten again, it doesn’t matter in practice - The “instance language” config in the backend defaults to listing only English. This makes sense, since it is _the project’s_ primary language and bias. Every new string is first added in English and only later localised by translators; it is thus the only guaranteed to be complete and consistent language. Ofc, this doesn’t suit everyone, which is why instance admins can and should customise this to match what’s being understood and used on the instance. The `["en"]` default is _only_ used when admins didn’t configure this. Your current patch meanwhile, blindly assumes no users want’s to see English if it’s not their first entry. As pointed out above this leads to nonsense results in all cases where English appears at a different place. > namely client-side persistence for users who are not members of the instance but read it once in a while I have no issue and think it’d be a good idea to persist _explicit_ configuration by logged-out users, e.g. in the *browser’s* storage or some other local form. However: > the [userLangauge] cookie survives through that Does it? When I edit the cookie on my end (when not logged in) to use a different langauge and match your adjustments, then reload the page it always gets overwritten again with the value from the frontend config. Have you tried persisting a value not in your browser locales? Frontend settings are stored as a JSON blob in the browser’s indexdb, but atm get discarded after the session. I believe, if you could figure out why they get discarded and make them persist instead (while not breaking configs for users logging in), this seems like the ideal outcome to me. Stuff will default to the common denominator between admins and the user, probably also somewhat matching the primary post languages, but explicit configuration for other interface languages persists even for logged-out users.
Author
Contributor

I appreciate your opinion nonetheless; your understanding of the engine is more up-to-date and thorough. I haven't contributed since my instance got nuked by Google Safe Browsing quite early in its existence. I spent a month trying to recover the organization domain, and Google only relented after I deleted all my opinions and Akkoma itself.

If they have no entry in common, the most preferred language of the instace admin gets chosen.

From what I observe, that is a source of systemic bias in favor of English (browser weights contain English by default, and fedi instances are predominantly US/UK/EU-owned while being explored by people from the periphery countries), and I disagree with you calling my expected result a nonsense result. If the user sets Japanese as their primary preference for the web, and the web application they open contains a Japanese translation, I think they should see a Japanese UI. I like that Forgejo behaves this way.

Have you tried persisting a value not in your browser locales?

Tbh no.

I appreciate your opinion nonetheless; your understanding of the engine is more up-to-date and thorough. I haven't contributed since my instance got nuked by Google Safe Browsing quite early in its existence. I spent a month trying to recover the organization domain, and Google only relented after I deleted all my opinions and Akkoma itself. > If they have no entry in common, the most preferred language of the instace admin gets chosen. From what I observe, that is a source of systemic bias in favor of English (browser weights contain English by default, and fedi instances are predominantly US/UK/EU-owned while being explored by people from the periphery countries), and I disagree with you calling my expected result a nonsense result. If the user sets Japanese as their primary preference for the web, and the web application they open contains a Japanese translation, I think they should see a Japanese UI. I like that Forgejo behaves this way. > Have you tried persisting a value not in your browser locales? Tbh no.
All checks were successful
ci/woodpecker/pr/woodpecker Pipeline was successful
This pull request has changes conflicting with the target branch.
  • src/modules/config.js
Sign in to join this conversation.
No description provided.