Addressing the terminology problems, in my opinion, does not necessarily mean waiting for an integrated help package or an acs-lang sponsor. As Carl said, documentation must not be "hidden away", but all texts including end-user docs and message catalogs must be more integrated with developers' work.
Minor changes in the administration of translateable messages would help a lot, not only for foreign languages but also for the en_US locale, because inconsistencies and sloppy tech speak are often discovered only after trying to translate them into usable texts. (One might even desire that all messages have to be translated from en_Develop to en_US before turning a beta into a release...).
Carls Propsal B splits in two parts:
B1 Tracking of changes within en_US: in the message listings "Translated" and "Untranslated", changed English originals should be listed in, e.g., "Untranslated mesages and unacknowledged changes", and in the translator's UI, the red and yellow markers should apply to them again.
B2 "A way of marking dependencies in acs-lang (e.g. when this term changes these terms are effected)": this is essentially the context problem translators have been addressing for long (see threads on context as this https://openacs.org/forums/message-view?message_id=125235 )
For B2 and for avoiding problems like #961, a simple terminology database would IMO solve the most important problems: every time when a developer must check if a new message key is needed, he could look up all similar terms in the database, provided that fellow developers provide for finding the respective contexts. For major concept changes, forum discussion is of course still necessary. For new packages, such i18n should be a requirement, anyway. For legacy packages this context annotation (and merging of keys as discussed in https://openacs.org/forums/message-view?message_id=158580 ) needs to be done at the next possible occasion and could be a requirement for being included in dotLRN distribution.
