Ryujinx
Ryujinx copied to clipboard
Ryujinx
Avalonia - Display language names in their corresponding language under "Change Language"
Currently, all names in the language change menu are in English no matter what you choose.
This PR changes it to display them in their native names, as most software and websites do.
Some might not be correct since I went off translators and google searches for their names, namely the Asian languages. If that's the case I'll change them.
Alphabetical sorting. I had to run Chinese, Korean, Russian and Greek through a couple online alphabetizers and then checked the result against other websites and software that also sort their languages like this.
Japanese (日本語) seems to go second-to-last, after Chinese (汉语, 汉语), but before Korean (한국어).
It's better to use "简体中文" for simplified Chinese "繁體中文" for traditional Chinese. Which is widely spoken by people. 漢語/汉语 is less commonly used today and only indicates the oral language but not the writing system
I would prefer to list both an English notation and a native one. For example: "Castilian Spanish / Español (ES)" "Simplified Chinese / 简体中文" The string length will be a little longer, but the sort order will be clearer. What do you think?
Download the artifacts for this pull request:
- ryujinx-Release-1.1.0+49081d6-linux_x64
- ryujinx-Release-1.1.0+49081d6-osx_x64
- ryujinx-Release-1.1.0+49081d6-win_x64
Experimental GUI (Avalonia)
GUI-less (SDL2)
Only for Developers
- ava-ryujinx-Debug-1.1.0+49081d6-linux_x64
- ava-ryujinx-Debug-1.1.0+49081d6-osx_x64
- ava-ryujinx-Debug-1.1.0+49081d6-win_x64
- ryujinx-Debug-1.1.0+49081d6-linux_x64
- ryujinx-Debug-1.1.0+49081d6-osx_x64
- ryujinx-Debug-1.1.0+49081d6-win_x64
- sdl2-ryujinx-headless-Debug-1.1.0+49081d6-linux_x64
- sdl2-ryujinx-headless-Debug-1.1.0+49081d6-osx_x64
- sdl2-ryujinx-headless-Debug-1.1.0+49081d6-win_x64
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
i often see applications translating other language names which is a bad user expierence. imagine changing to chinese by accidend and ull never be able to find your language again.
Same goes for the form field label Language:, its better to not translate this so user will find it easier when they choosed the wrong language.
good that its going to be changed in ryu.
You could also add the english or translated name in brackets after the origin name. Deutsch (German). But doesnt matter much.
I would prefer to list both an English notation and a native one. For example: "Castilian Spanish / Español (ES)" "Simplified Chinese / 简体中文" The string length will be a little longer, but the sort order will be clearer. What do you think?
But the other way around, first the origin language name, then the translated language name (e.g. in case the language might get cutted off if too large)
i often see applications translating other language names which is a bad user expierence. imagine changing to chinese by accidend and ull never be able to find your language again.
Same goes for the form field label
Language:, its better to not translate this so user will find it easier when they choosed the wrong language.good that its going to be changed in ryu.
You could also add the english or translated name in brackets after the origin name.
Deutsch (German). But doesnt matter much.I would prefer to list both an English notation and a native one. For example: "Castilian Spanish / Español (ES)" "Simplified Chinese / 简体中文" The string length will be a little longer, but the sort order will be clearer. What do you think?
But the other way around, first the origin language name, then the translated language name (e.g. in case the language might get cutted off if too large)
As seen from the images, the language you understand would be in the form that you understand. If you switch to Chinese by mistake, English will still be English in the Chinese text.
And also, you should never assume a default or fallback language when localizing. Everything that's not technical should be in the localized language. Language: no matter where it will be, would be translated.
Putting the translated name before the ISO Locale name will make sorting and finding the language you want harder.
And also, you should never assume a default or fallback language when localizing. Everything that's not technical should be in the localized language.
Language:
which is bad user experience and should not be, the rest is the same as i said.
How do u want change the language back if i switched it by accident, in this case it not that hidden, but there are applications which alot of settings and a user could search for hours.
spot the language change entry
And also, you should never assume a default or fallback language when localizing. Everything that's not technical should be in the localized language.
Language:which is bad user experience and should not be, the rest is the same as i said.
How do u want change the language back if i switched it by accident, in this case it not that hidden, but there are applications which alot of settings and a user could search for hours.
spot the language change entry
There's only 1 place the language can be changed. The same place you accidentally switched it. It's also done in 2 actions, not one. The option too, is separated by visible lines. It's not part of a section with lots of options. Once again, localizers do not assume a default language. There are places in the world where knowledge of English isn't necessary, even on the internet. Even if a word like Language can be easily understood by anyone, having an English common word right in the middle of Japanese options, for example, does not improve UX
Localizers use tricks to let users know where the language options are. Usually it's a globe icon, the 2 letter ISO locale name, or a place away from most other options or links on the page, together with an icon. They never leave a word in English, unless it's technical