[Resending because it does not seem to have reached all of its
destinations. Sorry if this is a duplicate.]
Hello Theodore,
Op 14-08-2017 om 04:58 schreef Theodore Ts'o:
Unfortunately, a recently change which I made to make things clearer
about the default answer for yes/no question is causing a translation
to go fuzzy, which means gettext skips printing it --- and this causes
a very nasty user experience, since we fall back to the English
message, but if the language is using a different characters for
yes/no, the user will type a english character and get the wrong
result. As a result, I've checked in a change to fix this issue (as I
feel it's urgent) and will be spinning a Debian release to fix this
issue.
Your solution is effective, but... goes a bit too far -- see below.
The problem only occurs because several translators have not heeded
the advice about translating yes/no questions: make sure that also
the English letters are accepted. The Polish, Swedish, and Vietnamese
translators have done this right: in the translation for "yY" they have
put not only the letters for Yes in their language, but also the ones
for English. So the translation of the "yY" msgid in for example
Polish is "tTyY". So a better solution would be to add "yY" to all
the translations of "yY".
But you could do one step better. Leaving the PO files entirely alone,
any e2fsprogs util could, when asking a question and taking one keystroke
for an answer, after checking whether the keystroke is in the translations
for the "yY" or "nN" or "aA" strings, and not finding any match -- then,
instead of assuming , it could check whether the keystroke is maybe
"y" or "Y" (untranslated), and if so, assume that the user means .
This would solve the problem no matter what translators do and no matter
whether msgstrs go fuzzy in the future.
The thing that goes a bit too far, as referred to above:
-#, fuzzy, c-format
+#, c-format
msgid "Proceed anyway (or wait %d seconds) ? (y,N) "
-msgstr "Jalankan saja? (y,n) "
+msgstr "Jalankan saja? (y,N) "
This causes a mistranslation -- the "(or wait %d seconds)" is dropped.
This is because the above "fuzzy" was never translated by any translator
but is simply what msgmerge has filled in because of similarity with
another msgid.
What's more, 'msgfmt -cv' will report an error for the above msgstr,
so your solution will fail for a couple of languages.
Regards,
Benno
