[Freeciv-Dev] Re: gettext 0.10.38

[Gaute B Strokkenes <gs234@xxxxxxxxx>]

This is a (slightly re-edited) re-send of a message that was
originally a private reply to Thue.  I'm forwarding it here at his
request.

On Sat, 16 Jun 2001, thue@xxxxxxx wrote:
> Could you point out those kludges that are now unneccesary with
> gettext 0.10.38
 
I'm not that certain anymore.  One issue is that if you configure
current Freeciv on a box with glibc 2.1 and gettext 0.10.35 (say)
installed, then it will use the gettext & associated tools that are
already installed.  So the workarounds might still be required, to
cater for this case.  As you might have already realised, the docs are
not too clear on how this is supposed to work.  It is also not clear
what you are supposed to do if you wish to take advantage of the
features of GNU gettext (e.g. plural support).  This is highly
annoying.

Gettext used to have a bug in which msgmerge would mangle PO files
with certain encodings.  When refilling paragraphs, it would sometimes
insert a newline between the constituent bytes of a multibyte
character, with disastrous results.  Therefore our configure.in script
contains a snippet which modifies the appropriate makefile so that
msgmerge is run with a parameter that disables paragraph refilling.

Our configure.in also contains this:

  dnl Why doesn't AM_GNU_GETTEXT set LIBS appropriately 
  dnl when -lintl is required??
  if test "$gt_cv_func_gettext_libintl" = "yes"; then
      LIBS="-lintl  $LIBS"
  fi

I haven't tried removing it, but you get the feeling that this is
something that should have been taken care of already.  I consider it
very suspicious.

Gettext 0.10.36+ makes use of the encoding information in the header
entry of each PO file to convert text from one encoding to another on
the fly.  Unfortunately, all of these entries are marked as fuzzy in
the Freeciv PO files, so that they will not be included in the MO
files.  I enquired about this before, and it was claimed and
subsequently demonstrated that strange things would occur under
certain circumstances if the fuzzy marker was removed from these
strings.  Unfortunately, no one on the mailing list seemed to know
why.  It would be a good thing to find out if this mangling still
occurs, and if not remove the fuzzy marker again.  [As a side issue,
this information is missing or incorrect in several of the PO files,
but this is easily corrected.]

I guess I should add here that I have spent some considerable time
sifting through the mailing list archives and the web in general
trying to find any details concerning this bug, apart from its
existence.  I don't see any way to deal with this other than appealing
to the people who were around at the time to provide details if we are
to nail this bug for good.

Freeciv also has its own PO file syntax checker,
freeciv/po/check_po.pl .  I do not remember offhand, but I think the
standard checking done by msgmerge (I think) is more comprehensive
(check_po.pl does not understand a double %% (i.e. and escaped %) for
instance.  I could find no explanation for why this is required, other
than a remark in part of the gettext / i18n guidelines on
www.freeciv.org stating that the default gettext checker complains
about things which are not errors.  I note that the fact that the
header entry is marked fuzzy is considered a fatal error by msgmerge.
check_po.pl was written by DWP, so with luck we might be able to
extract the required information from him.

Apart from that there are a number of things in configure.in that are
supposed to tweak the arguments given to xgettext etc. slightly.  We
may be able to get rid of them now, but I don't think so.

-- 
Big Gaute                               http://www.srcf.ucam.org/~gs234/
LOOK!!!  I'm WALKING in my SLEEP again!!