Comment not extracted to po file

tely, the comment is not picked up by xgettext, apparently because it is before the "if" line. If you would move the comment below that line, your nice message would be included in the po files immediately available for all us translators!

Re: Comment not extracted to po file

Pádraig Brady writes: > Göran, do you want me to update your email address in the THANKS also > from goe...@uddeborg.pp.se to goe...@uddeborg.se Yes please. The pp-address is no longer active, so that would be a good idea. ___ Bug-coreutils mailing li

Composing sentences makes them hard to translate

In the macro _STRTOL_ERROR in lib/xstrtol.h contains strings like "invalid %s `%s'" where the first %s is some kind of object, different for different calls. This is problematic to translate, since the translation of "invalid" would have different forms dependent on what the object is. In gen

Re: Composing sentences makes them hard to translate

Paul Eggert writes: > True, but how would we fix it? Wouldn't it be possible to enumerate the objects, just as you do for the errors? That is, you would call STRTOL_FATAL_ERROR (spec, block_size, e); where "block_size" is a value in an enumeration type defined in xstrtol.h similar to strtol

[bug #22121] chcon help output refers to lchown system call

URL: Summary: chcon help output refers to lchown system call Project: GNU Core Utilities Submitted by: goeran Submitted on: fredag 2008-01-25 den 21:35 Category: None

[bug #22121] chcon help output refers to lchown system call

Follow-up Comment #2, bug #22121 (project coreutils): Eh? You say that the problem does NOT affect current coreutils. But then you show an example that HAS the bug. What am I missing? In case I wasn't clear: my point was that referring to the system call "lchown" is wrong. chcon will not use

bug#11117: Suggestion to mark the the arrow for translation

When printing a symbolic link in ls, the target of the link is printed like this: if (f->linkname) { DIRED_FPUTS_LITERAL (" -> ", stdout); print_name_with_quoting (f, true, NULL, (p - buf) + w + 4); I would suggest marking the arrow for translation. DI

bug#11117: Suggestion to mark the the arrow for translation

Paul Eggert: > Also, POSIX requires that 'ls' use '->', I was going to reply something about POSIXLY_CORRECT, but it seems I was too late for the debate. I guess we'll have to live with the ASCII art.

bug#11471: Message incorrectly marked as c-format

This message in the 8.17 message file is written using fputs(), but it is anyway marked as c-format. This is a problem since the % sign in the description of --goal is taken as a formatting directive (of an unsigned int written in octal, with the "space" flag). This causes problems when translati

bug#11470: bug in 8.17 pot file

A possibly more general fix would be to tell xgettext that fputs' argument is not c-format. That would catch all uses of fputs. Something like this: --- po/Makevars~2012-05-10 11:05:30.0 +0200 +++ po/Makevars 2012-05-17 20:06:13.0 +0200 @@ -18,6 +18,7 @@ --flag=asprintf:

bug#11470: bug in 8.17 pot file

Pádraig Brady: > Why does xgettext even think fputs takes a printf format? I don't think it does. I think it doesn't know anything about fputs at all, so it tries to guess. If there is something that looks like a printf directive in the message, it is guessed to be c-format, otherwise not. In a

bug#13665: Question about the translation of double_to_human

I started the translation of coreutils 8.20-pre2 which just arrived via the Translation Project. I got a bit uncertain about messages like: msgid "" "simple_strtod_human:\n" " input string: '%s'\n" " locale decimal-point: '%s'\n" and msgid "double_to_human:\n" Is "simple_

bug#13665: closed (Re: bug#13665: Question about the translation of double_to_human)

Thanks!

bug#16838: Confusing localization of seq

It seems the input arguments of "seq" are not localized, but the output is. I was surprised to find this, and thought I'd ask here if it is an intentional decision. More specifically, I'm using the Swedish locale, where the radix character is a comma. The arguments to "seq" does not accept a com

Inconsistent help message

In the message file for coreutils 4.5.8, there is a message: #: src/stat.c:703 msgid "" " %D Device number in hex\n" " %d Device number in decimal\n" " %F File type\n" " %f raw mode in hex\n" " %G Group name of owner\n" " %g Group ID of owner\n" The lower case "r" in the descrip

Wrong mailing list mentioned in README file.

The README file which comes with coreutils 4.5.8 tells me to send bug reports to [EMAIL PROTECTED] But I've been told this address, [EMAIL PROTECTED], is the appropriate place to use. So the README file needs updating. ___ Bug-coreutils mailing list [

Some mistakes in translatiable strings

While translating coreutils 5.1.0 to Swedish I came across these: #: src/chmod.c:171 src/chown-core.c:193 src/du.c:345 #, c-format msgid "%s" Marking this for translation seems a bit overambitious. It's not much I can do about it, I believe. :-) #: src/ptx.c:38 msgid "F. Pin

bug#18540: Sorting bug?

I discovered a behaviour of "sort" that looks like a bug to me. When one key in the input is an initial part of another key, the shorter key is sorted first if the key is all there is on the line. But if there are other fields too, not included in the key, the order changes. That is true even wi

bug#18540: closed (Re: bug#18540: Sorting bug?)

Drats! I felt so proud after the last paragraph of your first comment! :-) But I've filed https://bugzilla.redhat.com/show_bug.cgi?id=1146185 (I'm also using Fedora).

bug#22686: An empty string marked for translation

On line 955 of src/stty.c there is an empty string marked for translation. fputs (_("\ "), stdout); This might actually be harmful. Po files use the translation of the empty string as a header. So depending on the gettext implementation, it might be replaced by a header which I'm

bug#22686: closed (Re: bug#22686: An empty string marked for translation)

> bug introduced in coreutils-8.24 Already in 8.24? Right, it does happen to my system coreutils (Fedora 23). I assumed it was a new mistake, so I never checked that. (And it shows that gettext does not guard aginst it.) But good to have it fixed either way. :-)

bug#69995: Untranslatable string

While translating the new version of coreutils to Swedish, I came across this code from the end of chown-core.h: printf (_("\ --from=CURRENT_OWNER:CURRENT_GROUP\n\ change the %sgroup of each file only if\n\ its current owner and/or group ma

bug#74653: tail --follow=name doesn't exit when using inotify and the file is moved

When using "tail --follow=name", but without "--retry", on a file supporting inotify, the command doesn't finish if the file is moved to a new name. Repeat this way on a local filesystem: echo apa > apa tail --follow=name apa & mv apa bepa "tail" will print an error message saying "N

bug#74653: closed (Re: bug#74653: tail --follow=name doesn't exit when using inotify and the file is moved)

Thank you for a quick follow up and prompt fix of this issue!