-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Correctly import zh-CN and zh-TW and remove language flags #457
Conversation
@JulianKniephoff would you approve the changes in b817e4c? |
This pull request has conflicts ☹ |
b817e4c
to
281d73a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code changes I gladly approve. ✅ They work and seem reasonable.
Regarding the language stuff I have some thoughts, but obviously I'm not a native, so take this with a grain of salt. I did some research right now, but of course I'm not immersed in these cultures, and know very little about conventions and idiomatic use of these languages/terms. However, while I don't want to question any one person in particular, I do want to put out there that being a native does not necessarily qualify someone to answer these questions. Natives can be "wrong" about their languages, especially in a situation that's politically loaded like this one. Because remember, too, that we are dealing with two languages here, but see also below. Anyway:
First of all, by now we should all know that flags aren't langauges. Of course whether or not we want to keep the flags is a bigger discussion outside the scope of this PR. I just wanted to mention it for completeness.
What we should discuss here is what our translations actually represent, especially when talking about variants like this. Officially zh_CN
is Chinese as spoken/written in the PRC, and zh_TW
is Chinese as used in Taiwan. This is also what the flags suggest. I don't know and can't really verify whether that's what's in the translation files, but as far as I'm concerned that is what we are intending to provide here: A localization that's appropriate for mainland China and another one that's appropriate for Taiwan. And people who don't fall directly into these categories probably know/have a preference about which one of those they should pick. (Same way as we don't have a Canadian English translation, but @gregorydlogan still has an opinion about which one he wants. ;D)
And it is true (generally, probably simplifying a lot here) that that maps to simplified vs. traditional Chinese writing, but that's only part of it. However, if I understand correctly, 简体中文 and 繁體中文 specify exactly that, simplified and traditional Chinese writing. So are our two Chinese translations just the same texts but written in different writing systems? I don't think so. And even if, mapping that to flags would definitely be wrong then, and also I think it's kind of weird to have that while other translations have a rather clear connection to some territory. Also, the proper codes in that case would be zh_Hans
and zh_Hant
, but I'm not sure our setup would support that.
Anyway, these specific terms might be weird for another reason:
The government of Taiwan officially refers to traditional Chinese characters as 正體字; 正体字; zhèngtǐzì; 'orthodox characters'.[9] This term is also used outside Taiwan to distinguish standard characters, including both simplified, and traditional, from other variants and idiomatic characters.[10] Users of traditional characters elsewhere, as well as those using simplified characters, call traditional characters 繁體字
—Wikipedia
So I think it's weird to use 繁體中文 as the self-description of the zh_TW
locale. IIUC it should be 正體中文, but what I'm really getting at is that we maybe should rather use the names these territories use for their own language, instead of just their writing system. Which, AFAIK, would be either 中文 for both, or 汉语 and 漢語 for PRC and Taiwan respectively.
TL;DR I propose changing this:
to either this (note again the similarity to English):
or this:
How about getting rid of the flags at all? And switch from "English/English" to "US-English/GB-English"? |
I talked with my colleague (who is a native speaker) again. She said that "简体中文" / "繁體中文" is the most common form she comes across when switching languages in games and other applications. Using 中文 for both provides the least value and the best would be to get rid of the flags all along. We could also argue why we have a German flag for the german language when there also could be a Swiss or an Australian flag used in that case... |
🚫🦘 |
Autocorrection 🤨🙄🤬 |
I'm definitely in favor of removing the flags. Regarding the wording I voiced my concerns, but I don't want to block anything with them. If Google uses these terms as well, that can of course still be wrong, but so can I, and I unfortunately don't have the resources right now to get deeper into it. 🤷♀️ One thing I would be interested in is what language codes Google maps these strings to. 🤔 |
Google uses: simplified Chinese
traditional Chinese
Crowdin provides "Chinese Simplified" ( |
281d73a
to
d8eb7b3
Compare
Use Run test server using develop.opencast.org as backend:
Specify a different backend like stable.opencast.org:
It may take a few seconds for the interface to spin up. |
@JulianKniephoff I rebased and removed the flags. Can you have a look once more? |
This pull request has conflicts ☹ |
d8eb7b3
to
7f8be75
Compare
This pull request is deployed at test.admin-interface.opencast.org/457/2024-05-31_11-19-08/ . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
src/components/Header.tsx
Outdated
onClick={() => setMenuLang(!displayMenuLang)} | ||
> | ||
<img src={currentLanguage?.flag} alt={currentLanguage?.code} /> | ||
<div className="lang" title={t("LANGUAGE")} onClick={() => setMenuLang(!displayMenuLang)}> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would get rid of the title
attribute in this case, this element is now self-describing. Also, can we get rid of the LANGUAGE
translation key then?
OR we use that as the text for the selector, not the selected language.
Or we use it as alt
for a generic language selector icon, like the typical globe or the "A文" thing you see sometimes. 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would got for the third option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JulianKniephoff which of the two icons do you prefer?
FaGlobe from "react-icons/fa"
FaLanguage from "react-icons/fa"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I prefer the globe in this case 🤔
This pull request has conflicts ☹ |
7f8be75
to
4a6ecb8
Compare
This pull request is deployed at test.admin-interface.opencast.org/457/2024-06-04_09-14-33/ . |
4a6ecb8
to
3161d44
Compare
This pull request is deployed at test.admin-interface.opencast.org/457/2024-06-04_09-56-02/ . |
@lkiesow, would you be okay with the second version, like here: #457 (comment)? I would stay within the same iconography, and that's currently FontAwesome5. We can change this at a later stage. @JulianKniephoff prefers the globe. |
This pull request has conflicts ☹ |
Sorry for the late reply. Lots of other patches drawing attention ;-) |
This fixes the garbled use of zh-CN and zh-TW. We used the flag from the one, the description of the other and only used one, so somehow got it mixed up. The strings 简体中文 and 繁體中文 were approved by a native speaker. We shouldn't be stepping on anybody's toes too badly ... Signed-off-by: Daniel Ziegenberg <[email protected]>
Removes a bunch of ts-expect-error TS(2307) Signed-off-by: Daniel Ziegenberg <[email protected]>
Signed-off-by: Daniel Ziegenberg <[email protected]>
3161d44
to
4a66fe7
Compare
This pull request is deployed at test.admin-interface.opencast.org/457/2024-06-11_15-53-53/ . |
Signed-off-by: Daniel Ziegenberg <[email protected]>
4a66fe7
to
91e75d4
Compare
This fixes the garbled use of zh-CN and zh-TW. We used the flag from the one, the description of the other and only used one, so somehow got it mixed up.
The strings 简体中文 and 繁體中文 were approved by a native speaker. We shouldn't be stepping on anybody's toes too badly ...
Apart from that we also enable importing .json files for the translations.
EDIT:
Also removing the language flags now