Attempted to resolve locale that does not exist

[gnh1201]

Describe the bug The WebUI attempts to resolve a locale that does not exist. Eventually, WebUI rendering fails.

To Reproduce This issue can be seen by accessing the WebUI from a non-English desktop.

Expected behavior If the locale does not exist, it should be automatically resolved as en.

Screenshots

Desktop (please complete the following information):

• OS: Windows 10
• Browser: Chrome
• Version: 103

Additional context

Nothing

[welcome[bot]]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review. In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment. Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

[lidel]

ipfs-webui will read locale sent by your browser, and look for the best variant available. this search is done via http requests, and getting 404 (Not Found) for some of them is part of the process (not a bug), and if no match is found en is used as the last resort fallback.

We have ko-KR here, if you want to improve it you can join project at https://www.transifex.com/ipfs/ipfs-webui/dashboard/

closing as there is no bug here.

[gnh1201]

I'm sorry, but could you take a look again? It's attempting to connect ko/status.json, not ko-KR/status.json.

There seems to be a problem with handling notation such as **-**.

[lidel]

@gnh1201 ack, let's double-check:

• is your browser sending requests only for ko and none for ko-KR? (or both?)
• are you able to share "Request headers" your browser sends (namely, Accept-Language one)?

[gnh1201]

Thank you :) Here are the Accept-Language header values.

• Chrome 104: en-US,en;q=0.9,ko-KR;q=0.8,ko;q=0.7
• Edge 104: ko,en;q=0.9,en-US;q=0.8

[lidel]

• In Chrome, your browser should send requests for both ko and ko-KR versions. Is that not ther case?
• In Edge, is the problem that your browser does not attempt to read ko-KR?

(The connection error you experience is not related to locales)

[gnh1201]

ko and ko-KR are the same locale. ko should automatically be set to ko-KR.

In Chrome, your browser should send requests for both ko and ko-KR versions. Is that not ther case? In Edge, is the problem that your browser does not attempt to read ko-KR?

I know that this problem is because there is no translation file for ko. However, since ko and ko-KR are the same, ko should be automatically mapped to ko-KR.

(The connection error you experience is not related to locales)

[SgtPooki]

Thanks for your input! Seems like our todo list should be:

• [ ] reproduce this error
• [ ] no translation file for ko
• [ ] ko should be automatically mapped to ko-KR.

[ipfs-gui-bot]

:tada: This issue has been resolved in version 2.18.0 :tada:

The release is available on GitHub release

Your semantic-release bot :package::rocket: