Standardize language selector labels to local script + English name

[indpriyanshuraj]

Environment

• Android Version: Android 16
• LeviLaunchroid Version: 1.5.8

Description

The language selector should display every option in a consistent local script + English name format.

At the moment, the list appears to show languages only in their native script. That is fine for users who already understand the script, but it becomes awkward when someone accidentally switches to a language they cannot read.

Showing the English name alongside the local name would make the menu easier to scan and much easier to recover from.

Current Behavior

Language options are displayed only in their local script, such as:

• हिंदी
• 日本語
• Русский

video_20260709_153923.mp4

Proposed Behavior

Each language option should follow a consistent format like:

• [Local Script] ([English Name])

Examples:

• हिंदी (Hindi)
• 日本語 (Japanese)
• Español (Spanish)
• Français (French)
• Русский (Russian)
• 简体中文 (Chinese)

Why This Matters

If a user changes the launcher to a language they cannot read, they may get stuck in the settings menu without an obvious way back. The English label works as a clear indicator and makes the selector more beginner-friendly.

It also keeps the language list more consistent and professional across all locales.

Additional Context

Applying this rule globally in the translation files would keep the language selector readable, accessible, and easier to navigate for everyone.

[indpriyanshuraj]

• [Minor improvement] Sort language list alphabetically (while keeping English pinned at the top) #291
• Inconsistent formatting for the “Language” label across locales #328
• Standardize language selector labels to local script + English name #329

I'd like to work on these above issues for improvements. I will open a Pull Request with the proposed implementation for review and feedback.

[Viablecobra]

Tf you mean scan and recover?

[Viablecobra]

Local script 😭✌🏻

[indpriyanshuraj]

Tf you mean scan and recover?

@Viablecobra
I mean to see and fix(for the situation were if person has clicked wrong language and then it doesn't able to read and find)

When name will be written in both languages (local and english) ,then user will able to read English and find language name

[Viablecobra]

sUs

[indpriyanshuraj]

I've finished implementing the proposed changes for three issues after 1h. I'll be opening a PR shortly that addresses them for review.

I find it a bit confusing that you think users can't find their language and have to look at the English version to know it's their language?

[indpriyanshuraj]

@owjgbxkks Some user or some Child(maybe mostly they will play)
By mistake if they click another language (which they don't know to read), then it becomes hard for them to find

Yes they will find but it will take more time, for better user experience , just adding those english name which be more helpful

Even this is very silly and rare to happen, but it happens with some user like me.

@indpriyanshuraj I don't know why you're having trouble getting into that situation,because after changing the language, the user is still in the settings area and the language selection box is darker than background, so it's quite easy to spot and click to find that language :)

[indpriyanshuraj]

@owjgbxkks because I had face such issues in my childhood when phone become laggy , sometimes app get closes during misclick,then finding take little more time

But that a simple thing which makes it fast to find(even 2s is important) and for future when there will 100 of language in app, it would more helpful

Mainly this will give consistency to code and ui for naming.

[indpriyanshuraj]

I had already implemented such things(#291 #328 #329) in my pr #330

@indpriyanshuraj Assuming it really did fail for some reason, your pull request only modified the language switching area. If they actually found that area, as I said, they could immediately see the language switching box. And after clicking on it, how could they find their language within it a few seconds faster? I mean, the position of the languages before and after the incorrect switch doesn't change, right:)? (A bit off-topic, why do you keep denying the use of AI? I don't think note in the pull request code are human-made)