Comment 20 for bug 16953

tags 475802 + patch
thanks

[CC to some people that commented on these bug reports related to
input translation on prompts.]

On 14 January 2012 22:24, Daniel Hartwig <email address hidden> wrote:
> Anyway, there are not many places where the prompt is invoked so I
> will get a patch together next time I am at the workstation.

Actually, ignoring cwidget prompts for now, there is only one straight
yes-no prompt:
  - cmdline_prompt.cc(prompt_trust)

This method currently expects the user to type exactly "yes" or it's
translation. Using rpmatch(3) (a wrapper for nl_langinfo(3)) the
attached patch changes this to a more standard yn prompt.

This is a great option which addresses all concerns raised for Bug:
#475802 and LP: #16953, and uses standard translations for input to
the yes-no prompt.

*NOTE* This patch addresses only the "untrusted sources" command-line
prompt. I provide some comments regarding the other prompts afterwards.

Now, some verbose examples of the new behaviour: (please skip forward
if short attention :-)

Deng Xiyue wrote:
> For Chinese user, "Yes" will be translated to "是", which will be used
> for the is_ok comparison. Meanwhile, "是" will not be able to input
> when input method is unavailable, which in turn isn't installed by
> default install settings.

So, for example, in the zh_CN locale this prompt now accepts responses
starting with:
  - affirmative: "y", or "是"
  - negative: "n", "不", or "否"

Noritada Kobayashi wrote:
> Yeah, it's true for Japanese users. "Yes" and "No" are respectively
> "はい" (hai) and "いいえ" (iie) in Japanese. Since they can be input
> only via input methods, however, softwares usually provide a prompt
> like "Yes/No" or "Y/N" to us. Forcing users to input "はい" is not a
> good idea.

In ja_JP locale the responses can start with:
  - affirmative: "y", "ｙ", "はい", or "ハイ"
  - negative: "n", "ｎ", "いいえ", or "イイエ"

Adam Borowski wrote:
> This way, if the language is russian, the prompt would be:
> "Start nuclear war? (Да/Нет) (Y/N)"

The "[y/n]" hint should not be included when there is already a
translated hint.

>
> where both "д" and "y" would confirm, and both "н" and "n" would deny.

ru_RU responses:
  - affirmative: "д", or "y"
  - negative: "н", or "n"

Santiago M. Mola wrote:
> Should I go ahead and install the packages anyway?
> To continue, enter "Sí"; to abort, enter "No":
> ---
>
> It doesn't work! I typed Si, S, Yes, Y... it doesn't work anyway...

The es_ES locale will now accept both "Sí" and "Si" (and any other
response beginning with "s" or "y").

*** Other prompts ***

A quick survey of the current situation with the other prompts.

On the command-line side there is:

  * cmdline_prompt.cc(prompt_essential): user must type a string
    exactly, either translated or untranslated.

    This is "working" right now, however, many translations require
    input methods to type and if those methods aren't available the
    user does not know they can type the untranslated string (they
    don't even get told what it is).

  * cmdline_prompt.cc(cmdline_do_prompt): the standard "Do you want
    to continue?" prompt for package installs, etc. -- does not
    accept translated input.

    We could (should?) accepted translated input to
    this prompt -- though there are a lot of commands and to handle
    this *thoroghly* will require translators to write small regular
    expressions like "nl_langinfo(YESEXPR)" provides.

  * cmdline_resolver.cc(cmdline_resolve_deps): the command-line
    problem resolver.

    Same situation as above.

I have not yet looked at the curses side very much. I assume that
most yes-no prompts can have the keybindings overloaded (e.g. "y" and
"j" mean "yes" for German) but don't know if there is a mechanism in
place to allow translators to define this.

Has any one had a chance to investigate the options for cwidget?