Re: Bison i18n patches installed

[Bruno Haible]

Paul Eggert wrote:
> > - You refer to the glibc documentation where I referred to ABOUT-NLS.
> >   ABOUT-NLS is platform independent. Is your problem with ABOUT-NLS that
> >   it is not installed as an info file?
>
> Yes; I want a reference that readers can easily follow, since I'm
> assuming they're reading info (or a web page, or a PDF document, or
> whatever).  If there's a better such reference than the glibc manual
> please let me now.

Yes, could you please add a reference to node 'Users' in gettext.info as
primary reference? It doesn't yet contain the complete info from ABOUT-NLS,
but I'm adding it before gettext-0.15. You can leave glibc as secondary
reference, I don't mind.

> > - In runtime-po/ it would make sense to save the diff between the normal
> >   po/Makefile.in.in and this one, and enhance the bootstrap script to
> >   apply these diffs. This should make the migration to gettext-0.15 etc.
> >   smoother, without introducing inconsistencies (i.e. without risking
> >   use of a 0.15 gettext.m4 with a 0.14.5 Makefile.in.in).
>
> I've been thinking about that too, but I have a more radical proposal
> (A): simply revert to the standard Makefile.in.in (so that we don't
> have to maintain any difference), and place the old translation
> strings, whatever they are, in some file maintained by hand.
>
> A problem with the current approach is that translation strings
> survive even when they shouldn't.  For example, if I misspell a
> diagnostic, the misspelling will accumulate into the .pot file even
> though I correct the misspelling before the next official release.
> This problem is already starting to happen, because I see that the
> formats in the current diagnostics aren't quite right for 64-bit
> machines (once we fix some other deficiencies), and I'd like to fix
> this before Bison 2.1 comes out.

You're right. I didn't think at that. Actually the way I maintain
archive.tar.gz in gettext in similar, with a special modification done
by hand before "make dist".

> To help implement this, can a .pot file be in POTFILES.in?  That is,
> would it work if runtime-po/POTFILES.in looked like this?
>
> data/yacc.c
> runtime-po/bison-2.1.pot
> runtime-po/bison-2.2.pot

Yes, absolutely, this will work. You just need to add runtime-po/bison-2.?.pot
to the toplevel Makefile.am's EXTRA_DIST.

Actually, among runtime-po/bison-2.1.pot and runtime-po/bison-2.2.pot you
only need the last one. (Because it's supposed to contain all messages
from the earlier releases.)

> I installed the following patch.
> Please let me know if you see any problems with it.
> 2005-07-13  Paul Eggert  <address@hidden>
>
>       * PACKAGING: New file, suggested by Bruno Haible and taken from
>       similar wording in gettext's PACKAGING file.
>       * NEWS: Mention PACKAGING.
>       * Makefile.am (EXTRA_DIST): Add PACKAGING.

Looks all fine to me, except for a typo in PACKAGING:
"to in the bison package".

Bruno