Hi,

[#475802]
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.

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.

> This is quite a dilemma for users using non-en_US based locales,
> especially CJK-based locales.  I'd propose such usage to be changed to
> a letter-based comparison, as Y for Yes and N for No or something like
> that.

I think this solution is a little bit extreme, since there are many
non-English locales and they cannot be considered in one group.  Take
a look at German for example.  Since "Yes" and "No" are "Ja" and
"Nein" in German, people are familiar with J/N prompts instead of Y/N
prompts.  Forcing users to input "Ja" does not have a problem.
Although I don't know about other Western cultures well, I think most
of Western languages, like German, does not have any issues since they
are composed of alphabets.

[#494816]
Hideki Yamane wrote;
>  Then, how can we continue? ...we should enter localized YES message,
>  such as ' "はい (Y)" ' (Japanese YES message) by copy&paste, '(' and ')'
>  are also needed to do. Umm.
>  See attached screenshot_aptitude-localized-continue01.png file.

Translating "Yes" and "No" to "はい (Y)" and "いいえ (N)" is an idea
from Ubuntu's aptitude package.  These are good for Y/N dialog strings
indeed, but have a by-product when used as a command line prompt as
you have shown, sigh...

>  This confuses non-English users, they want to continue by entering just
>  "Yes", but they can't do that. So could you try to give us any fix or
>  workaround for this issue by default? Needs help.

Not all "non-English users" as I described above.

Kenshi Muto wrote:
> I made two patches.
>
> - - cmdline_prompt.patch
>   This patch lets aptitude allows Y*/y*/N*/n* also for Yes/No prompt
>   in addition to the translated Yes/No.
>   I think this is better patch than later one.
>   One problem I can imagine is that this check may go to failure
>   if local language means "Y*" for No or "N*" for Yes, but it will be
>   very rare and I didn't see it in current po files.

It seems to be a little bit confusing that users can go ahead by
inputting "Y" although aptitude asks users to input "はい (Y)".  Also,
aptitude wants to make confirmation here by forcing users to input
some longer strings instead of forcing to press just one key.  So, I
consider the latter to be a better workaround.

> - - japo-yesno.patch
>   This patch reverts Yes/No translation of Japanese po file.
>   If you Daniel won't touch the code, please apply this one.
>   (But you'll lose a chance to close #475802 :) )

Since it's frozen for lenny now, I prefer this "translation
workaround" (Actually, we had resolved similar Y/N prompt issue
(#401598) by changing translations likewise under the freeze for
etch...).  "Yes" and "No" can be left untranslated as most of Japanese
can understand what they mean.


This issue is a little bit complex since "Yes" and "No" messages are
used in two ways: as dialog messages on cwidget side and as
confirmation messages on aptitude side.  Since dialogs work good, I
propose a solution to add another string for confirmation input and
allot one role to one message like this:

- _("Yes"), _("No"): strings displayed on dialogs (coded on cwidget
  side).  _("yes_key") and _("no_key") coded on aptitude side are also
  used for keyboard operations.  CJK translators can translate "Yes"
  and "No" to messages with their CJK characters and specify "y" and
  "n" to keyboard operations.

- _("YES"), _("NO"): string for confirmation (coded on aptitude side).
  CJK translators may well have to make these translations only have
  ASCII characters so that users can input these messages correctly
  without input methods.

However, it's a post-lenny solution, IMHO.

Many thanks,

-nori

Reply via email to