[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 <No>, it could check whether the keystroke is maybe "y" or "Y" (untranslated), and if so, assume that the user means <Yes>. 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