Tldr: Formatting quality of Chinese translation

[gyli]

This is an issue but also a reminder for Chinese translators, that many items come with low formatting quality. Note that this issue is not about the translation quality but only about the copywriting in Chinese.

For example:

1. Whether there should be a space between English words and Chinese characters. (Right answer: yes)

2. Which symbols should be used in a Chinese sentence, full-width or half-width. (Right answer: only use half-width in commands or full English sentences or terms, otherwise use full-width)

In current translations, it looks like there is no rule about copywriting at all and thus different symbols are used in one file mistakenly. Here are some examples:

1. 
   Wrong:
   Mas是一个简单的 Mac App Store 命令行界面.

Correct:
Mas 是一个简单的 Mac App Store 命令行界面。

Added the space between "Mas" and "是"; Changed "." to "。".

1. 
   Wrong:
   显示有关指定软件的信息（版本，安装路径，依赖关系等):

Correct:
显示有关指定软件的信息（版本，安装路径，依赖关系等）：

Changed the bracket and colon to full width.

I recommend you follow a copywriting standard, like this one https://github.com/sparanoid/chinese-copywriting-guidelines, to unify the format.

[gyli]

If you agree that we should follow such a guideline, I don't think posting a link in issue is useful. That's not an efficient way to ping translators/contributors about it.

So I propose the following actions:

1. Ask the main Chinese contributors to choose or decide a copywriting guideline we can follow for this repo.
   @wizarot @HugueLiu @KsRyY @starccy (any more?)

2. If @bestony's MiniProgram client for tldr is still a main source of Chinese contributors, maybe that's a good place to guide contributors before they start working on any record. Otherwise, we can have the guideline link on CONTRIBUTING page or dedicated TRANSLATION page, although I also feel like this issue only happens to translation into eastern languages.

[sbrl]

Hrm. Most of the current maintainers don't know Chinese, so we usually don't notice this kind of thing. You're welcome to leave reviews on Chinese PRs too help out, and submit PRs to fix errors. It governance file in the root of the repo also documents how you can gain additional reviewing privileges etc, should you want to do that.

[einverne]

If this guideline is acceptable, I'd like to help to format current Chinese translations.

[einverne]

There is a problem, when I format all Chinese translations, it change all period into Chinese 。, which can not pass the format lint. How I can adjust this?

[agnivade]

Sorry, I don't think you can do that. The period is compulsory.

[einverne]

OK, I get it.

[mebeim]

Hi @gyli, thank you for bringing this up. We had a PR in the past which was trying to (partially) address this issue (#2897).

As far as I'm concerned, what you are suggesting makes sense, but there are some critical parts of pages that we cannot change (at least as of now), since that would mean breaking the linter and a lot of clients.

What is ok to change:

• Spacing between English and Chinese words.
• Commas and other punctuation/tokens inside sentences (not at the end or beginning).
• Phrasing/wording, of course.

What is not ok to change:

• Critical characters, like the ending dot (.) for description lines, or the leading dash (-) and ending colon (:) for example descriptions, etc. Those are ASCII characters that need to be matched exactly, and cannot be replaced.
• Line spacing (empty lines between examples), trailing newline, etc.

I'm sorry that we cannot 100% adhere to the copywriting standard that you are citing (even though we know it would make a lot of sense to), but it currently is not possible.

With the above said, a PR fixing what can be fixed would be most welcome! I see @einverne already opened #3442 for this. That's almost perfect. I'll make a comment there.

[gyli]

@mebeim Thanks for listing these points. I'm not worried that we are unable to follow the copywriting rule above completely, as long as we do have a rule. It's OK to have exceptions for whatever we need.

This is also the main point of this issue, that we need to list those formatting rules alone with exceptions somewhere, so that contributors can follow before submitting.

[sbrl]

Note that on the wiki we've got a project outlined for rewriting the linter so make it more maintainable.

[einverne]

There is another problem I found when I tried to format existing translations. Should we put translations in the command line? It feels quite strange when Chinese mixed into the command line and such format can break the guideline mentioned above.

[gyli]

@einverne If you are talking about scenario like locate {{关键字}}, I would say yes, as it is descriptive placeholder and will be replaced by user input in whatever languages.

[sbrl]

Correct, @gyli. I believe for the command-lines themselves, I'd translate the bit inside the double curly braces {{translate_text_here}}. The braces themselves are part of the syntax, but the content within is fine to be translated.

/cc @waldyrious

[einverne]

@gyli @sbrl Thank you for your advice. I also agree the translation in descriptive placeholder. But if there are more words in double curly braces, for example, this translation tried to

osascript -l JavaScript {{路径/文件名.js}}

But if we follow the guideline, we will change it to

osascript -l JavaScript {{路径 / 文件名.js}}

and notice the space int the path. It will break the command's correctness. Under this situation, I simple think the path/to/filename.js is clear enough to show this command's usage.

[gyli]

@einverne I agree, this should be an exception since the former one is a valid path. Later one might have issue without quoting.

[sbrl]

Yeah, that's an awkward one. What about then wrapping the{{}} in double quotes ""? Then it's still syntactically correct.

[mebeim]

@einverne I think that can be a pretty valid exception to the rule. After all, 路径 / 文件名 and 路径/文件名 are two entirely different paths. It does not make sense to apply the rule here IMHO.

[einverne]

So, to conclude, I think most time we can follow the guidelines in the descriptions. And for command line, we should consider the correctness first.