better l18n support in webview (navigator. language)

[eike-hass]

Is your feature request related to a problem? Please describe.
I want to rely on navigator.language or navigator.languages in the webview to determine which language a user prefers and to then translate the app.

On WSL 2 / Ubuntu 20 the language is just "c", on Windows 10 with WebView2 it does not respect language settings on the system or browser (Edge) level, on native Ubuntu 20 it had a language that was actually more accurate then the system setting, but did not respect the system setting as well. I don't have access to a macos device.

Describe the solution you'd like
Ideally navigator.language or navigator.languages contain languages that match the system level user preferences.

Describe alternatives you've considered
One could call system level APIs (different for every platform, i guess) from Rust to determine the preferences and expose those to Rust and finally the webview. Without changing navigator.language or navigator.languages this approach is not ideal, because some libraries rely on those fields. Maybe an approach where those preferences are exposed on the navigator and additionally have exposed to Rust and Webview via functions.

[amrbashir]

/upstream tauri-apps/wry

[tauri-apps]

I have created an upstream issue at tauri-apps/wry#442, I will notify you once it is resolved.

[amrbashir]

A fix has landed upstream but navigator.langagues still returns ["en-US", "en"] although every setting in my Windows is changed to Arabic. There is nothing we can do about this apparently since the issue also exists in Edge chromium and all chromium-based browsers so a fix should land in chromium first.

The upstream fix does have a desired effect on some other i18n components like new Date().toLocaleString()

I am gonna close this issue as we've done everything we can. We probably can provide a separate function to retrieve OS languages in our JS API. Feel free to open another issue for that.

[John0x]

A fix has landed upstream but navigator.langagues still returns ["en-US", "en"] although every setting in my Windows is changed to Arabic. There is nothing we can do about this apparently since the issue also exists in Edge chromium and all chromium-based browsers so a fix should land in chromium first.

The upstream fix does have a desired effect on some other i18n components like new Date().toLocaleString()

I am gonna close this issue as we've done everything we can. We probably can provide a separate function to retrieve OS languages in our JS API. Feel free to open another issue for that.

Is there currently a way to get the preferred language? Can't find anything the JS API.

[Miniontoby]

Why don't we add code to do set the navigator.language?

In Cargo.toml:

(...)

[dependencies]
current_locale = "*"
(...)

In rust:

use current_locale::*;

(...)

#[tauri::command]
fn get_user_language() -> String {
  let current_locale = current_locale::current_locale();
  if (current_locale.is_ok()){
    return current_locale.ok().unwrap();
  }
  return "en-US".to_string();
}

In the code for the frontend functions:

import { invoke } from '@tauri-apps/api/tauri';

(...)

// Add in some async function
navigator.language = await invoke('get_user_language');