Re: libintl: stubs or working functions?

[Justin Cormack <justin@specialbusservice.com>]

[-- Attachment #1: Type: text/plain, Size: 1891 bytes --]

On Mar 18, 2015 11:10 PM, <u-wsnj@aetey.se> wrote:
>
> On Tue, Mar 17, 2015 at 11:38:57AM -0400, Rich Felker wrote:
> > > msgid "Permission denied"
> > > msgstr "asdf@# lkjk^& (EPERM)"
> >
> > I'm a bit undecided on this. It's reasonable to ask people reporting
> > bugs to set their locale temporarily to something the project
> > maintainers understand (typically English). It's also pretty easy to
> > grep the .po files or use Google Translate to figure out what the
> > message says.
> >
> > If users with a non-English locale would find those kind of messages
> > helpful and non-obtrusive (is latin text in the middle of non-latin
> > obtrusive? perhaps, depending on font?), I'm not opposed to having
> > them, but I don't think they should be added against the desire of
> > most users out of an interest in making it easier to interpret bug
> > reports for us or for other upstreams.
>
> As an application user I am motivated to be able to report problems as
> exactly as possible.
>
> As a "library user" (either as a packager, application developer,
> support staff or something else) I find it unfortunate/disturbing to
> have to "guess" the actual error name, even when a message is in a well
> known language like English.
>
> This is mostly very easy but sometimes less certain, with less usual
> errors and/or different C libraries which may contain different English
> strings/spellings too.
>
> An error-specific indentifier should IMHO always be present
> in every message, not translated to a "natural" language with the
> intention to be translatable back with more or less pain.
>
> IOW I'd like to always have the canonical errname in the output,
> in English too.
>
> This would make error messages easier and more robust to interpret.
>

Would it make sense for the canonical names to be the output in the C
locale and English if you set an English locale?

Justin

[-- Attachment #2: Type: text/html, Size: 2390 bytes --]