Junio C Hamano schrieb am 10.12.2014 um 23:50: > 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 Yes, I think we would need something different then. The glossary entries are asciidoc which we can't format easily from the glossary command. I really think of the glossary command as being orthogonal to the definitory glossary. I guess I should name it "translate" instead. It's just that I don't know how to do the translation from the locale back to English for stuff in the message catalogue (i.e. how to search the translations), unless I list the msgids the way I do for the glossary terms. It could be any list of terms. The glossary seemed to be a good place for that list of most important terms which users may want to translate both ways. > 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>. Exactly, one would need to query for "blob object". Or we concatenate arguments automatically, but I think being able to query multiple terms (also) is more useful. Michael -- 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