From: "Jean-Noël AVILA" <avila.jn@gmail.com>
To: Peter Krefting <peter@softwolves.pp.se>,
Junio C Hamano <gitster@pobox.com>
Cc: Helge Kreutzmann <debian@helgefjell.de>, git@vger.kernel.org
Subject: Re: i18n of git man pages
Date: Fri, 10 May 2024 09:39:02 +0200 [thread overview]
Message-ID: <3298196.44csPzL39Z@cayenne> (raw)
In-Reply-To: <xmqqr0ebuft5.fsf@gitster.g>
On Thursday, 9 May 2024 18:10:30 CEST Junio C Hamano wrote:
> Peter Krefting <peter@softwolves.pp.se> writes:
>
> > Should it also be merged into the git.git repository as well, so that
> > translation can be synced with the upstream version? The problem with
> > an external project is that it is easy to forget about.
>
> Carrying an extra tree that has been (and I suspect will continue to
> be) managed in a separate workflow and by a separate group does
> incur coordination cost.
I totally agree with Junio. The workflow is different and it is already quite
difficult to mix the long-running process of translation with the fast-paced
life of patches in the documentation. Moreover, the translation needs to be
opened to contributor who are not techno-friends and will not be able to
>
> > Looks like I had cloned the repo and intended to do a Swedish
> > translation back in 2019, but never got around to. I guess the lack of
> > visibility made me forget all about it.
>
> It is exactly why you are seeing a proposed solution to raise the
> visibility that is much lightweight and has less chance of doing
> unnecessary harm than merging of the project into ours. The help
> the would-be translators need will be there. To end-users, I do
> not think it matters in today's world where the manpages come from.
> The distro folks are there to absorb different ways translated
> manual pages are done by different projects, and I can hardly
> believe that our project is in any way unique.
It is not unique in using asciidoc as a single source for documentation. In
other projects that I know of, the documentation is a sister project in a
dedicated repository.
I try to present the translation of the man pages as coupled with the
translation of git itself, for consistency purpose. The translation of git is
already a large bite in itself (15481 segments at the moment), but the
translation of the documentation (which only concerns a subset of the whole
documentation) is really a beast: 73976 segment!
The absence of visibility is mainly an issue from my side, due to a lack of
communication. I could propose as a reminder to publish the translation stats
for each new Git release, if it helps remind developers of the presence of
this project. Honestly, this is not really the targeted audience for this kind
of work. Currently the main source of translators has been through the little
ad on https://git-scm.com, with most of the contributions coming from Weblate.
Giving more visibility to the presence of translated content and to the
project on git-scm.com or in the community of translators may have more impact
than on the git mailing list.
>
> I would like to hear from Jean-Noël how the manpage translation
> project wants to proceed. I do not fundamentally object to taking
> an approach similar to the one we use to manage the po/ part of our
> project, where I can normally be unaware of what happens in that
> directory and leave it to i18n coordinator, but I have a feeling
> that even such a light-weight integration might affect their
> workflows at the manpage translation project side, which may or may
> not be acceptable on their end. Also to go from the work product
> they have to what our "make -C Documentation all" produces, it may
> require more build dependencies (like a version of po4a with a patch
> or two that are yet to be accepted by the upstream), plus updates to
> Documentation/Makefile, on our side, which might turn out to be an
> overly high cost relative to the benefits both projects gain. These
> unknowns need to be resolved before we consider heavier proposals.
>
Normally, I would synchronize to the releases of git, by updating the po files
and opening an update window when a rc is tagged. At the end of the release
window, I would push a new version of translated asciidoc sources.
The translation process is not fully synchronous with the releases of Git. If
a large chunk of translation changes has been proposed on weblate, I can push
updated versions to the project and publish them on git-scm.com. Note that I'm
not polyglot enough to be able to review the submissions, so except for checks
on the asciidoc formatting itself (which is mostly scripted now), the
submissions are accepted as-is, like in most translation projects.
The size of the translation files already gives some weight to the project. The
current repo size is 50MB.
All this tells me that, except for the missing visibility, the current way of
working is good, and trying to merge the doc translation of Git into the main
repo would make more trouble than needed.
Regards,
JN
next prev parent reply other threads:[~2024-05-10 7:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-08 16:30 i18n of git man pages Helge Kreutzmann
2024-05-08 17:26 ` Junio C Hamano
2024-05-08 18:42 ` Helge Kreutzmann
2024-05-08 20:12 ` Junio C Hamano
2024-05-09 14:39 ` Peter Krefting
2024-05-09 16:10 ` Junio C Hamano
2024-05-10 7:39 ` Jean-Noël AVILA [this message]
2024-05-10 15:45 ` Junio C Hamano
2024-05-10 16:33 ` Jean-Noël AVILA
2024-05-09 14:56 ` Jean-Noël AVILA
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=3298196.44csPzL39Z@cayenne \
--to=avila.jn@gmail.com \
--cc=debian@helgefjell.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peter@softwolves.pp.se \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).