[Printing-architecture] [Gimp-print-devel] Common Printing Dialog: PPD extension specs updated

Till Kamppeter till.kamppeter at gmail.com
Mon Aug 4 15:41:49 PDT 2008



Roger Leigh wrote:
> Well, the problem here is simple.  The program fails as expected
> because you *don't have a valid locale* for the testcase to use:
> 
>   // Initial setlocale call must succeed, or else we're still in a C
>   // locale, and gettext won't translate at all.
>   const char *l1 = setlocale(LC_ALL, "en_GB.ISO-8859-1");
> 
> Do you have a valid en_GB.ISO-8859-1 locale?  If not, then change this
> to a different locale (e.g. "" to use your en_US locale), or generate
> the locale.  To do the test as I requested above however, you *must*
> start off in a non-UTF-8 locale to verify that the UTF-8 transcoding
> is working properly, or else the test is not useful, though it will
> verify we can do lookups while using "invalid" locales.
> 
> What results do you get if you fix this?

Now the results are better.

I did

sudo locale-gen en_US.ISO-8859-15
    (locale must be listed in /usr/share/i18n/SUPPORTED)

edited gettext-test.c to have a line

const char *l1 = setlocale(LC_ALL, "en_US.ISO-8859-15");

and all the rest like before.

Then I get as screen output:

setlocale1: en_US.ISO-8859-15
setlocale2: (null)
setlocale3: en_US.ISO-8859-15
domain: /home/till/gutenprint/cvs/HEAD/x
codset (null)->UTF-8
selected-domain: gutenprint
lookup: Foto aus fünf Farben gemischt
dlookup: Foto aus fünf Farben gemischt

So in this case translations work and encoding works. st.out is 
attached. So this means that the system needs at least one non-C locale 
and the PPD generator has to find and select it.

    Till


More information about the Printing-architecture mailing list