Re: lynx-dev internationalizing menu options

[Klaus Weide]

On 31 Oct 1999, Tijs van Bakel wrote:

> I've been trying to localize the lynx messages to Dutch, but I have
> found some problems translating the hotkey-menus like this one:
> 
> msgid " H)elp O)ptions P)rint G)o M)ain screen Q)uit"
>       "/=search [delete]=history list \n"

I know the problem...

> For these interactive menus it might be useful if the hotkeys could be
> changed to letters that are more meaningful in another language.
> 
> What is the current opinion on this subject? Will lynx support other
> keys for other languages, or should I use the existing hotkeys to keep
> the interface consistent, or even a combination of both -- if at all
> possible?

IMO it is unlikely that lynx will support language-dependent key command
assignments in the near future.  It would require updating *a lot* of
stuff - code, documentation, lynx.cfg, how should it interact with
explicit KEYMAP in lynx.cfg...  Someone would have to go through all
this systematically, and it may still not work quite right or logically.

Having command keys that are non-obvious in a given language (but familiar
to those who already know "English" lynx) is much better than having some
inconsistent mess.

Of course, if you were not just writing message translations for the
mainstream lynx code, but creating your own completely localized lynx
(say for a "national" binary distribution, or for your own dialup users
in some location), that would a different case - you could then changes
all the references to fixed keys in code and documentation to get whatever
you want (but things that are now fixed to "English" would then be just
fixed to your language - not a general improvement).

So the best realistic solution for now is to make do with the current
state of affairs (unless someone comes forward with a grand plan for
change).  Have you looked at how your colleagues (other translators)
have tackled this?  (Emacs PO-mode has soem convenient keys to switch
back and forth between translations, for comparisons liek this.)  For
example, in my initial German translation (now taken over by someone
else in the German FT team) I have, for the message above:

msgid ""
" H)elp O)ptions P)rint G)o M)ain screen Q)uit /=search [delete]=history list "
"\n"
msgstr ""
"H)ilfe O)ptionen P) Druck G)ehe zu M) Hauptseite Q) Beenden /=Suche "

I.e. use like in English where the initial letters happen to be the same,
otherwise use a space.  It's not perfect (may be confusing e.g. to what
the "M)" belongs), you may come up with something better (or find better
ideas in other .po files).

I found the cookie prompts were probably the most difficult to deal
with...

> If other keys can be used, then how will this be possible to the
> translators?

The only case where language-specific key meaning is currently used is
yes/no responses in simple (but not all prompts), see HTConfirmDefault
in HTAlert.c (I *think* this was already in 2.8.2 code, it is now in
2.8.3dev code).  If you provide translations for
  msgid "yes"
  msgid "no"
then the first letter of those will be used instead (and shown in the
prompt text).  (I think this needs to be looked at again... at least,
the original "y" and "n" should be recognized in addition, in cases
where there is no conflict.  Also afaik this doesn't work in a
meaningful way for CJK charsets.  But the transltor is free to not
translate "yes" and "no", which wil lresult in default "English"
behavior).

   Klaus