Re: Is there any interest in localizing term delimiters in git messages?

From: Jiang Xin <worldhello.net@gmail.com>
Date: Oct 19, 2023, 05:08 UTC
Message-ID: <CANYiYbEqTH975j9E0GTbSbexrw3MLhKwBCw7mibfnWbxZ+-_yw@mail.gmail.com>
In-Reply-To: <xmqqwmvkve83.fsf@gitster.g>

On Wed, Oct 18, 2023 at 10:47 AM Junio C Hamano <gitster@pobox.com> wrote:

Show 43 quoted lines

>
> Jiang Xin <worldhello.net@gmail.com> writes:
>
> > Starting with the release of git 2.34.0 two years ago, we had a new
> > l10n pipeline and the git-po-helper tool as part of our l10n workflow.
> > The first version of git-po-helper introduced a validator to protect
> > git command parameters and variable names in megid.
>
> Ahh, that is the piece I was missing.  I didn't know you guys are
> doing extra checks that could trigger false positives.
>
> > E.g. In pull
> > request 541 (https://github.com/git-l10n/git-po/pull/541), a
> > mismatched variable name "new_index" was reported in bg.po as below:
> >
> >     level=warning msg="mismatch variable names in msgstr: new_index"
> >     level=warning msg=">> msgid: unable to write new_index file"
> >     level=warning msg=">> msgstr: новият индекс не може да бъде записан"
> >
> > And po/bg.po changed as below:
> >
> >     msgid "unable to write new_index file"
> >     msgstr "новият индекс (new_index) не може да бъде записан"
>
> Wait.  Is this supposed to be a good example of validator working
> well?  We use this exact message three times in builtin/commit.c; is
> the validator insisting on the translated message to have verbatim
> string "new_index" in it so that the end-users will see it?
>
> I may still be confused, but if that is what is going on, I think it
> is a wrong validation in this particular case.  I can understand if
> we were creating say .git/new_index file and it helps the end users
> to diagnose a troubled repository by running "ls .git" to see if a
> file called "new_index" exists and getting in the way, but I do not
> think it is the case.  A new file ".git/index.lock" is created via
> repo_hold_locked_index() and I do not think it helps the end-user to
> know that we may be calling it "new_index" internally among the
> developers' circle.  If the message were about "index.lock", it
> might be a different story, but such an error would probably have
> been issued long before write_locked_index() gets called.
>
> I'd suggest doing s/new_index/new index/ to msgid string for these
> anyway.

I tried to find similar patterns in `po/bg.po` using:

    $ git  grep -h -B5 '([a-zA-Z_\.]*_[a-zA-Z_\.]\+)' po/bg.po

And find other translated variable names in Bulgarian as follows:

 * cookie_result in builtin/fsmonitor--daemon.c:

   error(_("fsmonitor: cookie_result '%d' != SEEN"),

 * run_command in builtin/submodule--helper.c:

    die(_("run_command returned non-zero status for %s\n."),
    die(_("run_command returned non-zero status while "

 * crlf_action in convert.c:

    warning(_("illegal crlf_action %d"), (int)crlf_action);

 * lazy_dir in name-hash.c:

    die(_("unable to create lazy_dir thread: %s"),

 * lazy_name in name-hash.c:

    die(_("unable to create lazy_name thread: %s"),
    die(_("unable to join lazy_name thread: %s"),

 * load_cache_entries in read-cache.c:

    die(_("unable to create load_cache_entries thread: %s"),
    die(_("unable to join load_cache_entries thread: %s"),

 * load_index_extensions in read-cache.c:

    die(_("unable to create load_index_extensions thread: %s"),
    die(_("unable to join load_index_extensions thread: %s"),

Apart from "new_index", it seems that none of the above sentences can be rewritten simply by removing the underscores in variable names without breaking the grammar, and I suppose it would be better to keep those variable names unchanged.