Re: [Question] Translation Dictionary
On Thu, Feb 03 2022, rsbecker@nexbridge.com wrote:
Show 47 quoted lines
> 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.
rsbecker@nexbridge.com
