Aptitude: should accept both "Si" and "Sí" (when asking for confirmation)

It works in aptitude GUI too, but not in command line.

Thanks for your bugreport.

Did you try to enter: "Sí" (note that the second letter is not a "i" but a "í")?
It looks like aptitude is pretty strict about this. If it still does not work
with "Sí" I would like to know your locale settings (please type: "locale" and
attach the output).

Cheers,
 Michael

Yeah, it works with 'Sí'
Thank you,
Santiago Mola

I think this bug can be closed. If you disagree feel free to reopen it again and
explain what should be done.

Open again this bug. This problem is very annoying. I'm searching the string to translate/fix.

Maybe this one:?

https://translations.launchpad.net/ubuntu/jaunty/+source/aptitude/+pots/aptitude/es/325/+translate

Or this one:?

https://translations.launchpad.net/ubuntu/jaunty/+source/aptitude/+pots/aptitude/es/1138/+translate

Version in Karmic accepts 'Si' (without accent) and not 'Sí'. So the original problem is more or less fixed. However, the ideal situation is that it accepted both 'Si' and 'Sí' as correct, like other programs do.

I've triaged the bug accordingly.

I think this needs fixing in apitude to accept both the language specific string and the transliterated one.

@Santiago: what other programs do you know of? It might be useful if there's some generic method for this already and should get forwarded to the Aptitude developers.

Hi there, just one comment, aptitude shouldn't accept 'Sí' for this is a conditional statement ('if' in english), only 'Si' ('yes' in english).

@Federico, I guess you mean the other way: 'Si' (conditional) and 'Sí' (affirmative). 'Si' is linguistically incorrect but highly convenient.

Accepting both 'Si' and 'Sí' would make aptitude behave correctly from a linguistic point of view, while making possible to use aptitude in situations where an accent can't be typed. Think about a situation where you need aptitude and you're stuck with a bad configuration without accents, or using an american keyboard.

@Santiago yeahp that's what I ment (my bad). You are right, I haven't consider that option, why not use just 'S' or 's' so as to avoid confusion?

Too late to add new targets for server-papercuts, sorry :)

Reopening for consideration in the maverick papercuts cycle

Issue happends around line 721 in src/cmdline/cmdline_prompt.cc, from the comment in that section:
      // These strings are used to compare in a translation-invariant
      // way, so that "yes" and "no" are always valid inputs; if the
      // user can't enter the translated string for some reason,
      // he/she can always enter the fallback strings.
A function can be added to take words with accents and convert it to non accent ones, i.e change é for e, í for i and so on

Still haven't got time to get to this, postponing to A3

Code has changed and now problem is around like 570 of the same file, it seems that some translations have been disables aswell, this set of translations include Yes for Sí. The only viable way i can see of fixing this is to write a function that read the input and change the accent with his non-accented equivalence for the code to use it

Too much work for a papercut

Removing accents from strings before or while comparing them

There is libunac [1] which provides a function to remove accents from a string.

There is an algorithm discussed here [2] which could be implemented with libunistring:

Now, the best algorithm is hinted at the approved answer: Use NKD (decomposition) to decompose accented letters into the base letter and a seperate accent, and then remove all accents.

[accent characters are in the non-spacing mark category "Mn"]

[1] http://www.nongnu.org/unac/unac-man3.en.html
[2] http://stackoverflow.com/questions/144761/how-to-remove-accents-and-tilde-in-a-c-stdstring

... or see apt-get's "YnPrompt" for an alternate (and very succinct) solution using nl_langinfo(YESEXPR)

FYI the english version of this looks is "^[yY]", so matching any string beginning with 'y'.

This is probably the preferred way to go since it would match apt-gets behaviour.

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.

    ...

The attachment "0001-I18n-deficiency-in-cmdline-untrusted-prompt.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

Upstream bug was fixed in aptitude 0.7.6-1 on 2016-02-21
Ubuntu changelog includes:

- Bug fixes:
      * Properly set a default for $XDG_CACHE_HOME if not set. (Closes: #807545)
      * [cmdline] "w" at prompt now actually works (Closes: #555014)
      * Refuse to remove aptitude within aptitude (Closes: #319782, #568548)
      * [cmdline] Address prompt deficiencies related with translation and input
        methods (Closes: #475802)

Closing by marking "Fix Released"