mingw-users

[Mingw-users] Getting rid of xgettext's "CHARSET" warning

[Martin M. <vi...@gm...>]

I have a problem with xgettext. I am not really sure where to ask, this is
the only place somewhat related. Feel free to point me to better place ;)

My problem is that xgettext always spits out this annoying warning:
messages.po: warning: Charset "CHARSET" is not a portable encoding name.
Message conversion to user's charset might not work.

Inside messages file, it sets:
"Content-Type: text/plain; charset=CHARSET\n"

I couldn't find a way to force it set charset directly (or at least shut up
about this warning). There is --from-code option, but according to this link
(
http://stackoverflow.com/questions/1084191/command-or-option-for-the-xgettext-msginit-msgfmt-sequence-for-setting-the-mime),
it only has effect when source contains some non-ASCII character. In every
other case, this option is ignored, "CHARSET" is used, and warning
displayed.

Only workaround might be to place dummy non-ASCII string to every source,
but that's not something I'd consider (also it's discouraged by GNU:
http://www.gnu.org/software/gettext/FAQ.html#nonascii_strings). So, how to
get rid of this warning? Or, at least, where to ask about this problem?

Thanks

Re: [Mingw-users] Getting rid of xgettext's "CHARSET" warning

[Keith M. <kei...@us...>]

On Sunday 10 October 2010 15:59:39 Martin Mocko wrote:
> My problem is that xgettext always spits out this annoying warning:
> messages.po: warning: Charset "CHARSET" is not a portable encoding
> name. Message conversion to user's charset might not work.
>
> Inside messages file, it sets:
> "Content-Type: text/plain; charset=CHARSET\n"

I'm not especially familiar with gettext usage, but aren't you expected 
to replace the place holder 'CHARSET' with an actual encoding name[*], 
such as ASCII, ISO8859-1, UTF8, or similar?

[*] Of course, your choice would not be arbitrary -- it should be the 
actual encoding used for the message file.

-- 
Regards,
Keith.

Re: [Mingw-users] Getting rid of xgettext's "CHARSET" warning

[Martin M. <vi...@gm...>]

On Sun, Oct 10, 2010 at 5:30 PM, Keith Marshall <
kei...@us...> wrote:

> On Sunday 10 October 2010 15:59:39 Martin Mocko wrote:
> > My problem is that xgettext always spits out this annoying warning:
> > messages.po: warning: Charset "CHARSET" is not a portable encoding
> > name. Message conversion to user's charset might not work.
> >
> > Inside messages file, it sets:
> > "Content-Type: text/plain; charset=CHARSET\n"
>
> I'm not especially familiar with gettext usage, but aren't you expected
> to replace the place holder 'CHARSET' with an actual encoding name[*],
> such as ASCII, ISO8859-1, UTF8, or similar?
>
> [*] Of course, your choice would not be arbitrary -- it should be the
> actual encoding used for the message file.
>

>From how I've seen people use it (sed after xgettext) it seems so, and
that's not the problem. But what bothers me is that warning. I use -Wall and
try to make my builds warning-free. This one always pops out, however..

Re: [Mingw-users] Getting rid of xgettext's "CHARSET" warning

[Keith M. <kei...@us...>]

On Sunday 10 October 2010 17:06:44 Martin Mocko wrote:
> > > My problem is that xgettext always spits out this annoying
> > > warning: messages.po: warning: Charset "CHARSET" is not a
> > > portable encoding name. Message conversion to user's charset
> > > might not work.
> > >
> > > Inside messages file, it sets:
> > > "Content-Type: text/plain; charset=CHARSET\n"
> >
> > I'm not especially familiar with gettext usage, but aren't you
> > expected to replace the place holder 'CHARSET' with an actual
> > encoding name[*], such as ASCII, ISO8859-1, UTF8, or similar?
> >
> > [*] Of course, your choice would not be arbitrary -- it should be
> > the actual encoding used for the message file.
> >
> >
>
> From how I've seen people use it (sed after xgettext) it seems so, 
> and that's not the problem. But what bothers me is that warning.

Then, I guess you need to provide a *minimal*, *self-contained*, test 
case, to illustrate the problem.

-- 
Regards,
Keith.

Re: [Mingw-users] Getting rid of xgettext's "CHARSET" warning

[Martin M. <vi...@gm...>]

On Sun, Oct 10, 2010 at 7:03 PM, Keith Marshall <
kei...@us...> wrote:

> Then, I guess you need to provide a *minimal*, *self-contained*, test
> case, to illustrate the problem.
>

While preparing the example, I sorted it out. This warning is only printed
on _subsequent_ calls to xgettext (with -j parameter, join with existing
file), not in the first call which creates output file. That means I have to
replace CHARSET after first xgettext, preferably by processing all sources
within one xgettext command. This is the post-build command I use in
Code::Blocks IDE, should anyone ever encounter this problem and find this
thread:

$(CMD_RM) messages.po
xgettext -C -k_ $(ALL_PROJECT_FILES)
sed --in-place messages.po --expression=s/CHARSET/UTF-8/

By the way, I couldn't find MinGW version of sed anywhere (only MSYS sed,
which is not invoked by Code::Blocks IDE by default), so I used GnuWin32
sed. Is it safe to use MSYS executables outside MSYS shell?

Re: [Mingw-users] Getting rid of xgettext's "CHARSET" warning

[Keith M. <kei...@us...>]

On Sunday 10 October 2010 19:08:56 Martin Mocko wrote:
> > Then, I guess you need to provide a *minimal*, *self-contained*,
> > test case, to illustrate the problem.
>
> While preparing the example, I sorted it out.

That's good.  One of the reasons we encourage reduction of a problem to 
a minimal test case is that exercise of creating it often leads you to 
a solution to the problem.

> By the way, I couldn't find MinGW version of sed anywhere (only MSYS
> sed, which is not invoked by Code::Blocks IDE by default),

Well, we are unlikely to ever distribute sed as anything other than an 
MSYS application.

> so I used GnuWin32 sed.

That is an alternative you may wish to consider; I've never used it 
myself, but have no reason to doubt that it will work for you.

> Is it safe to use MSYS executables outside MSYS shell? 

As long as your MSYS /bin is in $PATH (%PATH%), many of them will work, 
but it isn't a usage scenario which we officially support.  YMMV.

-- 
Regards,
Keith.