[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Translation for aptitude



Hi,

I have two issues about translation for aptitude.  I figure I'll ask
here first, and if most translators agree with me, I'll file bugs
against aptitude.  They are mostly related to CJK languages, but I
suppose many other non-Latin languages would be interested as well,
especially issue #1.


1. The following two entries REALLY need comments for translators:

#: src/ui.cc:2690 src/vscreen/vscreen.cc:724
msgid "yes_key"
msgstr ""

#: src/ui.cc:2691 src/vscreen/vscreen.cc:725
msgid "no_key"
msgstr ""

These are the shortcut keys you need to press when answering a Yes/No
question.  While the aptitude developers care i18n enough to give the
possibility to localize this shortcut key, without a comment translators
won't know they are supposed to translate them to a single key that
stands for yes/no (in English, they'll be "y" and "n").  These shortcut
keys are used quite often, for example, in the dialog of quitting
aptitude.

This is also the cause of bug #338056.  The zh_TW translation is just
literally "the yes key", and it seems aptitude just take the first
character of the translated string.

I've done a grep in the po/ directory, and fewer that half of the
languages have one-character translations (although many others just
have it untranslated, so that should give y/n).


2. Can the developers somehow separate the following strings?

#: src/cmdline/cmdline_prompt.cc:413 src/vscreen/vs_util.cc:177
#: src/vscreen/vs_util.cc:215
msgid "Yes"
msgstr ""

#: src/cmdline/cmdline_prompt.cc:413 src/vscreen/vs_util.cc:178
#: src/vscreen/vs_util.cc:216
msgid "No"
msgstr ""

These are actually three Yes/No pairs.  The two for
src/vscreen/vs_util.cc:178 and src/vscreen/vs_util.cc:216 are strings
shown to users, and we zh_CN translators want to translate them.  On the
other hand, the pair for src/cmdline/cmdline_prompt.cc:413 is both for
display AND to match the user's input.  It goes like
    Do you want to ignore this warning and proceed anyway?
    To continue, enter "Yes"; to abort, enter "No": 
and the user need to type in the string that match the Yes/No
translation here.

And a Chinese user recently complained in our mailing list that it would
make much more sense for the user to just type the English word "Yes" or
"No" to answer, instead of having to type Chinese (or worse, rely on
copy and paste as inputting Chinese is harder than displaying Chinese),
and most of us agree.  The problem is that if we change this
translation, the two other Yes/No pairs got displayed in the ncurses
user interface will go back to English as well, and we want to avoid
that.

So in brief the request is to separate the strings that are display-only
and that are both for display and input.  For Chinese, we translators
want to show localize messages but generally try to avoid enforcing the
user to input Chinese, as it sometimes causes big inconvenience.


So what does the fellow translators think?

Ming
2005.11.08

Attachment: signature.asc
Description: Digital signature


Reply to: