{"thread":{"id":"59368","subject":"Feature Request - Better i18n support","startedAt":"2023-03-09T13:06:35Z","lastAt":"2023-05-10T03:01:11Z","messageCount":7,"participants":["Emir SARI","Junio C Hamano","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"473280","messageId":"ZAnXddDN7v0AOBdm@mbp.local","threadId":"59368","inReplyTo":null,"subject":"Feature Request - Better i18n support","fromName":"Emir SARI","fromEmail":"emir_sari@icloud.com","sentAt":"2023-03-09T12:56:21Z","receivedAt":"2023-03-09T13:06:35Z","isPatch":false,"sender":{"key":"emir_sari@icloud.com","avatar":"https://avatars.githubusercontent.com/u/2769571?v=4"},"body":"Greetings,\n\nGit is translated into many languages, but as far as I can see, it does not\ntake localisation formats into account nor it allows them to be translated\ninto localised formats.\n\nFor instance, in Turkish (and in French AFAIK), percentages are indicated\nin different formats. In Turkish it precedes the number like %54. However,\nall the percentages use the standard 54%. By marking these as translatable,\nwe could easily provide the correct formats.\n\nAnother thing is the decimal signs. In many languages, a comma (,) is used to\nindicate decimals, however Git does not allow another formats. I am not sure\nhow to achieve this in C, but it would be great to have this in order to have\nan errorless professional look in Git outputs.\n\nThank you very much for your attention.\n\n[Sistem Bilgisi]\ngit sürümü:\ngit version 2.39.2\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nfeature: fsmonitor--daemon\nuname: Darwin 22.3.0 Darwin Kernel Version 22.3.0: Mon Jan 30 20:42:11 PST 2023; root:xnu-8792.81.3~2/RELEASE_X86_64 x86_64\nderleyici bilgisi: clang: 14.0.0 (clang-1400.0.29.202)\nlibc bilgisi: libc bilgisi yok\n$SHELL (typically, interactive shell): /bin/zsh\n"},{"id":"473321","messageId":"xmqqfsad8tap.fsf@gitster.g","threadId":"59368","inReplyTo":"ZAnXddDN7v0AOBdm@mbp.local","subject":"Re: Feature Request - Better i18n support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-03-09T22:16:14Z","receivedAt":"2023-03-09T22:16:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Emir SARI <emir_sari@icloud.com> writes:\n\n> For instance, in Turkish (and in French AFAIK), percentages are indicated\n> in different formats. In Turkish it precedes the number like %54. However,\n> all the percentages use the standard 54%. By marking these as translatable,\n> we could easily provide the correct formats.\n\nInteresting.  Let's take a look to see how bad it is.\n\n$ git grep '[fd]%%' \\*.[ch] ':!compat/' ':!t/'\napply.c:\t\tprintf(\" %s %.*s{%s => %s} (%d%%)\\n\", renamecopy,\napply.c:\t\tprintf(\" %s %s => %s (%d%%)\\n\", renamecopy,\napply.c:\t\t\t\t\tprintf(\" rewrite %s (%d%%)\\n\",\n\nThese are currently not even marked with _() to be translatable, and\nit should be just the matter of enclosing them in _().\n\nIf these should be translated in the first place, that is.  I do not\nthink these are originally meant to be machine parseable (it is\nshown as part of \"git apply --summary\"), but existing users may\nalready be abusing them as such.\n\ndiff.c:\t\t\t\tfprintf(opt->file, \"%s%4d.%01d%% %.*s\\n\", line_prefix,\n\nThis is part of \"git diff --dirstat\" output.  I do not think it\nshould be translated, even though it probably is not machine\nparseable.\n\ndiff.c:\t\tstrbuf_addf(msg, \"%s%ssimilarity index %d%%\",\ndiff.c:\t\tstrbuf_addf(msg, \"%s%ssimilarity index %d%%\",\ndiff.c:\t\t\tstrbuf_addf(msg, \"%s%sdissimilarity index %d%%%s\\n\",\ndiff.c:\tstrbuf_addf(&sb, \" %s %s (%d%%)\\n\",\n\nThese are part of the extended diff headers (e.g. \"rename A to B\nwith similarity index of X%\") that are very much designed to be\nmachine parseable, and cannot be touched.\n\ndiff.c:\t\t\tstrbuf_addf(&sb, \" (%d%%)\\n\", similarity_index(p));\n\nThis is part of \"git diff --summary\" to show \"rewrite\", similarly to\n\"rename\" and \"copy\" that we saw earlier.\n\nwt-status.c:\t\t\t\t_(\"You are in a sparse checkout with %d%% of tracked files present.\"),\n\nThis is already marked _(translatable) and your l10n files should be\nable to do \"%d%%\" -> \"%%%d\" as needed.\n\n"},{"id":"473323","messageId":"ZApdaAMrkmFcxarq@tapette.crustytoothpaste.net","threadId":"59368","inReplyTo":"ZAnXddDN7v0AOBdm@mbp.local","subject":"Re: Feature Request - Better i18n support","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2023-03-09T22:27:52Z","receivedAt":"2023-03-09T22:28:00Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2023-03-09 at 12:56:21, Emir SARI wrote:\n> Greetings,\n\nHey,\n\n> Git is translated into many languages, but as far as I can see, it does not\n> take localisation formats into account nor it allows them to be translated\n> into localised formats.\n\nThanks for the report.\n\n> For instance, in Turkish (and in French AFAIK), percentages are indicated\n> in different formats. In Turkish it precedes the number like %54. However,\n> all the percentages use the standard 54%. By marking these as translatable,\n> we could easily provide the correct formats.\n\nI think this should be relatively easy to do.  I didn't know Turkish did\nthis (and I suspect nobody else did or we'd have fixed it), but I\nhaven't personally seen this in French (which doesn't mean that it isn't\ndone in some places).  We've already done human-readable byte values,\nwhich do vary in French (due to it using o, for octet, instead of B), so\nI don't see any reason why this couldn't be fixed.\n\nMore specifically, I think it could be fixed for progress output, but\nthere are a few places in diff output where it couldn't because it might\nbe parsed.  Would you be willing to try a patch for this?  I think the\ncode you're probably thinking about is in progress.c (search for \"%%\"),\nbut there might be other places you have in mind as well.\n\n> Another thing is the decimal signs. In many languages, a comma (,) is used to\n> indicate decimals, however Git does not allow another formats. I am not sure\n> how to achieve this in C, but it would be great to have this in order to have\n> an errorless professional look in Git outputs.\n\nCan you clarify what places you're thinking about?  Is this printing\ndecimal values, or is it parsing decimal values?  If we know what\nspecifically is affected (for example, an affected command or message),\nit's a lot easier to fix this.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"473324","messageId":"xmqq7cvp8sdu.fsf@gitster.g","threadId":"59368","inReplyTo":"ZApdaAMrkmFcxarq@tapette.crustytoothpaste.net","subject":"Re: Feature Request - Better i18n support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-03-09T22:35:57Z","receivedAt":"2023-03-09T22:36:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n\n> More specifically, I think it could be fixed for progress output, but\n> there are a few places in diff output where it couldn't because it might\n> be parsed.  Would you be willing to try a patch for this?  I think the\n> code you're probably thinking about is in progress.c (search for \"%%\"),\n> but there might be other places you have in mind as well.\n\nAh, my earlier grep missed this, as it tried only to catch [fdi]%%\nand the progress thing uses \"%u%%\" like so:\n\n\t\tif (percent != progress->last_percent || progress_update) {\n\t\t\tprogress->last_percent = percent;\n\n\t\t\tstrbuf_reset(counters_sb);\n\t\t\tstrbuf_addf(counters_sb,\n\t\t\t\t    \"%3u%% (%\"PRIuMAX\"/%\"PRIuMAX\")%s\", percent,\n\t\t\t\t    (uintmax_t)n, (uintmax_t)progress->total,\n\t\t\t\t    tp);\n\t\t\tshow_update = 1;\n\t\t}\n\nWith the PRIuMAX thing, it won't be as simple as enclosing the\nentire format string inside _(), though.\n\nThanks.\n"},{"id":"473325","messageId":"ZApgtJqVxkory4/B@tapette.crustytoothpaste.net","threadId":"59368","inReplyTo":"xmqq7cvp8sdu.fsf@gitster.g","subject":"Re: Feature Request - Better i18n support","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2023-03-09T22:41:56Z","receivedAt":"2023-03-09T22:43:57Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2023-03-09 at 22:35:57, Junio C Hamano wrote:\n> \"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n> \n> > More specifically, I think it could be fixed for progress output, but\n> > there are a few places in diff output where it couldn't because it might\n> > be parsed.  Would you be willing to try a patch for this?  I think the\n> > code you're probably thinking about is in progress.c (search for \"%%\"),\n> > but there might be other places you have in mind as well.\n> \n> Ah, my earlier grep missed this, as it tried only to catch [fdi]%%\n> and the progress thing uses \"%u%%\" like so:\n> \n> \t\tif (percent != progress->last_percent || progress_update) {\n> \t\t\tprogress->last_percent = percent;\n> \n> \t\t\tstrbuf_reset(counters_sb);\n> \t\t\tstrbuf_addf(counters_sb,\n> \t\t\t\t    \"%3u%% (%\"PRIuMAX\"/%\"PRIuMAX\")%s\", percent,\n> \t\t\t\t    (uintmax_t)n, (uintmax_t)progress->total,\n> \t\t\t\t    tp);\n> \t\t\tshow_update = 1;\n> \t\t}\n> \n> With the PRIuMAX thing, it won't be as simple as enclosing the\n> entire format string inside _(), though.\n\nSure, but we can split it into two invocations of strbuf_addf, one\nlocalized, one not, no big deal.  This was the place that immediately\nstood out to me as the place we see lots of percentages, but I'm glad\nyou mentioned a couple other places as well.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"473326","messageId":"9F4F74FC-B424-4BF7-9F9D-8A821C89B442@icloud.com","threadId":"59368","inReplyTo":"xmqqfsad8tap.fsf@gitster.g","subject":"Re: Feature Request - Better i18n support","fromName":"Emir SARI","fromEmail":"emir_sari@icloud.com","sentAt":"2023-03-09T23:12:25Z","receivedAt":"2023-03-09T23:20:41Z","isPatch":false,"sender":{"key":"emir_sari@icloud.com","avatar":"https://avatars.githubusercontent.com/u/2769571?v=4"},"body":"Hello,\n\nThank you very much for the prompt responses.\n\n> Junio C Hamano <gitster@pobox.com> şunları yazdı (10 Mar 2023 01:16):\n> \n> These are currently not even marked with _() to be translatable, and\n> it should be just the matter of enclosing them in _().\n> \n> If these should be translated in the first place, that is.  I do not\n> think these are originally meant to be machine parseable (it is\n> shown as part of \"git apply --summary\"), but existing users may\n> already be abusing them as such.\n\nMy general idea is, if the percentages appear with the translated\nstrings, they should use the localised format. Otherwise if they\nonly appear with some machine-output without any localised context\nit is perfectly fine to leave them as-is.\n\n> brian m. carlson <sandals@crustytoothpaste.net> şunları yazdı (10 Mar 2023 01:27):\n> \n> More specifically, I think it could be fixed for progress output, but\n> there are a few places in diff output where it couldn't because it might\n> be parsed.  Would you be willing to try a patch for this?  I think the\n> code you're probably thinking about is in progress.c (search for \"%%\"),\n> but there might be other places you have in mind as well.\n\nThe progress output was my biggest motivation in reporting this. It was\nrather disturbing to see translated strings with unlocalised values.\n\nI’d love to assist in testing any possible patches. Just let me know of\nany possible scenarios, and I’ll get back to you. Being in vacation, I\nhave plenty of time available.\n\n> Can you clarify what places you're thinking about?  Is this printing\n> decimal values, or is it parsing decimal values?  If we know what\n> specifically is affected (for example, an affected command or message),\n> it's a lot easier to fix this.\n\nIn general, I am not concerned with parsing, it’s more about printing\nthem. As with the percentage situation, having unlocalised content with\nlocalised strings is not ideal. For instance, my ideal pull output would\nlook like this:\n\nNesneler sayılıyor: %100 (12/12), bitti.\nDelta sıkıştırması 8 iş parçacığı kullanıyor\nNesneler sıkıştırılıyor: %100 (7/7), bitti.\nNesneler yazılıyor: %100 (7/7), 3,79 KiB | 3,79 MiB/sn, bitti.\n\nAs I’ve indicated above, I am ready to test anything you might throw\nat me. :)\n\nThank you again very much!\n\nBest regards,\nEmir (𐰽𐰺𐰍)\n\n** E-mail needs to stay simple\n** Use plain text e-mail\n\n"},{"id":"476943","messageId":"D9534BB9-DF29-425D-9B4D-4DE051C1DB8B@icloud.com","threadId":"59368","inReplyTo":"ZApgtJqVxkory4/B@tapette.crustytoothpaste.net","subject":"Re: Feature Request - Better i18n support","fromName":"Emir SARI","fromEmail":"emir_sari@icloud.com","sentAt":"2023-05-10T02:50:56Z","receivedAt":"2023-05-10T03:01:11Z","isPatch":false,"sender":{"key":"emir_sari@icloud.com","avatar":"https://avatars.githubusercontent.com/u/2769571?v=4"},"body":"Hello,\n\nHow does the below diff look:\n\ndiff --git a/apply.c b/apply.c\nindex 6212ab3..3e1d08d 100644\n--- a/apply.c\n+++ b/apply.c\n@@ -4247,11 +4247,11 @@ static void show_rename_copy(struct patch *p)\n \t * new_name through the end of names are renames\n \t */\n \tif (old_name != p->old_name)\n-\t\tprintf(\" %s %.*s{%s => %s} (%d%%)\\n\", renamecopy,\n+\t\tprintf(_(\" %s %.*s{%s => %s} (%d%%)\\n\"), renamecopy,\n \t\t       (int)(old_name - p->old_name), p->old_name,\n \t\t       old_name, new_name, p->score);\n \telse\n-\t\tprintf(\" %s %s => %s (%d%%)\\n\", renamecopy,\n+\t\tprintf(_(\" %s %s => %s (%d%%)\\n\"), renamecopy,\n \t\t       p->old_name, p->new_name, p->score);\n \tshow_mode_change(p, 0);\n }\n@@ -4270,8 +4270,8 @@ static void summary_patch_list(struct patch *patch)\n \t\t\t\tshow_rename_copy(p);\n \t\t\telse {\n \t\t\t\tif (p->score) {\n-\t\t\t\t\tprintf(\" rewrite %s (%d%%)\\n\",\n-\t\t\t\t\t       p->new_name, p->score);\n+\t\t\t\t\tprintf(\" rewrite %s \", p->new_name);\n+\t\t\t\t\tprintf(_(\"(%d%%)\\n\"), p->score);\n \t\t\t\t\tshow_mode_change(p, 0);\n \t\t\t\t}\n \t\t\t\telse\ndiff --git a/progress.c b/progress.c\nindex f695798..1f8d372 100644\n--- a/progress.c\n+++ b/progress.c\n@@ -124,10 +124,24 @@ static void display(struct progress *progress, uint64_t n, const char *done)\n \t\t\tprogress->last_percent = percent;\n \n \t\t\tstrbuf_reset(counters_sb);\n-\t\t\tstrbuf_addf(counters_sb,\n-\t\t\t\t    \"%3u%% (%\"PRIuMAX\"/%\"PRIuMAX\")%s\", percent,\n+\n+\t\t\tstruct strbuf progress_sb = STRBUF_INIT;\n+\t\t\tstrbuf_addf(&progress_sb,\n+\t\t\t\t_(\"%u%% (%\"PRIuMAX\"/%\"PRIuMAX\")%s\"), percent,\n \t\t\t\t    (uintmax_t)n, (uintmax_t)progress->total,\n \t\t\t\t    tp);\n+\t\t\tstruct strbuf progress_str = STRBUF_INIT;\n+\t\t\tstrbuf_addstr(&progress_str, progress_sb.buf);\n+\t\t\tstrbuf_release(&progress_sb);\n+\n+\t\t\tif (percent < 10)\n+\t\t\t    strbuf_insert(&progress_str, 0, \"  \", 2);\n+\t\t\telse if (percent < 100)\n+\t\t\t    strbuf_insert(&progress_str, 0, \" \", 1);\n+\n+\t\t\tstrbuf_addf(counters_sb, \"%s\", progress_str.buf);\n+\t\t\tstrbuf_release(&progress_str);\n+\n \t\t\tshow_update = 1;\n \t\t}\n \t} else if (progress_update) {\n\nI’ve left diff.c out, since there are no accompanying localised strings to my knowledge. If this looks good, then only remaining thing to tackle would be localised decimal separators I think.\n\nBest regards,\nEmir (𐰽𐰺𐰍)\n\n** E-mail needs to stay simple\n** Use plain text e-mail\n\n"}]}