Re: [RFC/PATCH 2/5] glossary: introduce glossary lookup command

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 10, 2014, 22:50 UTC
Message-ID: <xmqqa92vf7ao.fsf@gitster.dls.corp.google.com>
In-Reply-To: <585191103e7bdd21ed422324504b6503bec2b914.1418052470.git.git@drmicha.warpmail.net>

Michael J Gruber <git@drmicha.warpmail.net> writes:

Show 18 quoted lines

> When using a localised git, there are many reasons why a correspondence
> between English and localised git terms is needed:
> - connect localised messages with English ones (porcelain vs. plumbing)
> - connect localised messages with English man pages or online docs
> - help out someone in a different locale
>
> Introduce a `git glossary' command that leverages the existing infrastructure
> in three possible ways:
> - `git glossary' lists all glossary terms along with their translation
> - `git glossary foo' matches `foo' in the glossary (both English and
>   localisation; partial matches shown)
> - `git glossary -a foo' matches `foo' in the git message catalogue
>   (English, exact match only).
>
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
> ---
> Some bike-shedding expected regarding the interface...
> Once I've learned how to test l10n stuff, this will be amended.

This is interesting.

I wondered if we want to also have the associated documentation in response to a query, but I am not sure how well that would go without having a translated glossary at least. I.e. pulling the original from glossary-content.txt would produce something like this:

	$ LANG=de git glossary -l blob object
        Blob-Objekten
	Untyped <<def_object,object>>, e.g. the contents of a file.

which is not ideal.

I noticed that you allow querying more than one term from the command line, so the above example would not work quite well, as we would end up querying "blob" and then "object", not a single term "blob object" which does have N_() translation in <glossary.h>.