On Wed, Feb 18, 2009 at 7:06 PM, Raymond Toy <raymond.toy at stericsson.com> wrote:
> Andrej Vodopivec wrote:
>>> And, at least for me on a Solaris box, xgettext doesn't recognize the
>>> --language option. There may be other problems with portability of
>>> xgettext. I've never used it before.
>>>
>>
>> The language option is not really required because the file type is
>> guessed from the file ending. But if xgettext on Solaris does not
>> recognize lisp files this is a problem. We could have maxima.pot in
>>
> The version of xgettext on Solaris doesn't recognize Lisp files. I
> supposed I could go get GNU xgettext and install that myself, but that's
> always a pain to do.
>> cvs and update it manually on a system with a GNU xgettext. Maybe we
>> should also add --with-xgettext option to configure script.
>>
>>
> If we decide not to have prebuilt versions of maxima.pot, then a
> --with-xgettext (or --without-xgettext) option for configure is
> acceptable to me.
My current plan is not to include maxima.pot anywhere. We will have
*.po files in cvs and *.po and *.mo files in the source and binary
packages.
When compiling from source packages, we will just install the *.mo
files. When compiling from cvs, the msgfmt program will be required,
but this should be OK. Only translators will actually need to use
xgettext to manually update the *.po files.
> On a different note, the current CVS code won't build because
> locale/Makefile has a shell command to run make on TRANSLATIONS. But
> TRANSLATIONS is empty and Solaris's /bin/sh chokes on the form "for t in
> ; do make $t.mo; done".
OK, I will disable updating until we actually have some translations.
Andrej