Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shared link user interface language forced by default_language #970

Closed
kohtala opened this issue Aug 19, 2016 · 10 comments
Closed

Shared link user interface language forced by default_language #970

kohtala opened this issue Aug 19, 2016 · 10 comments
Assignees
Labels
bug papercut Annoying recurring issue with possibly simple fix.

Comments

@kohtala
Copy link

kohtala commented Aug 19, 2016

Steps to reproduce

  1. Configure config/config.php default_language to a language.
  2. Configure your browser languages (Firefox 48 Option / Content / Languages) so it sends Accept-Language header with a languages different from default_language.
  3. Share a link.
  4. Open the link with your browser.

Expected behaviour

The shared link opens with the language the browser sends.

Actual behaviour

The shared link opens in default_language.

config/config.sample.php default_language documents that "It overrides automatic language detection on public pages like login or shared items." So it works as documented. However it is not what I expected.

I had set (before reading the documentation) that default_language would be used if the HTTP client did not specify a language. This can happen for example if Firefox has no languages configured.

We have non-English locale fi, and share links with other non-English locales. Our biggest user space is in our locale, so having a default language in absense of Accept-Language in our locale instead of English makes sense. However if a link is shared with a user in other non-English locale, a default_language of fi gives the link recipient user interface in Finnish and he does not understand it. There is no means for him to change the language, as he has no account and no user preferences to change. He might be sending Accept-Language for user interface in familiar language, but it is ignored.

Server configuration

Nextcloud version: Nextcloud 9.0.53 (stable)

Updated from an older Nextcloud/ownCloud or fresh install: fresh

Where did you install Nextcloud from: nextcloud.com .tar.bz2

Signing status:
No errors have been found.

@rullzer
Copy link
Member

rullzer commented Aug 19, 2016

Mmm seems we do something bad then in the public view.
Let me take a look at this.

@rullzer rullzer self-assigned this Aug 19, 2016
@rullzer rullzer added bug papercut Annoying recurring issue with possibly simple fix. labels Aug 19, 2016
@rullzer
Copy link
Member

rullzer commented Aug 19, 2016

Ok while thinking some more about it. I guess I understand the default behaviour a little bit better now.

I think it is mainly done because of the assumption that most users don't bother setting their language properly. But admins still want to set the default language for an installation. Else 99% of the users will get the englisch interface.

Let me run some tests how we handle this further.

@rullzer
Copy link
Member

rullzer commented Aug 19, 2016

Ok I think I got it.

There are 3 settings here that are relevant

A. Users settings in personal settings
B. Admins default language settings
C. Accept-Language settings of the browser

Now if you are logged in the order is: ABC
Which makes sense since 'by default' an institution might want to set the language to X. Or I for example have it set to dutch for all my relatives. Which is fine since I can still change language for me in A anyway.

However if you are not logged in the order should be ACB. A is obviously irrelevant. So we should prefer the browser language.

@kohtala @MorrisJobke do you agree?

@kohtala
Copy link
Author

kohtala commented Aug 19, 2016

https://www.w3.org/International/questions/qa-lang-priorities seems to suggest that if set the Accept-Language is set, it is set to a value the user can understand. No browser has it set to a default value that would not match the user interface of the operating system or browser.

Therefore I think it is safe to use ACB also when logged in.

Reading OC\L10N\Factory::findLanguage, it seems to set the user setting if it takes the language from Accept-Language. I do not see why. So it uses Accept-Language only once.

I did a bit further study on this. I found that Google recommends using different URL for different languages and cross linking each language version of the page (https://support.google.com/webmasters/answer/182192). It is not entirely relevant for Nextcloud as it is not indexed for search engines, but different URL for different languages would allow not logged in user easy access to other versions of the page in different languages without requiring change of browser settings. URL structure could stay the same if the difference was a parameter like "?lang=de" in the URL. I am not sure if it should be interpreted in OC\L10N\Factory::findLanguage before reading the user preference, or later in setLanguageFromRequest before using the Accept-Language.

http://webmasters.stackexchange.com/questions/84195 has an answer hinting that Accept-Language could be used to offer user the links to preferred language versions of the page. If default_language has a reason to override Accept-Language, or the URL had ?lang=, and Accept-Language has other languages besides default_language or ?lang=, then Nextcloud could offer users that are not logged in languages they understand.

I think these give good ideas which way to go with this, but require some more thought.

@rullzer
Copy link
Member

rullzer commented Aug 21, 2016

After thinking some more I have to agree with you that 'by default' we want to use ACB. I'll prepare a patch.

@MorrisJobke
Copy link
Member

After thinking some more I have to agree with you that 'by default' we want to use ACB. I'll prepare a patch.

Makes sense 👍

@rullzer
Copy link
Member

rullzer commented Aug 30, 2016

Ah right still need to do it. Will bump it on the list for this week. I already have a patch kind of in place. But I want proper tests to make sure it actually works :P

@LukasReschke LukasReschke added this to the Nextcloud 10.0.1 milestone Aug 30, 2016
rullzer added a commit that referenced this issue Sep 4, 2016
See #970

Before we had

1. Users settings in personal settings
2. Admins default language settings
3. Accept-Language settings of the browser

However this is not in line with
https://www.w3.org/International/questions/qa-lang-priorities

So this changes the order to

1. Users settings in personal settings
3. Accept-Language settings of the browser
2. Admins default language settings
@rullzer
Copy link
Member

rullzer commented Sep 4, 2016

PR in #1259

@rullzer
Copy link
Member

rullzer commented Sep 5, 2016

PR merged => Closing

@kohtala
Copy link
Author

kohtala commented Sep 5, 2016

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug papercut Annoying recurring issue with possibly simple fix.
Projects
None yet
Development

No branches or pull requests

4 participants