This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Req: Disable I18N/L10N translationforgcc-print-search-dirsoutput.
Ishikawa <ishikawa@yk.rim.or.jp> writes:
> 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.)
Ugh, that is a bad example. Yes, the only way that could work is if
the string holding the day gets translated separately. The only thing
that %n$... notation does is allow you to insert formatted arguments
in a different order than they appeared in the call to printf.
>> > 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.)
Take a look at the contents of the gcc/po directory. gcc.pot is the
translation template file, which contains a complete list of all
strings subject to translation. Files such as ja.po contain
translations, in a human-readable form. The exgettext program is used
(in conjunction with GNU xgettext) to generate gcc.pot from the
sources.
You may also find it helpful to read gcc/ABOUT-NLS and gcc/ABOUT-GCC-NLS.
> 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.
Ah, I see now.
Most places where sentence fragments are translated, that's a bug,
because as you say it doesn't give enough information for translators
to go on. However, there are places where there isn't much of an
alternative. One thing that can be done is put comments immediately
before such strings, in the source code, explaining what is going on.
xgettext will copy those comments into the .pot file.
We'll be happy to take patches that improve translation.
zw