since we're going to meet up at the conference in two days, we don't
have to discuss this here on the list, but I thought I'll describe and
document the proposal anyway.
The situation: When you execute a function package in the GUI, in the
window where you enter the function arguments, the descriptive labels
for the arguments sometimes come up translated to the local language,
even though the package itself "only" has English labels (as it should).
AFAIK this happens when gretl recognizes the label string as something
where there's already a translation present from another context.
(This already presupposes two things: First you're running gretl in
non-English, secondly the function package author has actually added
labels to the function arguments, which is optional.)
The automatic translation has pros and cons. Pros: You get it for free
and it's good for users who don't know enough English. Cons: Most of the
times the result is a mish-mash of English and the local language, so
the question is if it actually helps enough to be valuable in practice.
The suggestion: First of all, the translation is not predictable for me
as a package author. I think we need a clear "lexicon" of labels that
will be translated. Next, I think a package author should be given
control over whether anything is translated. For some packages it's
probably better to keep them English only; for example given the fact
that the output is never going to be translated (and we actually made it
a policy to not include other languages in public packages, which had
caused some disagreement).
Perhaps the translation control might be as simple as telling the
author: If you don't want it translated, add a blank at the start or at
the end of your label. (?) More sophisticated solutions of course also
So much for the idea; as I said, perhaps we want to discuss it at the
conference. OTOH not everybody will be there.
Show replies by date