Skip to content
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

Merged
merged 4 commits into from
Jun 11, 2024

Conversation

ziegenberg
Copy link
Member

@ziegenberg ziegenberg commented May 24, 2024

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

@ziegenberg ziegenberg added the type:bug Something isn't working label May 24, 2024
@ziegenberg
Copy link
Member Author

@JulianKniephoff would you approve the changes in b817e4c?

Copy link
Contributor

This pull request has conflicts ☹
Please resolve those so we can review the pull request.
Thanks.

@ziegenberg ziegenberg force-pushed the fix-i18n-languages branch from b817e4c to 281d73a Compare May 25, 2024 16:11
@JulianKniephoff JulianKniephoff self-assigned this May 27, 2024
@JulianKniephoff JulianKniephoff self-requested a review May 27, 2024 12:53
Copy link
Member

@JulianKniephoff JulianKniephoff left a 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:

image

to either this (note again the similarity to English):

image

or this:

image

@ziegenberg
Copy link
Member Author

How about getting rid of the flags at all? And switch from "English/English" to "US-English/GB-English"?

@ziegenberg
Copy link
Member Author

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...

@ziegenberg
Copy link
Member Author

That's what Google offers when switching languages:
Screenshot from 2024-05-28 16-17-15

For traditional Chinese, they also offer a country selection:
Screenshot from 2024-05-28 16-17-29

@ziegenberg ziegenberg added the discuss in dev meeting Pull requests that should be discussed in the dev meeting on tuesdays label May 28, 2024
@geichelberger
Copy link
Contributor

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...

🚫🦘

@ziegenberg
Copy link
Member Author

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 🤨🙄🤬

@JulianKniephoff
Copy link
Member

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. 🤔

@ziegenberg
Copy link
Member Author

Google uses:

simplified Chinese

  • zn-CN with 简体中文

traditional Chinese
This has a country selection and then either

  • zh-TW with 繁體中文
  • zh-HK with 繁體中文
  • zh-MO with 繁體中文

Crowdin provides "Chinese Simplified" (zn-CN) and "Chinese Traditional" (zn-TW), and then "Chinese Traditional" with the addition of Hongkong, Macau and Singapore.

image

@ziegenberg ziegenberg force-pushed the fix-i18n-languages branch from 281d73a to d8eb7b3 Compare May 30, 2024 14:32
Copy link
Contributor

github-actions bot commented May 30, 2024

Use docker or podman to test this pull request locally.

Run test server using develop.opencast.org as backend:

podman run --rm -it -p 127.0.0.1:3000:3000 ghcr.io/opencast/opencast-admin-interface:pr-457

Specify a different backend like stable.opencast.org:

podman run --rm -it -p 127.0.0.1:3000:3000 -e PROXY_TARGET=https://stable.opencast.org ghcr.io/opencast/opencast-admin-interface:pr-457

It may take a few seconds for the interface to spin up.
It will then be available at http://127.0.0.1:3000.
For more options you can pass on to the proxy, take a look at the README.md.

@ziegenberg ziegenberg removed the discuss in dev meeting Pull requests that should be discussed in the dev meeting on tuesdays label May 30, 2024
@ziegenberg ziegenberg changed the title Correctly import zh-CN and zh-TW Correctly import zh-CN and zh-TW and remove language flags May 30, 2024
@ziegenberg
Copy link
Member Author

@JulianKniephoff I rebased and removed the flags. Can you have a look once more?

Copy link
Contributor

This pull request has conflicts ☹
Please resolve those so we can review the pull request.
Thanks.

Copy link
Contributor

This pull request is deployed at test.admin-interface.opencast.org/457/2024-05-31_11-19-08/ .
It might take a few minutes for it to become available.

@JulianKniephoff JulianKniephoff self-requested a review June 3, 2024 09:59
Copy link
Member

@JulianKniephoff JulianKniephoff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some nitpicks in the code.

For everyone's convenience, this is what it looks like now:

image

tsconfig.json Outdated Show resolved Hide resolved
src/components/Header.tsx Outdated Show resolved Hide resolved
onClick={() => setMenuLang(!displayMenuLang)}
>
<img src={currentLanguage?.flag} alt={currentLanguage?.code} />
<div className="lang" title={t("LANGUAGE")} onClick={() => setMenuLang(!displayMenuLang)}>
Copy link
Member

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. 🤔

Copy link
Member Author

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.

Copy link
Member Author

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"

Screenshot from 2024-06-04 11-47-11

FaLanguage from "react-icons/fa"

Screenshot from 2024-06-04 11-47-38

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will leave the title attribute in here, as it creates a nice pop-over

Screenshot from 2024-06-04 11-52-40

Copy link
Member

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 🤔

Copy link
Contributor

github-actions bot commented Jun 4, 2024

This pull request has conflicts ☹
Please resolve those so we can review the pull request.
Thanks.

Copy link
Contributor

github-actions bot commented Jun 4, 2024

This pull request is deployed at test.admin-interface.opencast.org/457/2024-06-04_09-14-33/ .
It might take a few minutes for it to become available.

Copy link
Contributor

github-actions bot commented Jun 4, 2024

This pull request is deployed at test.admin-interface.opencast.org/457/2024-06-04_09-56-02/ .
It might take a few minutes for it to become available.

@lkiesow
Copy link
Member

lkiesow commented Jun 4, 2024

The selector looks fine, except the icon which is different from all other tools we have (studio, editor, tobira) and three people told me (and I agree) that they didn't identify this as a language selector. It looks like something related to internet or network or something like that.

Screenshot from 2024-06-04 16-06-33

Can we just use what we use in the other tools?
Screenshot from 2024-06-04 16-05-12

Except for that, I'm fine with the new dialog.

@ziegenberg
Copy link
Member Author

The selector looks fine, except the icon which is different from all other tools we have (studio, editor, tobira) and three people told me (and I agree) that they didn't identify this as a language selector. It looks like something related to internet or network or something like that.

Can we just use what we use in the other tools?

@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.

Copy link
Contributor

github-actions bot commented Jun 7, 2024

This pull request has conflicts ☹
Please resolve those so we can review the pull request.
Thanks.

@lkiesow
Copy link
Member

lkiesow commented Jun 7, 2024

@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.

Sorry for the late reply. Lots of other patches drawing attention ;-)
That's definitely better. But judging by your poll in Matrix, you might have already decided to go with another icon.

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]>
Copy link
Contributor

github-actions bot commented Jun 11, 2024

This pull request is deployed at test.admin-interface.opencast.org/457/2024-06-11_15-53-53/ .
It might take a few minutes for it to become available.

@ziegenberg ziegenberg force-pushed the fix-i18n-languages branch from 4a66fe7 to 91e75d4 Compare June 11, 2024 15:53
@lkiesow lkiesow self-assigned this Jun 11, 2024
@lkiesow lkiesow merged commit 8812a3a into opencast:main Jun 11, 2024
5 checks passed
@ziegenberg ziegenberg deleted the fix-i18n-languages branch June 12, 2024 09:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants