#: autorun.cc:531 #, c-format msgid "" "%s-%s -- the CD-ROM mounter for the lazy user\n" "\n" "Command strings are parsed and %%P%% is replaced by the mountpoint path.\n" "%%D%% is replaced by the device path. After that the command string will \n" "be executed using /bin/sh -c \"command string\".\n" "Copyright (c) 1998-2002 Harald Hoyer (Harald.Hoyer).\n" "Copyright (c) 1999-2002 Red Hat, Inc.\n" "\n" "%s comes with ABSOLUTELY NO WARRANTY and is free software, covered\n" "by the GNU General Public License, and you are welcome to change it\n" "and/or distribute copies of it under certain conditions described by the\n" "file COPYING coming with the source code." I don't think the ^K before the copyright line should be there. Or should it?
^K should be there... libc info page for argp: A two part documentation string (in the variable DOC), which allows documentation both before and after the options; the two parts of DOC are separated by a vertical-tab character ('\v', or '\013'). In the source code there is the string "\v", but for the .po file generation, it seemed to be translated..
In any case, placing this type of control characters inside messages marked for gettext translation is very broken. It's easy to miss this type of control character, it's easy to "translate" it into something else, and there's no point in having this control character marked for translation in the first place, since it presumably shouldn't be translated per se. My proposed solution is to split this message into several smaller ones (one per paragraph), which wouldn't just make this large message easier to translate but also would allow the control character to be moved outside of the gettext call.
It could be tricky to split this message into smaller parts since it probably is a static, compile-time assigned structure. But it would help the translator if a comment mentioned that the ^K is indeed intentional and should be kept at that position. There is some way to format comments so that gettext forwards them to the po files; I keep forgetting the details though.
though not critical, I will change this in the next version and keep that in mind...
fixed in 3.5