Wed 06 Apr 2011 11:00:40 PM UTC, comment #10:
> I would prefer to continue to keep .po files in the repository.
OK, I'll commit the changed ones, then (the change in xgettext flags causes the update of po sources during, e.g. `make lang.po-update'; in particular, the msgid that started this thread gets marked as fuzzy, which excludes it from the resulting .mo file, so that running `LC_ALL=ru_RU install-info' no longer causes coredump).
> Sergey, are you involved with the TP as a translator, by any chance?
Yes, I am.
[As a side note, using traditional email is much easier than this tracker. Looks like I am stick in the mud too:))]
|
Wed 06 Apr 2011 10:03:28 PM UTC, comment #9:
I would prefer to continue to keep .po files in the repository. My basic guideline is that I don't want autogen.sh to have do anything over the network, but just use local files. In the past, I had such limited bandwidth there was no realistic option; that's no longer the case, but I still find it much more comprehensible to do it this way. I know it is completely different from the do-everything-possible-at-bootstrap-time approach of coreutils, etc. Just call me a stick in the mud.
Meanwhile, coordinator@tp hasn't answered me yet about the spurious %s's. (It's only been a day or two, though.) Sergey, are you involved with the TP as a translator, by any chance?
|
Wed 06 Apr 2011 09:50:53 PM UTC, comment #8:
Done. While at it, do we really need to keep .po files in the repository? It would be much simpler to get them directly from the TP (e.g. in autogen.sh).
|
Tue 05 Apr 2011 10:52:58 PM UTC, comment #7:
Hi Sergey -- please do fix error() and fatal() (and anything else) to be standard stdarg stuff, instead of the weird K&R varargs-ish approach rms took 20 years ago. fixing makevars would be great too, thanks.
|
Tue 05 Apr 2011 03:08:34 PM UTC, comment #6:
Yes, Patrice, I know. But it is not relevant in this particular case.
|
Tue 05 Apr 2011 10:43:00 AM UTC, comment #5:
I don't know exactly how it fits here, but there are now 2 places for translated strings. In po/ for warning/error messages, and po_document/ for in string document translation. In po_document/ the perl way for gettext stuff is used (it is explained somewhere why it is better like that, in short because the order of the argument may change).
|
Tue 05 Apr 2011 07:09:20 AM UTC, comment #4:
I agree with (1) and (2).
As to (3), gettext is of course not able to handle this.
It is the responsibility of xgettext. And it would have reported an error and refused to create the mo file, if fatal() had been declared as pass-c-format, i.e. had the --flag=fatal:1:pass-c-format option been given in XGETTEXT_OPTIONS in po/Makevars. This is the standard method to prevent such bugs, so it qualifies as a bug in our Makevars. I'll fix this, but there remains a minor point: fatal() is not exactly printf-like, it always takes a second arguments and expects at most one %s specifier in its format string. The same holds true for error(). This makes both functions error-prone: it would suffice to supply a format string with any non-%s printf specifier to make them print garbage in best case and coredump in the worst one.
I would rather redeclare both as (const char *,...). WDYT?
|
Mon 04 Apr 2011 10:52:45 PM UTC, comment #3:
1. There have certainly been other changes to the .po since 2005. But that shouldn't stop us from removing the now-spurious %s.
2. But we maintainers are told in no uncertain terms that changes to translation files should be made through the translation project, not just willy-nilly hacked in. At least we should try. I'll write coordinator@tp.
3. I wonder if gettext can diagnose this situation.
|
Mon 04 Apr 2011 09:21:11 AM UTC, comment #2:
Hi Karl,
if this is the only change to the po file, the %s should simply be removed. AFAICT (my Russian is not the best), the translation is still valid.
Hilmar
|
Sun 03 Apr 2011 06:23:11 PM UTC, comment #1:
Can reproduce with the simpler env LC_ALL=ru_RU install-info.
This is a bug in the Russian translation for install-info. Last updated for 4.7.94 in 2005 :(. The original English for that message (and a subsequent one) does not contain %s (any more), so no argument is passed.
I am cc-ing Oleg Tihonov (the translator, hi Oleg T) and the translation team address in hopes that they can address it. If no answer, I'm not sure what the right thing to do is.
Here is the excerpt from ru.po (the Cyrillic will probably garbled somewhere along the way, but I trust the main point will remain):
#: install-info/install-info.c:2164
msgid "No input file specified; try --help for more information."
msgstr ""
"îÅ ÚÁÄÁÎ ×ÈÏÄÎÏÊ ÆÁÊÌ.\n"
"ðÏÐÒÏÂÕÊÔÅ `%s --help' ÄÌÑ ÐÏÌÕÞÅÎÉÑ ÂÏÌÅÅ ÐÏÄÒÏÂÎÏÇÏ ÏÐÉÓÁÎÉÑ."
#: install-info/install-info.c:2167
msgid "No dir file specified; try --help for more information."
msgstr ""
"îÅ ÚÁÄÁÎ ÆÁÊÌ ËÁÔÁÌÏÇÁ.\n"
"ðÏÐÒÏÂÕÊÔÅ `%s --help' ÄÌÑ ÐÏÌÕÞÅÎÉÑ ÂÏÌÅÅ ÐÏÄÒÏÂÎÏÇÏ ÏÐÉÓÁÎÉÑ."
|
Sat 02 Apr 2011 02:33:10 PM UTC, original submission:
Dear all,
down here in the Debian bug tracking system we got a bug report telling that the help output is a little broken in specific locale settings:
http://bugs.debian.org/595243
<quote>
$ locale
LANG=ru_RU.UTF-8
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL=
$ ginstall-info
install-info: Не задан входной файл.
Попробуйте `(null) --help' для получения более подробного описания.
In Russian locale install-info shows `(null) --help'. It is probably due to printf() call with a null string instead of argv[0]
</quote>
Note: ginstall-info is the name of install-info on Debian.
I tested with the latest code from the CVS, which did not solve the problem.
|