Simplified Chinese Translation, working with TexLive.net

[libralibra]

1. Add Simplified Chinese Translation by following translation instructions
   2. Add a temporary patch to make all examples work with TexLive.net (click the TexLive.net button to get the examples that contains Chinese punctuations compiled successfully)

2. Rewrite language-01.md to reflect Chinese language-specific issues

3. Check all examples in the forked git-page site before bringing back CNAME.txt (https://libralibra.github.io/learnlatex.github.io/zh/)

UPDATE:
4. Update the default engine from xelatex to lualatex
5. Remove the unnecessary reference to xeCJK package

[davidcarlisle]

@libralibra

I'll close this PR and open a new one with these changes.

There is no need to open a new PR simply push to your fork and this PR will automatically update, then it is easier to see what changes have been made.

Also don't worry too much about the CNAME file, if you take learnlatex.org out of your copy so that you do not "steal" the DNS name, then it is true that directly merging your PR would change that here as well, but we know that happens and can fix it while merging the code so you do not have to keep changing CNAME depending on whether you are testing locally or making version for us to merge.

[libralibra]

@libralibra

I'll close this PR and open a new one with these changes.

There is no need to open a new PR simply push to your fork and this PR will automatically update, then it is easier to see what changes have been made.

Also don't worry too much about the CNAME file, if you take learnlatex.org out of your copy so that you do not "steal" the DNS name, then it is true that directly merging your PR would change that here as well, but we know that happens and can fix it while merging the code so you do not have to keep changing CNAME depending on whether you are testing locally or making version for us to merge.

Cheers! I've made the changes and accidentally found that the commit history after submitting this PR has been attached to this discussion. That's awesome!

Thanks for your suggestion, the DNS name has been deleted from my CNAME.txt now - I am not going to hijack it by any means :-)

[u-fischer]

Why do many of the examples use the UTF8 class option? It seems to compile fine without it.

[davidcarlisle]

Why do many of the examples use the UTF8 class option? It seems to compile fine without it.

I think UTF8 is the default now (and the only supported encoding for luatex or xetex), so this could be dropped, (via google translate) the ctex manual says:

4.2 Chinese encoding

GBK
indicates the encoding used when writing the document. The CTEX macro set cannot detect the actual encoding format of the document source file, so the user needs to declare it through the option

UTF8
If not explicitly specified, UTF-8 encoding is used by default.
Updated: 2019-11-10
When compiled with XƎLATEX, LuaLATEX or upLATEX, the CTEX macro set is forced to use UTF-8 encoding, and the GBK option
is invalid at this time; when compiled with (pdf)LATEX, the CTEX macro set uses UTF-8 encoding by default, but users can also explicitly declare the GBK
option to make the CTEX macro set process documents in GBK encoding.
Users need to ensure that the compilation method, source file encoding, and macro package encoding options are consistent.
We recommend that you always use UTF-8 encoding when writing new documents, and only leave GBK encoding for legacy documents.

[libralibra]

Why do many of the examples use the UTF8 class option? It seems to compile fine without it.

It's a personal practice of 'explicit is better than implicit' from the Zen of Python. But I am happy to remove it as the examples work fine without it as you suggested.

[libralibra]

Why do many of the examples use the UTF8 class option? It seems to compile fine without it.

I think UTF8 is the default now (and the only supported encoding for luatex or xetex), so this could be dropped, (via google translate) the ctex manual says:

4.2 Chinese encoding

GBK indicates the encoding used when writing the document. The CTEX macro set cannot detect the actual encoding format of the document source file, so the user needs to declare it through the option

UTF8 If not explicitly specified, UTF-8 encoding is used by default. Updated: 2019-11-10 When compiled with XƎLATEX, LuaLATEX or upLATEX, the CTEX macro set is forced to use UTF-8 encoding, and the GBK option is invalid at this time; when compiled with (pdf)LATEX, the CTEX macro set uses UTF-8 encoding by default, but users can also explicitly declare the GBK option to make the CTEX macro set process documents in GBK encoding. Users need to ensure that the compilation method, source file encoding, and macro package encoding options are consistent. We recommend that you always use UTF-8 encoding when writing new documents, and only leave GBK encoding for legacy documents.

Thank you for quoting the documents. All examples work fine without the explicit UTF8 definition indeed.

[muzimuzhi]

To better review translations, is it possible to first have a clean copy of English version under ./zh, which is (temporarily) hidden on learnlatex.github.io? That would be basically merging the first commit (affb6e8) in this PR first.

Reviewing selected commits does the trick, but the English version would still be missing in contexts of review comments.

Some general questions:

• To provide both Simplified and Traditional Chinese translations in the future, need the directory name for Simplified Chinese be more specific than ./zh, e.g., zh-Hans or even zh-Hans-CN?
• I recommend inserting explicit space characters between Chinese and non-Chinese characters in .md files. For example "在Overleaf中打开" (Open in Overleaf) -> "在 Overleaf 中打开". (I can add them when reviewing, just ask for agreement.)
• I don't think "您" (your honor) is commonly used in Simplified Chinese learning resources. Just use "你"?

[davidcarlisle]

@muzimuzhi I'm not sure I did quite what you intended

I locally cherry picked affb6e8 into main (which added the English text under zh as expected) then pushed here and that shows in the three dot diff as in

main...libralibra:learnlatex.github.io:mainch

But the PR still shows the difs against which it is forked

[muzimuzhi]

@davidcarlisle Thank you! According to how three-dot Git diff works unfortunately this is expected behavior.

The three-dot comparison shows the difference between the latest common commit of both branches (merge base) and the most recent version of the topic branch.
Three-dot Git diff comparison | GitHub Docs

Now it shows "This branch has conflicts that must be resolved". Not sure if it's easy to add a new commit which reverts affb6e8 to the head branch. I will try it locally.

[davidcarlisle]

@muzimuzhi @libralibra there is some discussion with @stone-zeng in #77 and I think the suggestion there was to use zh-hans (part of the discussion relates to earlier versions of the site when the language switching may not have been quite the same)

[davidcarlisle]

I have checked that the language switching does work using the longer codes such as zh-hans . There are some comments in the earlier issue implying 2-letter codes are assumed, but it looks like I fixed that at the time. As far as I can see, language selection works on my fork at

https://davidcarlisle.github.io/learnlatex.github.io/zh-hans/

so if you git rename the directory to zh and adjust the lang: and permalink entries to use that, it should all work.

[libralibra]

I have checked that the language switching does work using the longer codes such as zh-hans . There are some comments in the earlier issue implying 2-letter codes are assumed, but it looks like I fixed that at the time. As far as I can see, language selection works on my fork at

https://davidcarlisle.github.io/learnlatex.github.io/zh-hans/

so if you git rename the directory to zh and adjust the lang: and permalink entries to use that, it should all work.

Thanks for your reply. Yes, the longer language code did work.

I have made changes slowly to reflect what has been discussed above, as shown in the test site:

https://libralibra.github.io/learnlatex.github.io/zh-hans/

1. updated translation in Simplified Chinese (I may start working on the Traditional Chinese translation after this) using the longer language code zh-hans
2. add extra space before and after English words in the Chinese translation.
3. there's no need to keep a copy of the en folder in translated directory if I read the TRANSLATIONS.md correctly

[davidcarlisle]

@libralibra thanks for this

I have made changes slowly to reflect what has been discussed above, as shown in the test site:>

https://libralibra.github.io/learnlatex.github.io/zh-hans/

Thanks for this. If you let me know when you think it is done, I will merge.

If other changes come up after the merge you can always make a new PR to add corrections of course.

@muzimuzhi @stone-zeng similarly comments before or after the merge are always welcome.

1. updated translation in Simplified Chinese (I may start working on the Traditional Chinese translation after this) using the longer language code zh-hans

Thank you. It is simpler to limit a PR to one script, so if you could make a new PR for any zh-hant additions rather than adding both here that would be helpful . Thank you.

2. add extra space before and after English words in the Chinese translation.

thanks

3. there's no need to keep a copy of the en folder in translated directory if I read the TRANSLATIONS.md correctly

Yes there should be no english under the zh-hans directory. What @muzimuzhi meant by the above comment about having english (which you could do for any new zh-hant translation). Is to start by populating zh-hant from a copy of the en directory rather than empty stubs, and then the files changed diff view in any PR will show the English (as - removed) and Chinese as (+ added) on the same page, for easier proof reading.

[davidcarlisle]

@libralibra also don't worry too much about the conflict under zh we can fix that locally if not fixed at your side.

[libralibra]

@libralibra thanks for this

I have made changes slowly to reflect what has been discussed above, as shown in the test site:>
https://libralibra.github.io/learnlatex.github.io/zh-hans/

Thanks for this. If you let me know when you think it is done, I will merge.

If other changes come up after the merge you can always make a new PR to add corrections of course.

@muzimuzhi @stone-zeng similarly comments before or after the merge are always welcome.

1. updated translation in Simplified Chinese (I may start working on the Traditional Chinese translation after this) using the longer language code zh-hans

Thank you. It is simpler to limit a PR to one script, so if you could make a new PR for any zh-hant additions rather than adding both here that would be helpful . Thank you.

2. add extra space before and after English words in the Chinese translation.

thanks

3. there's no need to keep a copy of the en folder in translated directory if I read the TRANSLATIONS.md correctly

Yes there should be no english under the zh-hans directory. What @muzimuzhi meant by the above comment about having english (which you could do for any new zh-hant translation). Is to start by populating zh-hant from a copy of the en directory rather than empty stubs, and then the files changed diff view in any PR will show the English (as - removed) and Chinese as (+ added) on the same page, for easier proof reading.

Thank you for your reply. The current state of the Simplified translation can be considered as finished.
I've removed zh-hant from the yaml files as I felt the same about making a new PR for the Traditional translation would be more reasonable.

[libralibra]

@libralibra also don't worry too much about the conflict under zh we can fix that locally if not fixed at your side.

Yes, please merge after correcting the conflicts. Thank you!

[davidcarlisle]

@libralibra thanks a lot

https://www.learnlatex.org/zh-hans/

I hope you can read that better than I can:-)

[davidcarlisle]

@libralibra I added a {: .norun :} in the "template" example in section 5 to stop it adding the buttons to try running \documentclass{<meta-styntax-for-class-name>}

3ba303c

[davidcarlisle]

@libralibra should there be a translation for the "meta" heading in the page footer?

It seems most of the the languages failed to translate this (or translated it unchanged to Meta) but it looks a bit odd in latin script here (because I can read it:-) It would need to be in _data/translations.yaml but you could just supply a text here rather than make a new PR just for one word (or if you think it should stay as it is, that is OK too)

Also I notice that while generally we force Noto Sans Font, for Chinese it is falling through to whatever font is supplied on the local system (I get Microsoft YaHei) We could get Noto Sans SC as a web font eg from google fonts but that does force a fairly large font download on users who may? prefer to use their existing system Chinese font, especially on mobile.

[libralibra]

@libralibra should there be a translation for the "meta" heading in the page footer?

It seems most of the the languages failed to translate this (or translated it unchanged to Meta) but it looks a bit odd in latin script here (because I can read it:-) It would need to be in _data/translations.yaml but you could just supply a text here rather than make a new PR just for one word (or if you think it should stay as it is, that is OK too)

Also I notice that while generally we force Noto Sans Font, for Chinese it is falling through to whatever font is supplied on the local system (I get Microsoft YaHei) We could get Noto Sans SC as a web font eg from google fonts but that does force a fairly large font download on users who may? prefer to use their existing system Chinese font, especially on mobile.

@davidcarlisle
It may be translated to 元数据, but it might not be easy to find a proper word in Chinese to precisely act as Meta in English.

I struggled a little bit between using the translation and keeping the original word during the translation process. You could do either I think. For a person who would like to learn LaTeX, it shouldn't be a problem.

Regarding the font, it should be fine to let the local system selects whatever it likes as it won't affect the user experience too much.

[davidcarlisle]

@libralibra thanks I think I'll update the text, "Meta" is not really that good a heading in English (and is probably difficult to translate to many languages) I don't think we need to change the English but I don't think it's important to preserve the meaning and highlight that heading by being the only Latin script heading. pushed 3f12736

I'll leave the font as it is.