Hmmm... there was a new greek translation:

#, c-format
msgid "Y"
msgstr "Y-ΝΑΙ"

#, c-format
msgid "N"
msgstr "N-ΟΧΙ"

I have no idea what the "-NAI" and "-OXI" bit is but that seems to be the issue.

Try using "LANG=C pacman ..." for the mean time.

NAI=yes
OXI=no
I tried all possible keyboard layouts, uppercase and lowercase- no dice.
OK, waiting for a fix. Thanks.

So what should the signle letter abbreviations be? Something like this?

#, c-format
msgid "Y"
msgstr "N"

#, c-format
msgid "N"
msgstr "O"

Yes, N and O looks the most logical solution.

Now it works only when I put "Y-ΝΑΙ" instead of yes, with written Y in latin an NAI written in Greek.

Ν and O should be just fine, I think.

This is the patch I propose. Do the upper/lower case answers look fine?

That's also the change I would propose. And yeah I also hope the case-insensitive comparisons will work right.

Some quick tests with tr on the command line don't look good:
$ echo "NO" | LANG=el_GR.UTF-8 tr "[:upper:]" "[:lower:]"
no
$ echo "νό" | LANG=el_GR.UTF-8 tr "[:lower:]" "[:upper:]"
νό

@Dan: tr was not utf8 aware (at least not for the greek segment) a few months ago and it seems it still isn't.
This -------------
#include <stdio.h>
#include <strings.h>
int main(void) {
if (!strcasecmp("ν", "Ν")) {
printf("match\n");
} else {
printf("no match\n");
}
}
------- yields a 'no match' too.

I fixed my .po and generated a new .mo to test it and it works, partially. It's not case insensitive. So, until glibc gets fixed, we could either leave these untranslated (and save ourselves a layout switch) or demand from users to observe the letter's case after they switch the keyboard layout.

If you choose the latter, it would be better to substitute msgstr "[Ν/ό]" with msgstr "[Ν/ο]", since the former requires 2 keystrokes, the first one for the accent (though any character except 'Ν' would abort).

Which road do other non-ascii users follow?

Chinese, Kazakh, Russian, and Ukrainian all leave Y/N untranslated. Turkish translates, although the translations appear to be latin/ascii characters.

I suggest then we do the same, there's little visual gain translating these compared to the fuss it creates.

The patch on my working branch now uses Y/n/y/N's