On Thu, Feb 03 2022, rsbecker@xxxxxxxxxxxxx wrote: > On February 3, 2022 4:55 AM, Ævar Arnfjörð Bjarmason wrote: >> On Thu, Feb 03 2022, Jean-Noël Avila wrote: >> > I guess not all git translators are subscribed to the mailing list, as >> > they mostly interact with Jiang. I put them in cc. >> > >> > For French, I try to maintain a glossary of terms in the header of the >> > `fr.po` file, available here: >> > https://github.com/git/git/blob/master/po/fr.po >> >> I started trying to come up with something similar for the Icelandic translation I >> plan on getting to any day now (for ~11 years and counting). >> >> I think it would be a really good addition to git to move this list into a built-in or an >> option for "git help", something like: >> >> git i18n-terms >> >> Or: >> >> git help --common-terms >> >> It would help users that use a non-English a lot, since they could use it as a >> reliable cheatsheet, and it would clearly help translators, since it could be one of >> the first things they'd translate, to anchor themselves when it comes to >> translating blob/tree/commit/tag etc. >> >> If you're interested I can help you come up with that. Basically it would be some >> "static" array with that table as C code with strings marked with N_(). We could >> then add optional explanations as in >> gitglossary(7) (and even eventually generate that documentation from that >> code). > > Yes, I would like to investigate doing this. I have some experience > with different translation approaches, so it does make sense to > me. The question is where to start. From a framework standpoint, it > would be nice to have the terms externalized and searchable (as in git > glossary [term]... or perhaps more completely git glossary --grep=term > --language=fr --iso=fr_CA [term]...). I can also see some provisioning > for phrases, "upstream remote" comes to mind as one that gave me a > headache earlier in the week, and potentially usage - in Jean-Noël > list, prefacing "to" to a term implies it is a verb rather than a noun > but we might want to consider a more normalized approach to managing > usage, bearing in mind that this is a very large "rabbit hole". I > would even suggest that gitglossary(7) might ultimately be deprecated > particularly on systems without 'man(1)'. > > Help would definitely be appreciated in getting this started. I have a topic branch at github where I am planning on keeping this stuff visible. If you do: make command-list.h We end up with something similar to what I have in mind. That one happens to be generated, but we could just stick this in help.c for now. I.e.: struct i18n_term { const char *term;; }; static struct i18n_term i18n_terms[] = { { N_("3-way merge") }, { N_("#NN") }, { N_("a commit") }, [...], NULL, }; I.e. just a copy of the list at https://github.com/git/git/blob/master/po/fr.po. The help.c library has some examples that should be easy to follow e.g. how "git help --guides" calls list_guides_help(), which iterates a similar variable. For --language=* etc. you can do that with just LANGUAGE=<...> (i.e. via standard libintl) features. I think for this we could just stick with that. And instead of --grep you can pipe to grep(1) :) This can always be made fancier later, and we can expand "struct i18n_term" with some category labels or whatever, e.g. for core data types (blob, tree, tag, commit) v.s. core concepts (merge, rebase, commit, pull, push) etc.
