[pacman-dev] [PATCH] Allow translation of makepkg y/n question
Signed-off-by: Allan McRae <allan@archlinux.org> --- scripts/makepkg.sh.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 4edb967..3d1430f 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1216,7 +1216,7 @@ if [ "$CLEANCACHE" = "1" ]; then echo -n "$(gettext " Are you sure you wish to do this? [Y/n] ")" read answer answer=$(echo $answer | tr '[:upper:]' '[:lower:]') - if [ "$answer" = "yes" -o "$answer" = "y" ]; then + if [ "$answer" = "$(gettext "yes")" -o "$answer" = "$(gettext "y")" ]; then rm "$SRCDEST"/* if [ $? -ne 0 ]; then error "$(gettext "Problem removing files; you may not have correct permissions in %s")" "$SRCDEST" -- 1.5.6.3
Well, Xavier beat me to it.... so ignore this thread!
Allan McRae wrote:
Well, Xavier beat me to it.... so ignore this thread!
Waoh, two different versions of the same patch in 4 min interval, that was pretty amazing :) Actually, if we combine our two patches, by not editing the big string with the Y/n part like you did, and by reusing the already translated YES and Y strings like I did, maybe we can avoid changing the .po files. But then, we need to check that everyone did translate the [Y/n] part if that string, so exactly the opposite of what I was doing until now : making sure everyone kept it intact. So in any cases, it looks like we will need to do some manual checking and fixing of the translations. So what could be done is once every translation has been updated, my patch is merged, the .po file are regenerated and each one fixed manually. This should be easy to do.
On Fri, Jul 18, 2008 at 1:41 AM, Allan McRae <allan@archlinux.org> wrote:
answer=$(echo $answer | tr '[:upper:]' '[:lower:]')
Random unrelated point - can this line possibly cause issues similar to the Turkish I/i thing?
Aaron Griffin wrote:
On Fri, Jul 18, 2008 at 1:41 AM, Allan McRae <allan@archlinux.org> wrote:
answer=$(echo $answer | tr '[:upper:]' '[:lower:]')
Random unrelated point - can this line possibly cause issues similar to the Turkish I/i thing?
Maybe, what is the Turkish I/i thing? (Maybe its another language because I think Y=E, n=h in turkish).
On Fri, Jul 18, 2008 at 10:39 AM, Allan McRae <allan@archlinux.org> wrote:
Aaron Griffin wrote:
On Fri, Jul 18, 2008 at 1:41 AM, Allan McRae <allan@archlinux.org> wrote:
answer=$(echo $answer | tr '[:upper:]' '[:lower:]')
Random unrelated point - can this line possibly cause issues similar to the Turkish I/i thing?
Maybe, what is the Turkish I/i thing? (Maybe its another language because I think Y=E, n=h in turkish).
Turkish has two I's. Just remember that the 'dot' moves with it. So i capitalizes to I with a dot over it, and I lowercases to an i without the dot over it. It causes all sorts of issues with "to upper" type comparisons. I was just wondering if this sort of issue hits any other languages. Because we ran into this with config file parsing, I always get scared when I see upper/lower based compares in a translated context. Just being thourough
On Fri, Jul 18, 2008 at 5:27 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Fri, Jul 18, 2008 at 1:41 AM, Allan McRae <allan@archlinux.org> wrote:
answer=$(echo $answer | tr '[:upper:]' '[:lower:]')
Random unrelated point - can this line possibly cause issues similar to the Turkish I/i thing?
This is a very good point that I never thought about. And since we already have the equivalent code in pacman, pacman is potentially affected too. Since I only heard about problem in Turkish locale, we can just look at the translation of yes/no in turkish : msgid "Y" msgstr "E" msgid "YES" msgstr "EVET" msgid "N" msgstr "H" msgid "NO" msgstr "HAYIR" But now that I think about it, it should not be a problem. Turkish users should be able to write HAYIR in lower case, something like hayir, but without the dot on the i. It is not like the keywords like RootDir which were already written like that in pacman.conf, then converted to upper case and compared to ROOTDIR. So in short, it looks like there is no problem here, after thinking about it.
participants (3)
-
Aaron Griffin
-
Allan McRae
-
Xavier