ja/i18n-common-messages (was: What's cooking in git.git (Feb 2022, #04; Tue, 15))

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Feb 15, 2022, 22:17 UTC
Message-ID: <220215.865ypfwz2q.gmgdl@evledraar.gmail.com>
In-Reply-To: <xmqqk0dwyrcv.fsf@gitster.g>

On Tue, Feb 15 2022, Junio C Hamano wrote:

Show 10 quoted lines

> * ja/i18n-common-messages (2022-02-04) 4 commits
>  - i18n: fix some misformated placeholders in command synopsis
>  - i18n: remove from i18n strings that do not hold translatable parts
>  - i18n: factorize "invalid value" messages
>  - i18n: factorize more 'incompatible options' messages
>
>  Unify more messages to help l10n.
>
>  Will merge to 'next'?
>  source: <pull.1123.v4.git.1643666870.gitgitgadget@gmail.com>

The changes to messages etc. in this series and the previous ones all look good.

The one reservation I had about it was the addition to the parse-options.c API: https://lore.kernel.org/git/220201.86a6fa9tmr.gmgdl@evledraar.gmail.com/

I don't mind if this goes in as-is, but would really like us to give ourselves license to make some generalized parse-options.c feature (like the OPT_INCOMPATIBLE() I proposed in the linked thread) not need to have the semantics introduced in die_for_incompatible_opt3() and die_for_incompatible_opt4() in this series.

I.e. it's a lot simpler to just die with a message the first time we see that --opt-b doesn't go with --opt-a, instead of needing to continue parsing and finding that --opt-c is also incompatible with the two, etc.