[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <871rbbi7pn.fsf@meer.lwn.net>
Date: Thu, 15 Apr 2021 15:00:36 -0600
From: Jonathan Corbet <corbet@....net>
To: Wu XiangCheng <bobwxc@...il.cn>
Cc: Alex Shi <alexs@...nel.org>,
Federico Vaga <federico.vaga@...a.pv.it>,
Masahiro Yamada <masahiroy@...nel.org>,
Tsugikazu Shibata <tshibata@...jp.nec.com>,
SeongJae Park <sjpark@...zon.de>, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC 0/2] Add a new translation tool scripts/trslt.py
Wu XiangCheng <bobwxc@...il.cn> writes:
> Hi all,
>
> This set of patches aim to add a new translation tool - trslt.py, which
> can control the transltions version corresponding to source files.
>
> For a long time, kernel documentation translations lacks a way to control the
> version corresponding to the source files. If you translate a file and then
> someone updates the source file, there will be a problem. It's hard to know
> which version the existing translation corresponds to, and even harder to sync
> them.
>
> The common way now is to check the date, but this is not exactly accurate,
> especially for documents that are often updated. And some translators write
> corresponding commit ID in the commit log for reference, it is a good way,
> but still a little troublesome.
>
> Thus, the purpose of ``trslt.py`` is to add a new annotating tag to the file
> to indicate corresponding version of the source file::
>
> .. translation_origin_commit: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> The script will automatically copy file and generate tag when creating new
> translation, and give update suggestions based on those tags when updating
> translations.
>
> More details please read doc in [Patch 2/2].
So, like Federico, I'm unconvinced about putting this into the
translated text itself. This is metadata, and I'd put it with the rest
of the metadata. My own suggestion would be a tag like:
Translates: 6161a4b18a66 ("docs: reporting-issues: make people CC the regressions list")
It would be an analogue to the Fixes tag in this regard; you could have
more than one of them if need be.
I'm not sure we really need a script in the kernel tree for this; it
seems like what you really want is some sort of git commit hook. That
said, if you come up with something useful, we can certainly find a
place for it.
Thanks,
jon
Powered by blists - more mailing lists