Skip to content

Conversation

@joshtrichards
Copy link
Member

@joshtrichards joshtrichards commented Dec 29, 2024

Closes #23486 (+possibly other locale related matters)

Summary

The initial Locale shown in the Personal info page is not the actual locale in-use. Besides being a bug in itself, it likely has resulted in some confusing bug reports about other aspects of Nextcloud not following the apparently active locale within an individual account.

Details

Given the following sent by the browser:

Accept-language: en-US,en;q=0.5

Results in our templates returning:

<html class="ng-csp" data-placeholder-focus="false" lang="en" data-locale="en" translate="no" >

Which is fine I guess, but it does not match what is displayed on the Personal info page for this user. The Locale, instead, is shown as "English (United States)" (it should be just "English" given data-locale="en").

Some environments likely work around this by setting the default_locale and/or force_locale config paremeters (which short circuit the fall back code detailed below).

Cause

We call findLocal() in two different ways, which produces different fallback return values. In our templates we call it with the currently determined language:

if ($locale === null || !$this->localeExists($locale)) {
$locale = $this->findLocale($lang);

...which means if a user doesn't have a locale saved yet we hit this fallback code:

// If no user locale set, use lang as locale
if ($lang !== null && $this->localeExists($lang)) {
return $lang;

This returns the language (en in my test case) as the fallback locale under all circumstances. This is why data-locale is set to en.

But when the user loads up their Personal settings we populate the active locale without providing the language clue to findLocale():

$userLocaleString = $this->config->getUserValue($uid, 'core', 'locale', $this->l10nFactory->findLocale());

...So we hit a different fallback:

// At last, return USA
return 'en_US';
}

The result is this field is only accurate if the user changes their locale since that triggers a save to the preferences table. At best this is confusing, at worst this leads to bug reports about things not being formatted per the locale that is indicated as being active.

This explains why the Personal settings page always shows me the right thing (for an English speaker in the US), but behavior elsewhere in Nextcloud doesn't match it until I toggle it to something else then back which triggers a save (such as in #23486).

This also [likely] means visitors with a base language other than English sent in their browser Accept-Language header get their real fallback locale set to their language (reasonable), but their Personal info page will show "English (United States)" until they toggle it (triggering a save).

This was discovered when looking into #23486 and revisiting my initial quick fix in #49986.

TODO

  • ...

Checklist

@joshtrichards
Copy link
Member Author

/backport to stable30

@joshtrichards
Copy link
Member Author

/backport to stable29

@nickvergessen
Copy link
Member

Cypress is fixed, OCI is flaky sometimes, DAV is unrelated as far as I'm aware.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Unit for temperature in dashboard weather widget is always Celsius

4 participants