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.