❓ Support
Subarist Subarist May 30, 2023

Only English Interface Displayed When Not Logged In, Despite Different Language Settings

When logged in, the language setting switches correctly. setting 'faker_locale' doesn't make a difference.
However, if there is no language setting option on the main page, should it be displayed based on the admin's settings?

image.png
image.png

I have uploaded the Traditional Chinese (zh-Hant) language pack, but I am not familiar with PR operations. Perhaps you can assist in confirming. @Toby
https://github.com/efast1568/core/tree/main/lang

Answered by Subarist Subarist

I know why we misunderstood...
It's so small that I didn't notice it 😅
especially when the navi bar is a bit long...

Can we specify a default language?

image.png

View Answer

⁨5⁩ ⁨Comments⁩

Toby Toby Waterhole Founder May 30, 2023

I'm not sure I quite understand the problem, so I'll just explain how the language system works.

In order to become available, languages must be registered using the Locales extender. For example, in WaterholeServiceProvider, you would add:

Extend\Locales::add('Traditional Chinese', 'zh-Hant');

Waterhole uses the following algorithm to determine which language to use:

  1. If the user has selected a language, use that. (If they are logged in, it's stored in their preferences; otherwise it's stored in the session.)
  2. Otherwise, use the closest matching preferred language from the Accept-Language header sent by the browser.

The app.locale setting is not actually used for Waterhole requests.

You should keep app.fallback_locale set to en so that any strings that don't have a zh translation will fall back to English instead of printing out the translation key.

Toby Toby Waterhole Founder Jun 4, 2023
In reply to Subarist Subarist

Can we specify a default language?

In most cases you shouldn't need to, since Waterhole defaults to the closest matching preferred language to the Accept-Language header sent by the browser. If there's no good match, it will default to the first locale defined in Extend\Locales (English). If you needed to change this you could remove the English locale:

Extend\Locales::remove('en');
In reply to Toby Toby

After several days of testing and interaction with other site admins, we suggest that it is still necessary to have a "default" language parameter instead of removing the "EN" language option.

In most non-English operating systems, browsers cannot accurately determine the language automatically.
This situation is similar to some flrum extensions where, in our usage environment, the current language cannot be automatically detected.

Alternatively, there are scenarios where users are accustomed to operating in an English environment but visit a new discussion forum where they would like to see the familiar language menu directly.
Furthermore, English is the primary international language and it serves a necessary purpose.

Therefore, if circumstances permit, having a default language option would be a popular choice.

Update Note:
In some non-EN language environments, Accept-Language may not be correctly detected.
If you need to change the default language, try modify the following code.

/Middleware/Localize.php

        // Retrieve the user's locale preference, either from the user model if
        // logged in, or from the session or browser preference otherwise.
        if ($user) {
            $locale = $user->preferredLocale();
        } else {
            $locale = session(static::SESSION_KEY, $request->getPreferredLanguage($locales));
        }

remove: $request->getPreferredLanguage($locales)

        // Retrieve the user's locale preference, either from the user model if
        // logged in, or from the session or browser preference otherwise.
        if ($user) {
            $locale = $user->preferredLocale();
        } else {
            $locale = session(static::SESSION_KEY);
        }