On Wed, Oct 18, 2023 at 10:47 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Jiang Xin <worldhello.net@xxxxxxxxx> 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.
