Request for comments/Help for starting project terminologies
A glossary entry must list at least these things:
- a word, phrase or expression,
- a context (usually a software product or an extension or group of those, but may be an logical area in a program, or "unspecified", where the more specific context overrides the less specific in search queries)
- a language plus possibly an area and a sccript.
Do we need more?
Definition. Without definition it is not easy to spot overlapping and ambiguous terms and to actually makes the messages more clear. I also think we should start with monolingual terminology.
I agree that a terminology would be useful and I also agree that we should start with a monolingual English (or in future any other source language of a project) glossary for each project.
Eventually we will need to devise a way for each language to build a bilingual glossary out of the main monolingual glossary efficiently. Having the monolingual glossary to build on is going to cut out a lot of work in setting up bilingual glossaries and it will mean that language teams are not doubling-up on the work of defining terms. It will also mean that all glossaries will be compatible.
I think it will enhance the projects themselves too, to have a glossary for its users. If we can produce a good glossary here, then we should be able to return this to the project as a service to their users. Our task is to make or improve on the English glossary already made at the project, with advice from the project developers and being reviewed by them. Then, we can create bilingual glossaries of the terms themselves, for our own use. Optionally, we could also translate the definitions and supply the project with translated glossaries, if our translators are willing to translate the definitions also. Translated definitions are going to be useful here in the future in the languages which are used as fallback by other languages, if we acquire translators who work primarily with the fallback instead of English.
I agree with having Definitions, at least where needed for disambiguations; and of course, they would not hurt otherwise. I agree to start with English. I do not mind adding other languages as soon as an original glossary entry is stable, but we should carefully design a method to to expand glossary entries
- without confronting users with an endless list of all possible language translations,
- allowing users to view translations in selected languages in parallel,
- allowing several equivalent translations, or synonymes,
- allowing definitions or explanations to be translated, too, so as to support translators who understand less or no English.
My first idea to create a glossary had been to set up a namespace "Glossary:" with translateable pages holding the expressions, and probably /qqq pages holding explanations, but that seems not sufficient now.