All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Shi <seakeel@gmail.com>
To: yanteng si <siyanteng01@gmail.com>
Cc: Tang Yizhou <tangyizhou@huawei.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Yanteng Si <siyanteng@loongson.cn>, Alex Shi <alexs@kernel.org>,
	Linux Doc Mailing List <linux-doc@vger.kernel.org>,
	zhengbin13@huawei.com, Yeechou Tang <tangyeechou@gmail.com>,
	Feiyang Chen <chris.chenfeiyang@gmail.com>
Subject: Re: [PATCH 1/1] docs/zh_CN: Add sched-capacity translation
Date: Wed, 8 Dec 2021 14:15:42 +0800	[thread overview]
Message-ID: <CAJy-AmmfSX14XgXgb5edvL1A40KeaUZ1wWYsfz=N43zdQrKuJg@mail.gmail.com> (raw)
In-Reply-To: <CAEensMx2OwMNszCJpCCtahsC3CLdSP0KRq_jPDPeZAjKtmz6PQ@mail.gmail.com>

On Wed, Dec 8, 2021 at 12:55 PM yanteng si <siyanteng01@gmail.com> wrote:
>
> Tang Yizhou <tangyizhou@huawei.com> 于2021年12月8日周三 12:35写道:
> >
> > On 2021/12/8 11:16, Alex Shi wrote:
> > > On Tue, Dec 7, 2021 at 10:57 PM Jonathan Corbet <corbet@lwn.net> wrote:
> > >>
> > >> Alex Shi <seakeel@gmail.com> writes:
> > >>
> > >>> What the result of scripts/checkpatch.pl or make htmldocs say?
> > >>> Let's tame these tools and follow the regluar styles of kernel.
> > >>
> > >> checkpatch knows nothing about different languages, and "make htmldocs"
> > >> doesn't do that sort of stylistic checking.
> > >
> > > Thanks for the info!
> > >
> > >>
> > >> I don't know enough (i.e. anything :) to have an opinion on the best
> > >> length for lines of Chinese text.  Surely there must be some conventions
> > >> out there?
> > >
> > > The only reason I know is to remove extra spaces char in 'rendered
> > > documentation'
> > > which is generated by line break. For this purpose, 40 or 60 line chars limit
> > > can't fulfill it obviously.
> > >
> > > Yizhou's suggestion has no line break unless a punctuation hitted, so the
> > > space will happen with the punctuation.   This makes the rendered document look
> > > good, but will lead to toooo long and never alignment lines in the
> > > source document.
> > > It looks like we have no good way to resolve this issue by style
> > > change. Also the '60'
> > > number seems an arbitrary number? If we have to relief this problem from coding
> > > style change, why not follow the new rule after checkpatch's change:
> > > from 80 to 100,
> > > let's say about 50 Chinese chars plus breaking after a meaningful Chinese word?
> >
> > Agreed.
> >
> > Now I prefer 50 Chinese chars plus breaking after a meaningful Chinese word.
> All guys:
>
> ref <https://stackoverflow.com/questions/8550112/prevent-browser-converting-n-between-lines-into-space-for-chinese-characters>

Nice finding!

>
> I have tested that firefox has no space problem. Looks like some
> browser issues, But I still think it's because rst didn't consider
> Chinese support when it was originally designed.
>
> I'm sure there are many ways to solve the space problem elegantly, but
> changing the document source code is definitely not one of them.

Right.

Just since checkpatch has changed, so let's move on...
And of cause, 40 chars width is also acceptable if someone like it.

Thanks
Alex

  reply	other threads:[~2021-12-08  6:16 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-06  9:09 [RFC PATCH 0/1] Add sched-capacity Chinese translation Tang Yizhou
2021-12-06  9:09 ` [PATCH 1/1] docs/zh_CN: Add sched-capacity translation Tang Yizhou
2021-12-07  5:37   ` Alex Shi
2021-12-07  7:46     ` Tang Yizhou
2021-12-07  8:34       ` yanteng si
2021-12-07  9:33         ` Feiyang Chen
2021-12-07  9:57           ` yanteng si
2021-12-07  9:59           ` Alex Shi
2021-12-07 13:30             ` Tang Yizhou
2021-12-07  9:41       ` Alex Shi
2021-12-07 13:18         ` Tang Yizhou
2021-12-07 14:57         ` Jonathan Corbet
2021-12-08  3:16           ` Alex Shi
2021-12-08  4:35             ` Tang Yizhou
2021-12-08  4:54               ` yanteng si
2021-12-08  6:15                 ` Alex Shi [this message]
2021-12-08  7:11                   ` yanteng si
2021-12-08  6:37                 ` Feiyang Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJy-AmmfSX14XgXgb5edvL1A40KeaUZ1wWYsfz=N43zdQrKuJg@mail.gmail.com' \
    --to=seakeel@gmail.com \
    --cc=alexs@kernel.org \
    --cc=chris.chenfeiyang@gmail.com \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=siyanteng01@gmail.com \
    --cc=siyanteng@loongson.cn \
    --cc=tangyeechou@gmail.com \
    --cc=tangyizhou@huawei.com \
    --cc=zhengbin13@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.