Enhancement request: Decouple keys from context, and set up a mechanism to handle context

[EvanAad]

I'm not familiar with the translation package. I wrote the following post as an enhancement request to the translator package, but was told that the translator package would not undergo any major developments, and that I should discuss the matter with the developers of the translation package. As I mentioned, I'm not familiar with the translation package, but from a cursory read through the manual, it appears to me that the translation package suffers from the same shortcoming as the translator package, which prompted me to ask for the enhancement request. Therefore, I post the request as-is. Please read it with the understanding that it was originally written with the translator package in mind, but that the ideas brought up in it likely apply equally to the translation package.

---

A given word can have many meanings. The meaning conveyed by a specific occurrence of a word depends on its context. Conversely, a given meaning can be conveyed by many words. In a given context, some of these words may be more suitable than others to convey the meaning. Therefore, when translating a word from one language to another, the context in which the word is used is crucial for determining the suitable translation.

In the current implementation of the translator package a word's context, in the rare occasion it is given at all, is part of the key. For instance in the basic standard dictionary, there are two keys for the entry encl: encl (plural) and encl (singular).

One of the problematic implications of the inclusion of context as part of keys can be seen when a new language is added to an existing dictionary type, for instance when translator-basic-dictionary-Hebrew.dict is added to the list of dictionaries of type translator-basic-dictionary. The new language may require that more context be added to a certain key in order to effect a suitable translation. For instance, the key author, which is part of the basic standard dictionaries, assumes two different grammatical forms in Hebrew, depending on the author's gender: a male author is מחבר, whereas a female author is מחברת. There is no gender-neutral form in Hebrew, and using one of these forms in a context when the other is expected would be inappropriate. In the current architecture of the translator package, in order to accommodate Hebrew, a new pair of keys needs to be added to the dictionary: author (male) and author (female), and --- and this is the important, and problematic part --- all instances of use of the old key, e.g. in the beamer class, must be replaced by one of the two new keys, according to context. But doing so will break existing code, and will require users of languages in which this gender distinction plays no part (e.g. English) to provide duplicate translations of this key for the new contextualized keys. But more importantly: this can't be done by the author of the beamer class, because they can't tell in advance whether the author referred to by this key is male or female.

I lay that this situation is unacceptable, and unsustainable.

In its stead a mechanism should be set up that would decouple keys from their contexts, and enable the unobtrusive addition of an arbitrary number of context indicators to every key without affecting existing usages of the key, and with each language being able to choose which context indicators of a given key it needs and will respond to.

This requires serious thought, but as a first "draft" I suggest adding a context option to the \providetranslation command. In this way the writer of translator-basic-dictionary-English.dict can specify \providetranslation{author}{author}, whereas the writer of translator-basic-dictionary-Hebrew.dict can spacify \providetranslation{author}[context=male]{מחבר}, \providetranslation{author}[context=female]{מחברת}.

Now, to "deploy" a translation, the class or package that uses the \translate command must use it inside a command or environment that is part of the class/package public user interface that is available to the end users. For instance, if the beamer class wants to use the translator package to translate the key author, it must do so inside the command \author, which is made available for end users of the beamer class to use. The \author command, in turn, must now be equipped with a context option, that the end users can optionally use to supply context. A Hebrew user of this command would use it in the following manner: \author[context=female]{לאה גולדברג}, or \author[context=male]{סייד קשוע}, whereas an English user of this command can use it either with or without the context option: \author{Jack London} or \author[context=male]{Jack London}. For the English user the context option will be ignored, since the basic dictionary doesn't specify any context indicators for the key author. However, the translator package can now choose the correct translation from the Hebrew version of the basic dictionary based on the context supplied by the end user.