Index: [Article Count Order] [Thread]

Date:  Wed, 5 Dec 2007 13:50:19 +0100
From:  Michael Stauber <bq (at mark) solarspeed.net>
Subject:  [coba-e:11362] Re: Translating BlueQuartz problems
To:  coba-e (at mark) bluequartz.org
Message-Id:  <200712051350.20072.bq (at mark) solarspeed.net>
In-Reply-To:  <4755607D.1000801 (at mark) enavn.com>
References:  <4753E4A3.5030909 (at mark) enavn.com> <87024F6F-1A87-4B26-8060-E49735D03FAB (at mark) iweb.dk> <4755607D.1000801 (at mark) enavn.com>
X-Mail-Count: 11362

Hi Jes,

> I see, why are the .po files supplied by Solarspeed not named f.ex,
> base-user.po ? All of them are named without base-?

Because that's how they're named in the BlueQuartz SVN. The "base-" namepart 
gets added when the RPMs are built from the sources through "make clean; 
make; make rpm".

> You might get error like this:
> msgfmt: cce.po: warning: Charset "CHARSET" is not a portable encoding name.
>  Message conversion to user's charset might not work.

That's why your umlauts don't show as the encoding (po -> mo) isn't done in a 
fashion that support these charsets. "msgfmt xxx.po -o xxx.mo" is just the 
most basic way of doing that and/or the po files must have "utf-8 
quoted-printable" as Rene pointed out.

The guide that I posted to the list a few weeks ago is just a very basic draft 
that doesn't cover all the involved nuts and bolts. Once the language files 
are incorporated into BlueQuartz we'll have to do some cleaning in regards to 
the used charsets. 

For that part it therefore would be the best if you leave the final 
implementation of the language files into the code to the BlueQuartz team. 

Sure, for testing purpose it would of course be nice if you could see your 
translation in action to check out if everything looks right. But it ain't 
that trivial to make it happen on the fly.

-- 
With best regards,

Michael Stauber