Re: Req: Disable I18N/L10N translation forgcc-print-search-dirsoutput.

[Ishikawa <ishikawa at yk dot rim dot or dot jp>]

Zack Weinberg wrote:
> 
> Ishikawa <ishikawa@yk.rim.or.jp> writes:
> 
> >> LC_MESSAGES=C should disable translation without any other effect.
> >> (Not all systems support this variable, however.)
> >
> > Thank you for the info. Hmm, I am not sure which system supports
> > LC_MESSAGES and which doesn't.
> 
> I'm not sure myself.  You can grep for it in /usr/include/locale.h -
> that is at least suggestive.
> 
> LC_MESSAGES appears in the 1997 and 2001 revisions of the Single Unix
> Standard, so it should be fairly common.  See respectively
> <http://www.opengroup.org/onlinepubs/007908799/xbd/envvar.html>,
> <http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html>.
> 
> >> For both these things, patches are welcome.  You are probably in a
> >> better position to write them than I am, since you have firsthand
> >> experience with the side effects of I18N/L10N.
> >
	...
> Please work from CVS HEAD instead.  There are instructions for this at
> <http://gcc.gnu.org/cvs.html>.  You should also read
> <http://gcc.gnu.org/contribute.html>.

I will download the CVS then and work on it.

> If you are interested in I18N projects, another worthwhile improvement
> would be to add support for %n$s notation to diagnostic.c.  See
> <http://www.opengroup.org/onlinepubs/007904975/functions/printf.html> for
> details of how this is supposed to work.
>
> I'll be happy to answer questions as you have them.

Thank you for the offer.
I have looked at the opengroup URL, but I think
I need to re-read and should understand the german date example.
(Not so sure why suddenly the "sunday" becomes German equivalent.
Maybe the day of the name string is changed BEFORE being passed
to printf. Then I can understand the semantics.)

> > (In the meantime, I will see if I can find the cause of the
> > "slowness" of recent gcc if possible.)
> 
> We'd be glad for any help you can provide on this, too.

Thank you. I posted a gprof info to the mailing list
and Andrew Pinski followed-up with an interesting info, too.
I have no idea if his patch  is in CVS or not.

> > Having a list of strings seem to require the use of xgettext() [
> > xstring(s) doesn't seem to exist on Debian GNU/Linux) and a heavy
> > massaging afterward and I am not sure how to go about it. So I will
> > not attempt it as of now.
> 
> I do not understand the question here...

I was thinking of extracting the string constant
so that we can take a look at the (possible) output coming
from GCC. (Making a list of it, sort of.)
It used to be that there was this tool called xstr/xstring or whatever
that is a very underpowered xgettext, so to speak.
This tool helped us in extracting such string literals for further
I18N/L10N work.
I looked at gcc 3.3 code, and since it has been already given some
I18N/L10N work, the part of string that is translated is given
by _("example") macro. (Ie. `_' is a macro name.)
This means that in order to re-construct the origianl ASCII English
string, I may have to do something about de-macrofy _("example") part
when
such translation is done as part of longer outut string, and/or
figure out WHERE such translation is done in WHAT output.
(For example, "install", "library", "program" that appears
as part of -print-search-dirs must be explained that
they appear as part of -print-search-dirs output. Otherwise,
such list of strings won't have much meaning.
This seems to be a lot of work and so I think I will
not attempt this at this time. 


-- 
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */