On Thu, 2012-01-05 at 19:29 +0100, Sebastian Pipping wrote:
> > I confess I'm not an expert in i18n, so it's quite possible I'm making
> > something out of nothing very important here. But I think it's worth
> > investigating. It's possible, for example, that it's sufficient to
> > "translate" the prefix string itself if everything is printed in one
> > invocation.
>
> I see. I'm all for a proper solution to that.
>
> With output like "make[4]: foo failed" pushing full control into
> translation strings seems troublesome to me. Imagine
>
> "%s[%u]: foo failed"
> "%s[%u]: bar failed"
> ...
>
> in the translation database. It doesn't get much better with
>
> "make[%u]: foo failed"
> "make[%u]: bar failed"
> ...
>
> What do you think about specify a reading direction for each supported
> language and making use that information to select from prefix or
> suffix?
What I was trying (very badly... sorry sometimes I type things that make
sense in my head, but nowhere else) to suggest in my paragraph above was
this:
We invoke the output function with an already-translated string:
output (_("some string to print"));
(pseudo code). So if the output needs to go right-to-left, or whatever,
that string is already converted. Now maybe it's sufficient to print
this and all the other stuff (prefix, etc.) using a single printf format
string that _itself_ is translated (so that translators can rearrange it
if they want/need to, particularly for right-to-left output). It would
have to be done all in one invocation of *printf().
I think the above is still not very clear.
What I mean is, instead of voutputf() invoking multiple calls to
fprintf(), we'd need to compute all the strings we needed then invoke a
single fprintf() for each output style where the format string was
translated, something like this:
if (flocp && flocp->filenm)
fprintf (target, _("%s:%lu: %s%s"), flocp->filenm, flocp->lineno,
catchy, output);
else if (makelevel == 0)
fprintf (target, _("%s: %s%s"), program, catchy, output);
etc. Of course we'd need to use vsprintf() or something to turn the
va_list into the "output" string. Now a translator can take that format
string and convert it so that things are generated in a different order
if necessary.
The other thing I wonder about is the hardcoding of ASCII colorized
strings and the start/stop character strings (\033[...). Are there
other methods of colorizing? Should we try to support them? Maybe it's
not worthwhile to try to support generic methods when we have no idea if
they're useful. We can always make changes needed to support them
later.
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
