Add(translation): Chinese

[HPDell]

Add Chinese translation for weekdays and months.

[Jeomhps]

Hi @HPDell,

Thank you for your translation and contribution! It looks great, but I do have one request, if I may. Could you create some tests and update the README file in the same way it was done in this PR? (#3)

Best regards,
Jeomhps

[HPDell]

Hi, thanks for your reply.

The tests have updated, but there are some other issues I was aware of when writing tests. I'm not sure whether you know a bit of Chinese. Usually, when writing dates, for example "1 May 2024", we usually use one of the following forms

二〇二四年五月一日
2024 年 5 月 1 日

And it would looks wired when someone write

2024 年五月 1 日

That means, "May" in English is the name of that month, but "五月" in Chinese is actually the rank number of that month "五" followed by a suffix "月" (meaning 'month'). So if we translate "五月" to English word by word, it would result in "The fifth month in a year".

Although I write translation for "May" as "五月" in the package, I'm afraid it is not best practice. Is there a way that we can ensure "1 May 2024" to be translate to either "二〇二四年五月一日" or "2024 年 5 月 1 日"?

[HPDell]

P.S., some example code and output

#let chinese_date = datetime(year: 2024, month: 5, day: 1)
#custom-date-format(chinese_date, "YYYY 年MMMM DD 日，day", "zh")
// 2024 年五月 1 日 which is wired

#custom-date-format(chinese_date, "YYYY 年 MM 月 DD 日，day", "zh")
// 2024 年 5 月 1 日 which is fine, but seems that there is no need to translate month names

[Jeomhps]

Thank you for your reply, I wasn’t aware of this detail about Chinese date formatting—thank you for pointing it out!

Regarding the code you provided:

#custom-date-format(chinese_date, "YYYY 年 MM 月 DD 日，day", "zh")

It would likely produce an output similar to this:

Here’s the code I used to generate this outputs (1st custom-date on the screen):

If your intention was to produce an output like 2024 年 5 月 1 日, you would need to omit the ,day portion like it is done in the 2nd custom-date. Or perhaps I misunderstood? For reference, here’s the output I got using the code above:

As far as I can tell, there’s no way to ensure that the month name isn’t translated except by using the MM argument. If this behavior needs to be explicitly disallowed, perhaps we could introduce a test for the zh language and have the compiler throw an error, along with a message to inform the user that this format is not supported.

One more question: In this commit (a48a9a9), you provided a date with day = 23, but the assert in the code uses 11. Was this a mistake, or is it intentional? Since I’m not familiar with Chinese date conventions, I wanted to confirm whether this was deliberate or an error. Here’s the code in question:

# let chinese_date = datetime(year: 2024, month: 5, day: 23)
# assert(custom-date-format(chinese_date, "YYYY 年MMMM DD 日，day", "zh") == "2024 年五月 11 日，星期四")

[HPDell]

Thanks for your reply. I'm sorry that I was distract by some other matters and left this package behind for so long time.

As for the problem in the following code

#custom-date-format(chinese_date, "YYYY年MM月DD日，day", "zh")

The problem is not related to the component day — actually this thing works fine. The real problem is related to how to deal with the necessary suffix 年 月 日, corresponding to year, month, and day, respectively. More specifically, shall I translate month numbers to its Chinese version with or without the suffix (translate 5 to 五 or 五月)?

I find it hard to make a decision because on one hand if I translate it to 五, users may have to write the suffix by themselves. In English (and some other languages used in European countries, perhaps), when writing dates, we don't need to write the suffix out, like 1 May 2024 (not 1 day May month 2024 year). So the format DD MMMM YYYY works fine. But in this case, the Chinese format YYYY MMMM DD would be rendered to 2024 五 1. This is not very usual in Chinese, so we need this format YYYY年MMMM月DD日.

On the other hand, if I translate it to 五月, the users do not need to write the suffix by themselves. And MMMM works fine for its whole name. But they still need to write the suffix 年 日.

Which way is preferred by you? Please tell me and I will revise the code further.

And there is another problem: how to show year numbers in Chinese number instead of Arabic number and automatically append a suffix 年 if format component YYYY is specified. And it is also necessary to do so on DD component. For example, to automatically render YYYY 2024 as 二〇二四年.

---

As for the problem you mentioned I "provided a date with day = 23, but the assert in the code uses 11". It was a mistake. I will correct in the future.

[Jeomhps]

Hi, no problem at all—I completely understand that you've been busy with other things. I’ve been pretty tied up as well, so no worries.

Regarding the suffix issue, I think it’s better to focus on translating the month and leave it to the end user to add the suffix. For example, consider the following English date: "August 04th, 2024." If you wanted to achieve this output with the package as it currently stands, you’d have to write:

# let my_date = datetime(year=2024, month=8, day=4)
# custom_date_format(my_date, "MMMM DDth, YYYY")

Even in English, you would manually append th. This was the approach I took when first designing the package, so to maintain consistency (at least for now), I’d prefer to let the end user handle the suffix themselves. This means the output would automatically translate the month, for example to 五, while the suffix would be added manually, like this:

# custom_date_format(my_date, "YYYY年MMMM月DD日")

As for using Chinese numerals for the year instead of Arabic numbers, I believe this could be implemented by adding a condition near the end of the formats.typ file, where the formatted output is assembled. Additionally, you’d need a method to convert the year into Chinese numerals. Let me know if this makes sense!

[HPDell]

Hi, thanks for your reply. It sounds very reasonable. Fortunately, there is a package called a2c-nums on Typst universe that can convert numbers to Chinese numerals. Even though, it still far more complicated that what I though in the beginning (just translate some names). I'm not sure I've got enough time to implement it in a short time.

In this case, I'd like to convert this PR to draft for a while until this is finished.

[Jeomhps]

Hello,

Sure, go ahead—no worries at all! Take your time and work on it whenever you have some spare moments. 👍