fix native language initial config and persistence

denys commented

2023-05-01 17:57:24 +00:00

Contributor

Fixes #305

floatingghost commented

2023-05-08 15:33:29 +00:00

Owner

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

denys commented

2023-05-08 16:14:01 +00:00

Author

Contributor

Added a respective branch, please try.

Mergan added the

Bug fix

label 2023-07-17 19:08:45 +00:00

Oneric commented

2024-02-28 19:34:33 +00:00

Member

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

denys commented

2024-02-29 15:39:07 +00:00

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.

Oneric commented

2024-02-29 20:42:54 +00:00

Member

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.

denys commented

2024-03-01 11:54:02 +00:00

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.

Oneric commented

2024-03-04 14:31:45 +00:00

Member

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.

If this is your goal, then the current patch does not achieve this. It still tries to find a match between browser and instance language first before defaulting to the user’s preferred language. So it can happen a non-preferred language is chosen (which the user might only understand to a limited degree).
Only specifically English is treated differently here and entirely discarded from the user preference, leading to the previously mentioned problems.

Now that I think about it, the defaulting to browser language is also not safe, as there might not even be a translation for it. To align with your stated goal, i guess you’d need to also search the full list of translations for the best match.

I disagree with you calling my expected result a nonsense result.

I’m calling the results of the current patch nonsensical. I doubt this is the result you expect, but it’s what will currently happen.
For more examples of what nonsense this patch yields consider the following two:

user languages in browser: ain,it;q=0.8
instance languages:  ["ar", "cs"]

This results in trying to get an Ainu translation (which does not exist (yet))
and then the interface will probably be forced to fallback to English,
i.e. a language understood by neither instance admins nor the user
(atm it choose Arabic instead, matching admins and likely posts)

user languages in browser: id,en-CA;q=0.9,vi;q=0.1
instance languages:  ["en", "vi"]

User indicates a very weak preference for Vietnamese and
and both instance and user have a much stronger preference for English.
However, due to the filtering from this patch, Vietnamese will be chosen instead, which the user might only barely understand.
(atm English will be chosen, which both understand well)

On a more general note:

This will ofc come down to personal preference, but I like the logic of trying to match user and instance language and defaulting to the instance language. Unlike some other websites, the primary content on an Akkoma instance are the posts and bios of users and those tend to match the instance languages as they form a community.
A bit different but similar logic applies to e.g. online newspapers. The frameworks used to built their sites may contain translations for many languages for basic UI elements, but to match the content ime everything always matches the article language.

Forgejo’s main content is code and can contains projects by many different people and organisations. There’s often not much overlap between different projects (not from the same org) and they might all converse in different natural languages. Therefore there’s no inherent primary natural language to use and no expectation of consistency. Defaulting to the user’s primary language is the only sane choice here.

Ofc, if someone explicitly configured another choice, this should persist, but the current patch does not achieve this.

> 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. If this is your goal, then the current patch does not achieve this. It still tries to find a match between browser and instance language first before defaulting to the user’s preferred language. So it can happen a non-preferred language is chosen (which the user might only understand to a limited degree). Only specifically English is treated differently here and entirely discarded from the user preference, leading to the previously mentioned problems. Now that I think about it, the defaulting to browser language is also not safe, as there might not even be a translation for it. To align with your stated goal, i guess you’d need to also search the full list of translations for the best match. > I disagree with you calling my expected result a nonsense result. I’m calling the results of the current patch nonsensical. I doubt this is the result you expect, but it’s what will currently happen. For more examples of what nonsense this patch yields consider the following two: ``` user languages in browser: ain,it;q=0.8 instance languages: ["ar", "cs"] ``` This results in trying to get an Ainu translation (which does not exist (yet)) and then the interface will probably be forced to fallback to English, i.e. a language understood by neither instance admins nor the user *(atm it choose Arabic instead, matching admins and likely posts)* ``` user languages in browser: id,en-CA;q=0.9,vi;q=0.1 instance languages: ["en", "vi"] ``` User indicates a _very weak_ preference for Vietnamese and and both instance and user have a much stronger preference for English. However, due to the filtering from this patch, Vietnamese will be chosen instead, which the user might only barely understand. *(atm English will be chosen, which both understand well)* --- On a more general note: This will ofc come down to personal preference, but I like the logic of trying to match user and instance language and defaulting to the instance language. Unlike some other websites, the primary content on an Akkoma instance are the posts and bios of users and those tend to match the instance languages as they form a community. A bit different but similar logic applies to e.g. online newspapers. The frameworks used to built their sites may contain translations for many languages for basic UI elements, but to match the content ime everything always matches the article language. Forgejo’s main content is code and can contains projects by many different people and organisations. There’s often not much overlap between different projects (not from the same org) and they might all converse in different natural languages. Therefore there’s no inherent primary natural language to use and no expectation of consistency. Defaulting to the user’s primary language is the only sane choice here. Ofc, if someone explicitly configured another choice, this should persist, but the current patch does not achieve this.

ci/woodpecker/pr/woodpecker Pipeline was successful

Details

This pull request has changes conflicting with the target branch.

src/modules/config.js

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u fix-native-language:denys-fix-native-language

git checkout denys-fix-native-language

fix native language initial config and persistence #308

Checkout