{"thread":{"id":"60385","subject":"Is there any interest in localizing term delimiters in git messages?","startedAt":"2023-10-17T21:10:05Z","lastAt":"2023-10-21T09:37:20Z","messageCount":12,"participants":["Alexander Shopov","Junio C Hamano","Jiang Xin","Jeff Hostetler","Torsten Bögershausen","Peter Krefting"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"483368","messageId":"CAP6f5Mmi=f4DPcFwfvEiJMdKMa0BUyZ019mc8uFXyOufgD4NjA@mail.gmail.com","threadId":"60385","inReplyTo":null,"subject":"Is there any interest in localizing term delimiters in git messages?","fromName":"Alexander Shopov","fromEmail":"ash@kambanaria.org","sentAt":"2023-10-17T21:09:50Z","receivedAt":"2023-10-17T21:10:05Z","isPatch":false,"sender":{"key":"ash@kambanaria.org","avatar":"https://avatars.githubusercontent.com/u/449359?v=4"},"body":"Hello all,\n\nIs there any interest in being able to change the delimiters of the\nchangeable terms in git messages?\n\nTypical example:\nORIGINAL\nmsgid \" (use \\\"git rm --cached ...\\\" to unstage)\"\n\nTRANSLATION\nmsgstr \"\"\n\" (използвайте „git rm --cached %s ФАЙЛ…“, за да извадите ФАЙЛа от индекса)\"\n\nThe important part are the `<' and `>' delimiters of the term \"file\"\n\nInstead of using them - I omit them and capitalize the term. As if `<'\nand `>' are declared as localizable and then I translate them as `',\n`'\n\nThis has the following benefits:\n1. The translation gets shorter\n2. We skip potentially dangerous shell characters (<> redirect IN/OUT)\n3. Readability improves for some strings, ex:\n- git pack-objects [] [< | < ]\n- git mailinfo [] < mail >info\n\nOn the other hand - this can increase the maintenance burden of\nmessages and tests and the shortening benefit is applicable to\nlanguages using capitalization or some other form of letter changing\nthat preserves readability (I understand there are many languages with\nlots of speakers that are not like that). They might decide to convey\n`<' and `>' as `«', `»' to get benefits 2 and 3.\n\nSo I am asking - is there any interest from other localizers to have\nsuch a feature? Would the additional maintenance be OK for the\ndevelopers?\n\nIt is possible that no one besides me is interested in this - in which\ncase I will rework the Bulgarian translation as:\n- More and more messages containing only the term automatically add\nthe `<' and `>'\n- I need to keep adding smudge rules to the git-po-helper tool\n(https://github.com/git-l10n/git-po-helper).\n\nKind regards:\nal_shopov\n"},{"id":"483371","messageId":"xmqqzg0gx6k9.fsf@gitster.g","threadId":"60385","inReplyTo":"CAP6f5Mmi=f4DPcFwfvEiJMdKMa0BUyZ019mc8uFXyOufgD4NjA@mail.gmail.com","subject":"Re: Is there any interest in localizing term delimiters in git messages?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-10-17T21:49:58Z","receivedAt":"2023-10-17T21:50:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alexander Shopov writes:\n\n> Typical example:\n> ORIGINAL\n> msgid \" (use \\\"git rm --cached ...\\\" to unstage)\"\n>\n> TRANSLATION\n> msgstr \"\"\n> \" (използвайте „git rm --cached %s ФАЙЛ…“, за да извадите ФАЙЛа от индекса)\"\n>\n> The important part are the `<' and `>' delimiters of the term \"file\"\n>\n> Instead of using them - I omit them and capitalize the term. As if `<'\n> and `>' are declared as localizable and then I translate them as `',\n> `'\n\nIs it because it is more common in your target language to omit <>\naround the placeholder word, or is it just your personal preference?\n\nWhichever is the case, I am not sure how it affects ...\n\n> So I am asking - is there any interest from other localizers to have\n> such a feature? Would the additional maintenance be OK for the\n> developers?\n\n... the maintenance burden for developers. Perhaps I am not getting\nwhat you are proposing, but we are not going to change the message\nin \"C\" locale (the original you see in msgid). In untranslated Git,\nwe will keep the convention to highlight the placeholder word by\nhaving <> around it, so the \"(use \\\"git rm --cached ...\\\" to\nunstage)\" message will be spelled with \"\". You can translate\nthat to a msgstr without <> markings without asking anybody's\npermission, and I do not think of a reason why it would burden\ndevelopers to do so.\n\nAs long as the target audience of your translation wants to see\n to be translated to ФАЙЛ without <> around the word, I do\nnot think there is any problem doing so. I of course am assuming\nthat using capitalized placeholder is the norm for all users who use\nBulgarian translated Git---if it is not some users want to see <>\naround the placeholder word just like \"C\" locale, then you'd need to\nanswer your users wish first, or course, but that would not need to\nconcern the developers who write the \"C\" locale messages.\n\nThanks for helping Git easier to use for users with your language.\n"},{"id":"483378","messageId":"CANYiYbHK90Ptq5v4EbquyRA7N9jo=xwkg=WuM=r60Wh9HMxdyA@mail.gmail.com","threadId":"60385","inReplyTo":"xmqqzg0gx6k9.fsf@gitster.g","subject":"Re: Is there any interest in localizing term delimiters in git messages?","fromName":"Jiang Xin","fromEmail":"worldhello.net@gmail.com","sentAt":"2023-10-18T02:01:52Z","receivedAt":"2023-10-18T02:02:06Z","isPatch":false,"sender":{"key":"worldhello.net@gmail.com","avatar":"https://avatars.githubusercontent.com/u/183860?v=4"},"body":"On Wed, Oct 18, 2023 at 5:50 AM Junio C Hamano wrote:\n>\n> Alexander Shopov writes:\n>\n> > Typical example:\n> > ORIGINAL\n> > msgid \" (use \\\"git rm --cached ...\\\" to unstage)\"\n> >\n> > TRANSLATION\n> > msgstr \"\"\n> > \" (използвайте „git rm --cached %s ФАЙЛ…“, за да извадите ФАЙЛа от индекса)\"\n> >\n> > The important part are the `<' and `>' delimiters of the term \"file\"\n> >\n> > Instead of using them - I omit them and capitalize the term. As if `<'\n> > and `>' are declared as localizable and then I translate them as `',\n> > `'\n>\n> Is it because it is more common in your target language to omit <>\n> around the placeholder word, or is it just your personal preference?\n>\n> Whichever is the case, I am not sure how it affects ...\n>\n> > So I am asking - is there any interest from other localizers to have\n> > such a feature? Would the additional maintenance be OK for the\n> > developers?\n>\n> ... the maintenance burden for developers. Perhaps I am not getting\n> what you are proposing, but we are not going to change the message\n> in \"C\" locale (the original you see in msgid). In untranslated Git,\n> we will keep the convention to highlight the placeholder word by\n> having <> around it, so the \"(use \\\"git rm --cached ...\\\" to\n> unstage)\" message will be spelled with \"\". You can translate\n> that to a msgstr without <> markings without asking anybody's\n> permission, and I do not think of a reason why it would burden\n> developers to do so.\n\nStarting with the release of git 2.34.0 two years ago, we had a new\nl10n pipeline and the git-po-helper tool as part of our l10n workflow.\nThe first version of git-po-helper introduced a validator to protect\ngit command parameters and variable names in megid. E.g. In pull\nrequest 541 (https://github.com/git-l10n/git-po/pull/541), a\nmismatched variable name \"new_index\" was reported in bg.po as below:\n\n level=warning msg=\"mismatch variable names in msgstr: new_index\"\n level=warning msg=\">> msgid: unable to write new_index file\"\n level=warning msg=\">> msgstr: новият индекс не може да бъде записан\"\n\nAnd po/bg.po changed as below:\n\n msgid \"unable to write new_index file\"\n msgstr \"новият индекс (new_index) не може да бъде записан\"\n\nLater, more validators were introduced into git-po-helper for checking\ngit config name, place holders, etc. \"git-po-helper\" used a list of\nregular expressions to find git config names, placeholders, and there\nare some false positive cases need to be ignored. So I added tweaks in\nsmarge tables in \"dict/*.go\" of git-po-helper. E.g. For German\ntranslation, there are two exceptions that need to be ignored:\n\n \"e.g.\" was translated to \"z.B.\",\n \"you@example.com\" was translated to \"ihre@emailadresse.de\"\n\nIn pull request 593 (https://github.com/git-l10n/git-po/pull/593), it\nwas the first time I know that in Bulgarian translations, markers\naround were not suitable for Bulgarian. So I decided to\nadd more tweaks for Bulgarian by adding more exception rules in\n\"dict/smudge-bg.go\".\n\nI wonder if Bulgarian can use some unique characters to wrap the\nplaceholders (e.g. Chinese can use wrappers around placeholders\nlike「placeholder」，【placeholder】，etc). It will be much simpler to\ndefine exception rules for Bulgarian. Otherwize, maybe I can add\nfilters for validators in \"po-helper\", and Bulgarian can bypass some\nvalidators to suppress warnings in pull requests.\n\n--\nJiang Xin\n"},{"id":"483380","messageId":"xmqqwmvkve83.fsf@gitster.g","threadId":"60385","inReplyTo":"CANYiYbHK90Ptq5v4EbquyRA7N9jo=xwkg=WuM=r60Wh9HMxdyA@mail.gmail.com","subject":"Re: Is there any interest in localizing term delimiters in git messages?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-10-18T02:47:24Z","receivedAt":"2023-10-18T02:47:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jiang Xin writes:\n\n> Starting with the release of git 2.34.0 two years ago, we had a new\n> l10n pipeline and the git-po-helper tool as part of our l10n workflow.\n> The first version of git-po-helper introduced a validator to protect\n> git command parameters and variable names in megid.\n\nAhh, that is the piece I was missing. I didn't know you guys are\ndoing extra checks that could trigger false positives.\n\n> E.g. In pull\n> request 541 (https://github.com/git-l10n/git-po/pull/541), a\n> mismatched variable name \"new_index\" was reported in bg.po as below:\n>\n> level=warning msg=\"mismatch variable names in msgstr: new_index\"\n> level=warning msg=\">> msgid: unable to write new_index file\"\n> level=warning msg=\">> msgstr: новият индекс не може да бъде записан\"\n>\n> And po/bg.po changed as below:\n>\n> msgid \"unable to write new_index file\"\n> msgstr \"новият индекс (new_index) не може да бъде записан\"\n\nWait. Is this supposed to be a good example of validator working\nwell? We use this exact message three times in builtin/commit.c; is\nthe validator insisting on the translated message to have verbatim\nstring \"new_index\" in it so that the end-users will see it?\n\nI may still be confused, but if that is what is going on, I think it\nis a wrong validation in this particular case. I can understand if\nwe were creating say .git/new_index file and it helps the end users\nto diagnose a troubled repository by running \"ls .git\" to see if a\nfile called \"new_index\" exists and getting in the way, but I do not\nthink it is the case. A new file \".git/index.lock\" is created via\nrepo_hold_locked_index() and I do not think it helps the end-user to\nknow that we may be calling it \"new_index\" internally among the\ndevelopers' circle. If the message were about \"index.lock\", it\nmight be a different story, but such an error would probably have\nbeen issued long before write_locked_index() gets called.\n\nI'd suggest doing s/new_index/new index/ to msgid string for these\nanyway.\n\n> Later, more validators were introduced into git-po-helper for checking\n> git config name, place holders, etc. \"git-po-helper\" used a list of\n> regular expressions to find git config names, placeholders, and there\n> are some false positive cases need to be ignored.\n\nOK, and \"\" in msgid string, for example, will automatically\ninsist on the translated msgstr string to have a string that is\nenclosed by a pair of such angle brackets, regardless of the target\nlanguage convention? If so, I can now understand where Alexander\ncomes from (assuming that the common convention in Bulgarian language\nis not to use a pair of angle brackets to highlight such a placeholder\nword).\n\nI can see that you have a lot better handle on the matter than I do,\nso I trust you and Alexander can resolve what the best \"validation\"\n(and possibly override per language) should be in the git-po-helper\ntool.\n\nThanks for explaining.\n"},{"id":"483381","messageId":"xmqqo7gwvd8c.fsf_-_@gitster.g","threadId":"60385","inReplyTo":"xmqqwmvkve83.fsf@gitster.g","subject":"[PATCH] commit: do not use cryptic \"new_index\" in end-user facing messages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-10-18T03:08:51Z","receivedAt":"2023-10-18T03:08:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"These error messages say \"new_index\" as if that spelling has some\nsignificance to the end users (e.g. the file \"$GIT_DIR/new_index\"\nhas some issues), but that is not the case at all. The i18n folks\nwere made to include the word literally in the translated messages,\nwhich was not a good idea at all. Spell it \"new index\", as we are\njust telling the users that we failed to create a new index file.\nThe term is expected to be translated to the end-users' languages,\nnot left as if it were a literal file name.\n\nThis dates all the way back to the first re-implemenation of \"git\ncommit\" command in C (the scripted version did not have such wording\nin its error messages), in f5bbc322 (Port git commit to C.,\n2007-11-08).\n\nSigned-off-by: Junio C Hamano \n---\n\n Junio C Hamano writes:\n\n > Jiang Xin writes:\n > ...\n > Wait. Is this supposed to be a good example of validator working\n > well? We use this exact message three times in builtin/commit.c; is\n > the validator insisting on the translated message to have verbatim\n > string \"new_index\" in it so that the end-users will see it?\n > ...\n > I'd suggest doing s/new_index/new index/ to msgid string for these\n > anyway.\n\n Just so that we do not forget, in case my \"using new_index in\n the message is wrong\" is not my misunderstanding, here is such a\n patch. Note that \"checkout\", \"clone\", \"read-tree\", and \"stash\"\n all use the \"new index\" spelling so this is not introducing any\n new message. \"git merge\" and \"git pull\" that fast-forward also\n use this same message when they cannot write a new index file.\n\n builtin/commit.c | 8 ++++----\n 1 file changed, 4 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin/commit.c b/builtin/commit.c\nindex 985a0445b7..7abd566bc7 100644\n--- a/builtin/commit.c\n+++ b/builtin/commit.c\n@@ -446,7 +446,7 @@ static const char *prepare_index(const char **argv, const char *prefix,\n \t\trefresh_cache_or_die(refresh_flags);\n \t\tcache_tree_update(&the_index, WRITE_TREE_SILENT);\n \t\tif (write_locked_index(&the_index, &index_lock, 0))\n-\t\t\tdie(_(\"unable to write new_index file\"));\n+\t\t\tdie(_(\"unable to write new index file\"));\n \t\tcommit_style = COMMIT_NORMAL;\n \t\tret = get_lock_file_path(&index_lock);\n \t\tgoto out;\n@@ -470,7 +470,7 @@ static const char *prepare_index(const char **argv, const char *prefix,\n \t\t\tcache_tree_update(&the_index, WRITE_TREE_SILENT);\n \t\tif (write_locked_index(&the_index, &index_lock,\n \t\t\t\t COMMIT_LOCK | SKIP_IF_UNCHANGED))\n-\t\t\tdie(_(\"unable to write new_index file\"));\n+\t\t\tdie(_(\"unable to write new index file\"));\n \t\tcommit_style = COMMIT_AS_IS;\n \t\tret = get_index_file();\n \t\tgoto out;\n@@ -518,7 +518,7 @@ static const char *prepare_index(const char **argv, const char *prefix,\n \trefresh_index(&the_index, REFRESH_QUIET, NULL, NULL, NULL);\n \tcache_tree_update(&the_index, WRITE_TREE_SILENT);\n \tif (write_locked_index(&the_index, &index_lock, 0))\n-\t\tdie(_(\"unable to write new_index file\"));\n+\t\tdie(_(\"unable to write new index file\"));\n \n \thold_lock_file_for_update(&false_lock,\n \t\t\t\t git_path(\"next-index-%\"PRIuMAX,\n@@ -1852,7 +1852,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)\n \n \tif (commit_index_files())\n \t\tdie(_(\"repository has been updated, but unable to write\\n\"\n-\t\t \"new_index file. Check that disk is not full and quota is\\n\"\n+\t\t \"new index file. Check that disk is not full and quota is\\n\"\n \t\t \"not exceeded, and then \\\"git restore --staged :/\\\" to recover.\"));\n \n \tgit_test_write_commit_graph_or_die();\n-- \n2.42.0-398-ga9ecda2788\n\n"},{"id":"483469","messageId":"CANYiYbEqTH975j9E0GTbSbexrw3MLhKwBCw7mibfnWbxZ+-_yw@mail.gmail.com","threadId":"60385","inReplyTo":"xmqqwmvkve83.fsf@gitster.g","subject":"Re: Is there any interest in localizing term delimiters in git messages?","fromName":"Jiang Xin","fromEmail":"worldhello.net@gmail.com","sentAt":"2023-10-19T05:08:10Z","receivedAt":"2023-10-19T05:08:24Z","isPatch":false,"sender":{"key":"worldhello.net@gmail.com","avatar":"https://avatars.githubusercontent.com/u/183860?v=4"},"body":"On Wed, Oct 18, 2023 at 10:47 AM Junio C Hamano wrote:\n>\n> Jiang Xin writes:\n>\n> > Starting with the release of git 2.34.0 two years ago, we had a new\n> > l10n pipeline and the git-po-helper tool as part of our l10n workflow.\n> > The first version of git-po-helper introduced a validator to protect\n> > git command parameters and variable names in megid.\n>\n> Ahh, that is the piece I was missing. I didn't know you guys are\n> doing extra checks that could trigger false positives.\n>\n> > E.g. In pull\n> > request 541 (https://github.com/git-l10n/git-po/pull/541), a\n> > mismatched variable name \"new_index\" was reported in bg.po as below:\n> >\n> > level=warning msg=\"mismatch variable names in msgstr: new_index\"\n> > level=warning msg=\">> msgid: unable to write new_index file\"\n> > level=warning msg=\">> msgstr: новият индекс не може да бъде записан\"\n> >\n> > And po/bg.po changed as below:\n> >\n> > msgid \"unable to write new_index file\"\n> > msgstr \"новият индекс (new_index) не може да бъде записан\"\n>\n> Wait. Is this supposed to be a good example of validator working\n> well? We use this exact message three times in builtin/commit.c; is\n> the validator insisting on the translated message to have verbatim\n> string \"new_index\" in it so that the end-users will see it?\n>\n> I may still be confused, but if that is what is going on, I think it\n> is a wrong validation in this particular case. I can understand if\n> we were creating say .git/new_index file and it helps the end users\n> to diagnose a troubled repository by running \"ls .git\" to see if a\n> file called \"new_index\" exists and getting in the way, but I do not\n> think it is the case. A new file \".git/index.lock\" is created via\n> repo_hold_locked_index() and I do not think it helps the end-user to\n> know that we may be calling it \"new_index\" internally among the\n> developers' circle. If the message were about \"index.lock\", it\n> might be a different story, but such an error would probably have\n> been issued long before write_locked_index() gets called.\n>\n> I'd suggest doing s/new_index/new index/ to msgid string for these\n> anyway.\n\nI tried to find similar patterns in `po/bg.po` using:\n\n $ git grep -h -B5 '([a-zA-Z_\\.]*_[a-zA-Z_\\.]\\+)' po/bg.po\n\nAnd find other translated variable names in Bulgarian as follows:\n\n * cookie_result in builtin/fsmonitor--daemon.c:\n\n error(_(\"fsmonitor: cookie_result '%d' != SEEN\"),\n\n * run_command in builtin/submodule--helper.c:\n\n die(_(\"run_command returned non-zero status for %s\\n.\"),\n die(_(\"run_command returned non-zero status while \"\n\n * crlf_action in convert.c:\n\n warning(_(\"illegal crlf_action %d\"), (int)crlf_action);\n\n * lazy_dir in name-hash.c:\n\n die(_(\"unable to create lazy_dir thread: %s\"),\n\n * lazy_name in name-hash.c:\n\n die(_(\"unable to create lazy_name thread: %s\"),\n die(_(\"unable to join lazy_name thread: %s\"),\n\n * load_cache_entries in read-cache.c:\n\n die(_(\"unable to create load_cache_entries thread: %s\"),\n die(_(\"unable to join load_cache_entries thread: %s\"),\n\n * load_index_extensions in read-cache.c:\n\n die(_(\"unable to create load_index_extensions thread: %s\"),\n die(_(\"unable to join load_index_extensions thread: %s\"),\n\nApart from \"new_index\", it seems that none of the above sentences can\nbe rewritten simply by removing the underscores in variable names\nwithout breaking the grammar, and I suppose it would be better to keep\nthose variable names unchanged.\n"},{"id":"483509","messageId":"xmqqcyxaxzxw.fsf@gitster.g","threadId":"60385","inReplyTo":"CANYiYbEqTH975j9E0GTbSbexrw3MLhKwBCw7mibfnWbxZ+-_yw@mail.gmail.com","subject":"Re: Is there any interest in localizing term delimiters in git messages?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-10-19T17:52:11Z","receivedAt":"2023-10-19T17:58:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jiang Xin writes:\n\n> I tried to find similar patterns in `po/bg.po` using:\n>\n> $ git grep -h -B5 '([a-zA-Z_\\.]*_[a-zA-Z_\\.]\\+)' po/bg.po\n>\n> And find other translated variable names in Bulgarian as follows:\n> ...\n> I suppose it would be better to keep those variable names\n> unchanged.\n\nTo me, all of them refer to names given to variables, functions, and\nmechanisms used internally as implementation details, and they are\nmeant to help developers diagnose when end-users hit these errors.\n\nI agree with you that translating these would be counter-productive\nfor that purpose.\n\nHaving said that, I have to wonder if in an ideal world these should\nbe written in terms that are more end-user facing.\n\n> * cookie_result in builtin/fsmonitor--daemon.c:\n>\n> error(_(\"fsmonitor: cookie_result '%d' != SEEN\"),\n\n[jch: cc'ed JeffH for area expertise]\n\nFor example, what does it mean to the end user when the\ncookie->result we retrieve is different from FCIR_SEEN? We lost\nsync with the fsmonitor daemon backend and to avoid yielding\nincorrect data we will be giving the \"trivial\" response only? It is\nnot obvious from the code and b05880d3 (fsmonitor--daemon: use a\ncookie file to sync with file system, 2022-03-25) that added it why\nthe end-user might even want to be shown this message [*]. I wonder\nif this should be an untranslated trace2_* message that are meant\nfor debugging.\n\n\tSide note: and isn't the significance of the event\n\t \"warning\", not \"error\"? As far as the end-user is\n\t concerned, after emitting this message\n\nAlso some of them might better be a BUG(), instead of die(_()).\n\n> * crlf_action in convert.c:\n>\n> warning(_(\"illegal crlf_action %d\"), (int)crlf_action);\n\n[jch: cc'ed Torsten for area expertise].\n\nFor example, can convert.c::output_eol() be called with an illegal\ncrlf_action that is not covered by the switch() statement due to\ndata error, not a programming error? From my quick scan, it looks\nlike that the error should never happen no matter what end-user\nmistakes (e.g., misspelt attribute and configuration variable names\nin their files) are fed to convert_attrs(), and can come only from a\nbug in that function (e.g., long and convoluted if/else cascade fails\nto assign any value to ca->crlf_action and leaves an undefined and\n\"illegal\" value there).\n\nThanks.\n"},{"id":"483512","messageId":"573f1142-d1de-b379-2f8b-07396c1249ec@jeffhostetler.com","threadId":"60385","inReplyTo":"xmqqcyxaxzxw.fsf@gitster.g","subject":"Re: Is there any interest in localizing term delimiters in git messages?","fromName":"Jeff Hostetler","fromEmail":"git@jeffhostetler.com","sentAt":"2023-10-19T18:07:16Z","receivedAt":"2023-10-19T18:07:23Z","isPatch":false,"sender":{"key":"git@jeffhostetler.com","avatar":null},"body":"\n\nOn 10/19/23 1:52 PM, Junio C Hamano wrote:\n> Jiang Xin writes:\n> \n>> I tried to find similar patterns in `po/bg.po` using:\n>>\n>> $ git grep -h -B5 '([a-zA-Z_\\.]*_[a-zA-Z_\\.]\\+)' po/bg.po\n>>\n>> And find other translated variable names in Bulgarian as follows:\n>> ...\n>> I suppose it would be better to keep those variable names\n>> unchanged.\n> \n> To me, all of them refer to names given to variables, functions, and\n> mechanisms used internally as implementation details, and they are\n> meant to help developers diagnose when end-users hit these errors.\n> \n> I agree with you that translating these would be counter-productive\n> for that purpose.\n> \n> Having said that, I have to wonder if in an ideal world these should\n> be written in terms that are more end-user facing.\n> \n>> * cookie_result in builtin/fsmonitor--daemon.c:\n>>\n>> error(_(\"fsmonitor: cookie_result '%d' != SEEN\"),\n> \n> [jch: cc'ed JeffH for area expertise]\n> \n> For example, what does it mean to the end user when the\n> cookie->result we retrieve is different from FCIR_SEEN? We lost\n> sync with the fsmonitor daemon backend and to avoid yielding\n> incorrect data we will be giving the \"trivial\" response only? It is\n> not obvious from the code and b05880d3 (fsmonitor--daemon: use a\n> cookie file to sync with file system, 2022-03-25) that added it why\n> the end-user might even want to be shown this message [*]. I wonder\n> if this should be an untranslated trace2_* message that are meant\n> for debugging.\n> \n> \tSide note: and isn't the significance of the event\n> \t \"warning\", not \"error\"? As far as the end-user is\n> \t concerned, after emitting this message\n> \n> Also some of them might better be a BUG(), instead of die(_()).\n...\n\n\nYeah, I think it should be an untranslated trace2 message rather\nthan an error. You're right, the user cannot do anything with\nthat information -- and by emitting a \"trivial\" result, we fall\nback to the normal behavior and cause the client to a regular\nscan. So there is no reason to scare the user.\n\nJeff\n"},{"id":"483515","messageId":"xmqqjzriwhde.fsf@gitster.g","threadId":"60385","inReplyTo":"573f1142-d1de-b379-2f8b-07396c1249ec@jeffhostetler.com","subject":"Re: Is there any interest in localizing term delimiters in git messages?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-10-19T19:18:37Z","receivedAt":"2023-10-19T19:18:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff Hostetler writes:\n\n> Yeah, I think it should be an untranslated trace2 message rather\n> than an error. You're right, the user cannot do anything with\n> that information -- and by emitting a \"trivial\" result, we fall\n> back to the normal behavior and cause the client to a regular\n> scan. So there is no reason to scare the user.\n\nThanks for a quick response. Note that this was something we\ndiscovered while talking about i18n and no immediate action is\nrequired---it is not like we saw a report that tells us that end\nusers are actively getting confused.\n\nTHanks.\n"},{"id":"483527","messageId":"20231019194747.GC25301@tb-raspi4","threadId":"60385","inReplyTo":"xmqqcyxaxzxw.fsf@gitster.g","subject":"Re: Is there any interest in localizing term delimiters in git messages?","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2023-10-19T19:47:47Z","receivedAt":"2023-10-19T19:48:29Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Thu, Oct 19, 2023 at 10:52:11AM -0700, Junio C Hamano wrote:\n\n>\n> Also some of them might better be a BUG(), instead of die(_()).\n>\n> > * crlf_action in convert.c:\n> >\n> > warning(_(\"illegal crlf_action %d\"), (int)crlf_action);\n>\n> [jch: cc'ed Torsten for area expertise].\n>\n> For example, can convert.c::output_eol() be called with an illegal\n> crlf_action that is not covered by the switch() statement due to\n> data error, not a programming error? From my quick scan, it looks\n> like that the error should never happen no matter what end-user\n> mistakes (e.g., misspelt attribute and configuration variable names\n> in their files) are fed to convert_attrs(), and can come only from a\n> bug in that function (e.g., long and convoluted if/else cascade fails\n> to assign any value to ca->crlf_action and leaves an undefined and\n> \"illegal\" value there).\n\nThe switch case covers all 8 values of \"enum crlf_action\",\nand removing these 2 lines\n -\twarning(\"Illegal crlf_action %d\\n\", (int)crlf_action);\n -\treturn core_eol;\ndoes still compile without a compiler warning.\nSo yes, a BUG is more appropriate here.\nI hopefully find some time to send a patch the next days.\n\n>\n> Thanks.\n>\n"},{"id":"483529","messageId":"xmqq8r7yweo8.fsf@gitster.g","threadId":"60385","inReplyTo":"20231019194747.GC25301@tb-raspi4","subject":"Re: Is there any interest in localizing term delimiters in git messages?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-10-19T20:16:55Z","receivedAt":"2023-10-19T20:17:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torsten Bögershausen writes:\n\n> The switch case covers all 8 values of \"enum crlf_action\",\n> and removing these 2 lines\n> -\twarning(\"Illegal crlf_action %d\\n\", (int)crlf_action);\n> -\treturn core_eol;\n> does still compile without a compiler warning.\n> So yes, a BUG is more appropriate here.\n\nYeah, and if our expectation is whenever we add a new value to enum\nconvert_crlf_action, we will handle in and return from the switch\nstatement, so I agree with you that BUG() is more appropriate.\n\nThanks for a quick response. Note that this was something we\ndiscovered while talking about i18n and no immediate action is\nrequired---it is not like we saw a report that tells us that end\nusers are actively getting confused by this message.\n\nThanks.\n"},{"id":"483618","messageId":"f6d7e29c-3532-428b-2c1-371eedaa5492@softwolves.pp.se","threadId":"60385","inReplyTo":"CAP6f5Mmi=f4DPcFwfvEiJMdKMa0BUyZ019mc8uFXyOufgD4NjA@mail.gmail.com","subject":"Re: Is there any interest in localizing term delimiters in git messages?","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2023-10-21T09:30:32Z","receivedAt":"2023-10-21T09:37:20Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Alexander Shopov:\n\n> Hello all,\n>\n> Is there any interest in being able to change the delimiters of the\n> changeable terms in git messages?\n>\n> Typical example:\n> ORIGINAL\n> msgid \" (use \\\"git rm --cached ...\\\" to unstage)\"\n\nI think there should be something indicating the variables, and with \nUnicode there are better choices than the ASCII \nless-than-greater-than, for instance U+2039/U+203A. In the same way, \nwe could also fix the quotation marks:\n\n \" (use “git rm --cached ‹file›...” to unstage)\"\n\nThe source should perhaps still be ASCII-only to be compatible with \nolder systems, but we could create a en_US.UTF-8 localization file \nthat does the above, and apply similar changes to other localizations \n(I have been thinking about doing it to the Swedish translation for a \nwhile, but so far have not come around to; of course quoting differs \nfrom language to language, with different styles for ‘English’, \n“American”, „German”, ”Swedish” and «Norwegian», for instance; it is \nall very confusing and difficult to get right).\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"}]}