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

Bug #16953 reported by Santiago M. Mola on 2005-05-12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Ubuntu Server papercuts
Fix Released
aptitude (Ubuntu)

Bug Description

When I made a dist-upgrade today I had this message:

WARNING: untrusted versions of the following packages will be installed!

Untrusted packages could compromise your system's security.
You should only proceed with the installation if you are certain that
this is what you want to do.

(..a list of packets...)

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...

It works fine with apt-get.

Santiago M. Mola (smola) wrote :

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

Michael Vogt (mvo) wrote :

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).


Santiago M. Mola (smola) wrote :

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

Michael Vogt (mvo) wrote :

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

Julian Alarcon (alarconj) wrote :

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

Changed in aptitude (Ubuntu):
status: Fix Released → Confirmed
assignee: Michael Vogt (mvo) → Ubuntu Spanish Translators (ubuntu-l10n-es)
Rolf Leggewie (r0lf) on 2009-10-03
summary: - Error in Spanish locale for aptitude (Breezy)
+ Error in Spanish locale for aptitude

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.

Daniel Hahler (blueyed) wrote :

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.

Changed in aptitude (Ubuntu):
importance: High → Low
status: Confirmed → Triaged
summary: - Error in Spanish locale for aptitude
+ Error in Spanish locale for aptitude: should accept "Si" and "Sí"
summary: - Error in Spanish locale for aptitude: should accept "Si" and "Sí"
+ Aptitude: should accept both "Si" and "Sí" (when asking for
+ confirmation)
Changed in aptitude (Ubuntu):
milestone: ubuntu-5.10 → none
assignee: Ubuntu Spanish Translators (ubuntu-l10n-es) → nobody
Federico Vera (fedevera) wrote :

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

Santiago M. Mola (smola) wrote :

@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.

Federico Vera (fedevera) wrote :

@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?

Thierry Carrez (ttx) wrote :

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

Changed in server-papercuts:
status: New → Won't Fix
Thierry Carrez (ttx) wrote :

Reopening for consideration in the maverick papercuts cycle

Changed in server-papercuts:
status: Won't Fix → New
Nicolas Valcarcel (nvalcarcel) wrote :

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

Thierry Carrez (ttx) on 2010-06-02
Changed in server-papercuts:
importance: Undecided → Low
milestone: none → maverick-alpha-2
status: New → Triaged
Thierry Carrez (ttx) on 2010-06-15
Changed in server-papercuts:
assignee: nobody → Nicolas Valcárcel (nvalcarcel)
Nicolas Valcarcel (nvalcarcel) wrote :

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

Thierry Carrez (ttx) on 2010-06-29
Changed in server-papercuts:
milestone: maverick-alpha-2 → maverick-alpha-3
Nicolas Valcarcel (nvalcarcel) wrote :

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

Thierry Carrez (ttx) wrote :

Too much work for a papercut

Changed in server-papercuts:
assignee: Nicolas Valcárcel (nvalcarcel) → nobody
status: Triaged → Won't Fix
Changed in aptitude (Ubuntu):
assignee: nobody → Abhishek kumar singh (abhishekkumarsingh-cse)
status: Triaged → In Progress
Daniel Hartwig (wigs) wrote :

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

Daniel Hartwig (wigs) wrote :

... 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.

Changed in aptitude:
status: Unknown → New
Download full text (3.8 KiB)

tags 475802 + patch

[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", "y", "はい", or "ハイ"
  - negative: "n", "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.]

tags: added: patch
Daniel Hartwig (wigs) on 2012-10-21
Changed in aptitude (Ubuntu):
assignee: Abhishek kumar singh (abhishekkumarsingh-cse) → nobody
status: In Progress → Confirmed
Changed in aptitude:
status: New → Confirmed
Changed in aptitude:
status: Confirmed → Fix Committed
Changed in aptitude:
status: Fix Committed → Fix Released
Paul White (paulw2u) wrote :

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"

Changed in aptitude (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.