Linux Documentation
 help / color / mirror / Atom feed
From: Weijie Yuan <wy@wyuan.org>
To: Jiandong Qiu <qiujiandong1998@gmail.com>
Cc: Alexs Shi <alexs@kernel.org>, Yanteng Si <si.yanteng@linux.dev>,
	Dongliang Mu <dzm91@hust.edu.cn>,
	Jonathan Corbet <corbet@lwn.net>,
	Shuah Khan <skhan@linuxfoundation.org>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/2] docs/zh_CN: update translations for process/changes.rst and sphinx.rst
Date: Wed, 8 Jul 2026 03:23:07 +0800	[thread overview]
Message-ID: <ak1SG5mw7y2UZrvR@wyuan.org> (raw)
In-Reply-To: <akuoP6z-GMfbKucI@archlinux>

Hi Jiandong,

Sorry for the late reply.

Thank you for delving deeply into this issue! Appreciate it! And I agree
with your analysis on this. So I would like to adjust my font setup
later to give it a try.

Your fontconfig setup is useful for an individual reader, and it is a
good workaround for someone who wants lore or a local editor to display
such tables nicely. However, I don't think the document source should
depend too much on each reader having such a setup, and that's what I
might not express myself clearly about in my previous mail.

My concern is mainly about the readability of the plain .rst source in
common environments, such as lore (as well as git.kernel.org web
interface), email clients, and text editors. In those places, many
readers may not have a carefully configured 2:1 CJK/ASCII monospace
font. So, as far as reasonable, I think it is better for the table
boundaries to remain readable in common cases, instead of asking every
individual reader to tune their local font configuration.

I suggest:

 * For the first table, keeping "optional" in English seems like a
   simple solution. That row appears to be the only place where the CJK
   text causes visible misalignment, and "optional" is not a difficult
   word for kernel developers.

 * For the other two tables, I agree that there may not be a perfect
   solution that satisfies every environment. I mainly wanted to raise
   the plain-source readability concern and ask what maintainers prefer.

Overall, I think we should try to keep table boundaries readable in
common plain-text environments (i.e. without additional settings) where
reasonably possible, but I do not think this issue should block the
patch. (Ah, sorry, till now I do not even read the patches themselves
yet ;-0

Best regards,
Weijie

      reply	other threads:[~2026-07-07 19:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-21 13:12 [PATCH v2 0/2] docs/zh_CN: update translations for process/changes.rst and sphinx.rst Jiandong Qiu
2026-06-21 13:12 ` [PATCH v2 1/2] docs/zh_CN: add process/changes.rst translation Jiandong Qiu
2026-07-05  8:23   ` Dongliang Mu
2026-07-05 15:48     ` Jiandong Qiu
2026-06-21 13:12 ` [PATCH v2 2/2] docs/zh_CN: update sphinx.rst translation Jiandong Qiu
2026-07-05  6:24 ` [PATCH v2 0/2] docs/zh_CN: update translations for process/changes.rst and sphinx.rst Weijie Yuan
2026-07-05 15:20   ` Jiandong Qiu
2026-07-05 15:51     ` Weijie Yuan
2026-07-06 13:21       ` Jiandong Qiu
2026-07-07 19:23         ` Weijie Yuan [this message]

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=ak1SG5mw7y2UZrvR@wyuan.org \
    --to=wy@wyuan.org \
    --cc=alexs@kernel.org \
    --cc=corbet@lwn.net \
    --cc=dzm91@hust.edu.cn \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=qiujiandong1998@gmail.com \
    --cc=si.yanteng@linux.dev \
    --cc=skhan@linuxfoundation.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox