On Fri, Aug 15, 2008 at 04:02:03PM +0900, Noritada Kobayashi <[EMAIL
PROTECTED]> was heard to say:
> [#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.
Sorry about that. I thought it would be useful for users to not have
to enter "Yes"/"No", but it looks like I guessed wrong. :-(
I hope I can get one more i18n-related upload of aptitude in, and I
guess I can fix this in that upload once we decide what to do.
> 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.
Which one is the latter? I've lost track.
> > - - 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.
Also, I believe aptitude actually says what it will do if you enter
"Yes", so the user doesn't need to treat it as anything but a magic
string of characters.
> 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.
Hm, yes_key is actually in cwidget, except that aptitude uses it as
well in the particular case that it's showing a minibuffer-style yes/no
prompt. (which it never does by default) That seems wrong -- probably
all the translation should happen in cwidget and aptitude should call a
function in the library to get the translation.
> - _("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.
You mean for the security prompt confirmation, right? I think that
this is the best long-term solution: use different translation keys for
"yes"/"no" when they're being used here. In fact, we could even use
P_() here: P_("Confirm security override|Yes") and
P_("Don't override security|No").
Daniel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
