Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes:
> 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@xxxxxxxxxxxxxxxxxxxx>
> ---
> 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>.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html