git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jean-Noel Avila <jn.avila@free.fr>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH] l10n: add framework for localizing the manpages
Date: Tue, 14 Mar 2017 22:00:21 +0100	[thread overview]
Message-ID: <CACBZZX4EGfBAu0M0y4xboVAtWf5N07XY8s40npQ1hN3rbgqmSw@mail.gmail.com> (raw)
In-Reply-To: <xmqq1su2ujsf.fsf@gitster.mtv.corp.google.com>

On Mon, Mar 13, 2017 at 1:01 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jean-Noel Avila <jn.avila@free.fr> writes:

Jean: Comments on the patch:

- Firstly thanks for working on this. When I hacked up the initial po
support in v1.7.8-rc2-1-g5e9637c629 I always meant to try out po4a,
but never got around to it. It's much easier than I thought.
- Consider submitting a more minimal patch that doesn't have the giant
fr.po (or just some minor cut version) as the tip of the series, to
make this easier to review
- The git-add.txt file is hardcoded in po4a.conf, won't this file need
to be generated in some final version of this series?

> This shows that even after adding just _one_ new option to the
> command, the whole thing need to be re-translated (the SYNOPSIS
> section may be a bad example, as not much is subject to i18n,
> though).  If each paragraph of the description section becomes a
> single string that need to be re-translated, as we can see below, I
> am not sure if it really helps the translators.  A mere single
> rephrasing of a word in a large paragraph would have to result in
> the entire paragraph to be translated again?
>
> [...]
>
> It almost makes me suggest that a totally different approach might
> be more manageable.  For example, we can pick one version of a
> source file (say, "v2.12.0:Documentation/git-add.txt"), have it
> fully translated to the target languages, _and_ make it a convention
> to record the original blob object name at the end of the translated
> file.  Perhaps "Documentation/l10n/fr/git-add.txt" may record the
> result of such translation effort.
>
> And then, when somebody wants to update the translation for v2.13.0,
> perhaps
>
>     git diff --color-words $old_blob v2.13.0:Documentation/git-add.txt
>
> (where $old_blob is taken from Documentation/l10n/fr/git-add.txt)
> can be examined and then Documentation/l10n/fr/git-add.txt can be
> adjusted to match the changes between the two versions.  After that,
> update the "source" blob object name in the translation.
>
> So, I dunno.  I like the goal and appreciate the effort to get to
> that goal.  I am not sure what the best approach would be and the
> sample translation mechanism I see in this patch makes me doubt that
> it is the best approach.

Junio: The concerns about long strings being altered & needing to be
translated is something already addressed by the gettext toolchain.
Your existing translations turn "fuzzy", and you can see a
before/after version of what changed in popular tools.

The proposal to do something like "git diff --words" is suboptimal
because it just gives you the same things these gettext tools give
you, but more importantly even though it's pretty feature similar in
theory you lose the advantage of plug-in integration with any
arbitrary gettext tool, e.g. the transifex or weblate tools Jean
mentioned.

Also, having done a lot of translations myself (although not for Git,
just the translation infra), it's a huge advantage to be able to
partially translate certain things out of order (e.g. parts of
git-add.txt), and even have different people do different parts. This
is trivial and you get out of the box support for it with the gettext
tooling, but not if we just have git-add.txt translated in its
entirety to e.g. French & record what the blob sha1 was.

I think this series is on the right track, and that po4a is the right
tool for the job.

  reply	other threads:[~2017-03-14 21:00 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-12 20:02 [PATCH] l10n: add framework for localizing the manpages Jean-Noel Avila
2017-03-12 20:02 ` Jean-Noel Avila
2017-03-12 20:36   ` Jean-Noël AVILA
2017-03-13  0:01   ` Junio C Hamano
2017-03-14 21:00     ` Ævar Arnfjörð Bjarmason [this message]
2017-03-14 21:13       ` Junio C Hamano
2017-03-15  8:11       ` Jean-Noël Avila
2017-03-15  9:01         ` Ævar Arnfjörð Bjarmason
2017-03-15  7:58     ` Jean-Noël Avila
2017-03-15 16:07       ` Junio C Hamano
2017-03-15 18:28       ` Stefan Beller
2017-03-18 17:53 ` [PATCH v2 1/2] l10n: Introduce framework for localizing man pages Jean-Noel Avila
2017-03-18 17:53   ` [PATCH v2 2/2] l10n: Add git-add.txt to localized " Jean-Noel Avila
2017-03-18 19:41   ` [PATCH v2 1/2] l10n: Introduce framework for localizing " Junio C Hamano
2017-03-18 22:17     ` Jean-Noël AVILA
2017-03-18 23:03     ` Junio C Hamano
2017-03-20  2:11       ` Junio C Hamano
2017-03-20  8:10         ` Jean-Noël Avila
2017-03-20  8:21           ` Jean-Noël AVILA
2017-03-20 16:50           ` Junio C Hamano
2017-03-20 21:02 ` Rework manpage localisation Jean-Noel Avila
2017-03-20 21:02   ` [PATCH v3 1/2] l10n: Introduce framework for localizing man pages Jean-Noel Avila
2017-03-21 18:09     ` Junio C Hamano
2017-03-20 21:02   ` [PATCH v3 2/2] l10n: Add git-add.txt to localized " Jean-Noel Avila
2017-03-20 22:05     ` Junio C Hamano
2017-03-22 12:01       ` Jean-Noël Avila
2017-03-22 18:02         ` Junio C Hamano
2017-03-22 18:41           ` Stefan Beller
2017-03-22 18:56             ` Junio C Hamano
2017-03-22 18:59               ` Stefan Beller
2017-03-24 14:21                 ` Michael J Gruber
2017-03-25 15:40           ` Jean-Noël AVILA
2017-03-26 22:56             ` Junio C Hamano
2017-03-27 20:12               ` Jean-Noël AVILA
2017-03-27 20:29                 ` Junio C Hamano
2017-03-24 15:58       ` Ævar Arnfjörð Bjarmason
2017-03-24 17:57         ` Junio C Hamano

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=CACBZZX4EGfBAu0M0y4xboVAtWf5N07XY8s40npQ1hN3rbgqmSw@mail.gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jn.avila@free.fr \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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).