On Wed, Oct 18, 2023 at 5:50 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Alexander Shopov <ash@xxxxxxxxxxxxxx> writes: > > > Typical example: > > ORIGINAL > > msgid " (use \"git rm --cached <file>...\" to unstage)" > > > > TRANSLATION > > msgstr "" > > " (използвайте „git rm --cached %s ФАЙЛ…“, за да извадите ФАЙЛа от индекса)" > > > > The important part are the `<' and `>' delimiters of the term "file" > > > > Instead of using them - I omit them and capitalize the term. As if `<' > > and `>' are declared as localizable and then I translate them as `', > > `' > > Is it because it is more common in your target language to omit <> > around the placeholder word, or is it just your personal preference? > > Whichever is the case, I am not sure how it affects ... > > > So I am asking - is there any interest from other localizers to have > > such a feature? Would the additional maintenance be OK for the > > developers? > > ... the maintenance burden for developers. Perhaps I am not getting > what you are proposing, but we are not going to change the message > in "C" locale (the original you see in msgid). In untranslated Git, > we will keep the convention to highlight the placeholder word by > having <> around it, so the "(use \"git rm --cached <file>...\" to > unstage)" message will be spelled with "<file>". You can translate > that to a msgstr without <> markings without asking anybody's > permission, and I do not think of a reason why it would burden > developers to do so. 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. 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) не може да бъде записан" Later, more validators were introduced into git-po-helper for checking git config name, place holders, etc. "git-po-helper" used a list of regular expressions to find git config names, placeholders, and there are some false positive cases need to be ignored. So I added tweaks in smarge tables in "dict/*.go" of git-po-helper. E.g. For German translation, there are two exceptions that need to be ignored: "e.g." was translated to "z.B.", "you@xxxxxxxxxxx" was translated to "ihre@xxxxxxxxxxxxxxx" In pull request 593 (https://github.com/git-l10n/git-po/pull/593), it was the first time I know that in Bulgarian translations, markers around <placeholder> were not suitable for Bulgarian. So I decided to add more tweaks for Bulgarian by adding more exception rules in "dict/smudge-bg.go". I wonder if Bulgarian can use some unique characters to wrap the placeholders (e.g. Chinese can use wrappers around placeholders like「placeholder」，【placeholder】，etc). It will be much simpler to define exception rules for Bulgarian. Otherwize, maybe I can add filters for validators in "po-helper", and Bulgarian can bypass some validators to suppress warnings in pull requests. -- Jiang Xin
