I have integrated the patches and the ja translation upstream.
Some strings have changed in cvs, and the ja file should be 
updated accordingly from the cvs file.

Link to the file in cvs:
http://cvs.savannah.nongnu.org/viewcvs/texi2html/i18n/ja?rev=1.1&root=texi2html&view=auto

Do you plan to release a new texi2html upstream release anytime soon? The
preferred way is to update to an official upstream release instead of
backporting changes to a 1.5 year old texi2html ;-)

I am not the upstream maintainer, I am the main contributor.
I already asked twice for a release... 

Do you want to update the ja translations before the release?

Definitely. Maybe it would be good to update to a current CVS snapshot to
include your and other fixes to F7 texi2html if there's no will from the
upstream maintainer to come out with the new upstream release.

Is the current CVS texi2html in a good shape or do you know about any
breakages/regressions introduced since texi2html-1.76?

There are no known regressions. Some bugfixes, some new features, 
some documented incompatibilities. It should be perfectly right
to use the CVS snapshot.

In theory I could do a release, but I prefer if Derek takes care 
of that. The only remaining issue is a license issue, the documentation
license is unclear. The original documentation author allowed us to use
whatever license we want, but once again I'd like that Derek chose.

(In reply to comment #4)
> Definitely. 

I don't really get it. Do you prefer a release before you update
the ja translation to match the changes in strings in cvs, do
you want to fix them later, or are you indifferent?

I could update the ja translation only as we have translation included
separately in the RH CVS, but as I understand it now, I need to update to the
texi2html cvs snapshot in the same time so that the strings match the newer
version of texi2html? Or are the new translations compatible with the old
texi2html-1.76?

(In reply to comment #7)
> I could update the ja translation only as we have translation included
> separately in the RH CVS,

I was thinking that you would have wanted to update them in the texi2html 
CVS... such that they are updated for the next upstream release.

> but as I understand it now, I need to update to the
> texi2html cvs snapshot in the same time so that the strings match the newer
> version of texi2html? 

The ja translation is now in texi2html CVS, so if you update to the cvs
snapshot the ja translation will be in the snapshot, and not (only) in 
RH CVS anymore -- except if you want to patch it in RH CVS.

> Or are the new translations compatible with the old
> texi2html-1.76?

No, they aren't, in the sense that translations that were in texi2html-1.76
and are not in texi2html-1.77/1.78 are in the OBSOLETE_STRINGS hash.

Ok, thanks for the clarification.

Could you please ask Derek if he could do a new texi2html release once again
maybe even with a link to this bug? If you agree, I'll wait for a week or so and
if no new release is out I'm going to package a texi2html cvs snapshot which
contains the newer ja translations.

I just updated texi2html to the latest CVS snapshot as of today.

Could you please add a comment explaining how you generated the
cvs snapshot such that sources may be checked.

Also I think that it would be better to remove the .gz in 
install-info scriptlets.

Also I suggest adding a Requires for latex2html, and maybe for
tetex-tex4ht (after the merge).

I don't know if the dependency on perl(Text::Unidecode) is 
detected automatically. If not, it should be added after
the merge.

texi2html could own  $sysconfdir/texinfo/ and $datadir/texinfo/
together with texinfo, since users may want to put an htmlxref.cnf
in those directories, which could be used by texi2html, and
makeinfo (once it is implemented in makeinfo).

(In reply to comment #11)
> Could you please add a comment explaining how you generated the
> cvs snapshot such that sources may be checked.

After checking it out from cvs I did:
autoreconf
./configure
make dist

what generated the source tarball for me. I renamed it to reflect that it's not
an official release, but a prerelease made from a CVS snapshot.

> Also I think that it would be better to remove the .gz in 
> install-info scriptlets.

No problem to remove it.

> Also I suggest adding a Requires for latex2html, and maybe for
> tetex-tex4ht (after the merge).

I'm going to add the latex2html Requires. I'm not quite sure we want to add
tex4ht dependency as it's not in Core and used only in examples?

(In reply to comment #12)
> I don't know if the dependency on perl(Text::Unidecode) is 
> detected automatically. If not, it should be added after
> the merge.

Nope, only these perl requires are autodetected:
perl(Cwd)
perl(Exporter)
perl(File::Spec)
perl(Getopt::Long)
perl(POSIX)
perl(strict)
perl(vars)


> texi2html could own  $sysconfdir/texinfo/ and $datadir/texinfo/
> together with texinfo, since users may want to put an htmlxref.cnf
> in those directories, which could be used by texi2html, and
> makeinfo (once it is implemented in makeinfo).

Hmmm, won't this clash with texinfo? %{_datadir}/texinfo is owned by texinfo
itself already.

(In reply to comment #13)
> (In reply to comment #11)
> > Could you please add a comment explaining how you generated the
> > cvs snapshot such that sources may be checked.
> 
> After checking it out from cvs I did:
> autoreconf
> ./configure
> make dist
> 
> what generated the source tarball for me.

I tried but it didn't worked. There were permissions issues for the
just updated files. Since the autotools generated files are already 
there, why not repackage the fresh cvs checkout? It is easier
to verify the sources then. 
Here is something that could work and be reproducible:

cvs -z3 -d:pserver:anonymous.nongnu.org:/sources/texi2html co -D
20070214 -d texi2html-1.77-20070214cvs texi2html
cd texi2html-1.77-20070214cvs
chmod a+x autogen.sh config.guess config.sub configure install-sh mdate-sh
missing mkinstalldirs buildt2h.sh doc/mdate-sh
cd ..
tar cjvf texi2html-1.77-20070214cvs.tar.bz2 texi2html-1.77-20070214cvs

> I'm going to add the latex2html Requires. I'm not quite sure we want to add
> tex4ht dependency as it's not in Core and used only in examples?

It is not really an example, it is an init file. With
  texi2html --init-file tex4ht.init
httex is used to render @tex and @math similarly than -l2h uses 
latex2html. Of course the dependency could only be added after the merge.
It adds functionality, however, it also brings in the whole TeX
stuff, so adding it as a Requires or not is not obvious.

(In reply to comment #14)

> Nope, only these perl requires are autodetected:
> perl(Cwd)
> perl(Exporter)
> perl(File::Spec)
> perl(Getopt::Long)
> perl(POSIX)
> perl(strict)
> perl(vars)

Ok, so Text::Unidecode should be added, but after the merge, 
since it is in extras. It is not surprising that it isn't
detected, since weird things are done to ensure that it
is detected at runtime.

> > texi2html could own  $sysconfdir/texinfo/ and $datadir/texinfo/
> > together with texinfo, since users may want to put an htmlxref.cnf
> > in those directories, which could be used by texi2html, and
> > makeinfo (once it is implemented in makeinfo).
> 
> Hmmm, won't this clash with texinfo? %{_datadir}/texinfo is owned by texinfo
> itself already.

Both texi2html and makeinfo are able to take advantage of what is
in %{_datadir}/texinfo and %_sysconfdir/texinfo/ (more precisely of 
an htmlxref.cnf file) since we agreed on the location and format 
of htmlxref.cnf. Similarly both should put the html manuals in
%{_datadir}/texinfo/html. Otherwise said %{_datadir}/texinfo/ is not 
specific of an implementation of a texinfo to html converter, but
of the texinfo language.

The release is on its way, so there shouldn't be a need for 
a cvs snapshot.

It took much longuer, Derek had too much work. That allowed 
to fix more bugs, though. 1.78 to be downloaded at:

http://download.savannah.nongnu.org/releases/texi2html/

As a side note, I'd appreciate being in initialCC or 
co-maintainer.

Ok, texi2html is now updated to 1.78. You are also co-maintainer now.

By being in pkg.acl, will I get the bug reports and the cvs
changes? Personally, when I add a co-maintainer I use

http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure

What about my other comments?

Do you agree with my proposals, such that I can provide you 
with a patch or are you disagreeing?

I committed the changes I was advocating. You can build if you like them,
I can revert the changes you dislike if you want to.

I also clarified the licenses. There is currently no tag for the
texi2html documentation license, I asked spot to add it to the wiki,
in the mean time I used MIT-like.

Thanks, it's building now. btw. texlive 0.11 will be out in a few minutes.

APPROVED. 

I'll take care of the documentation license tag.

I add this here since it was discussed above.

I just commited changes in texi2html cvs (no need to backport,
will be in the next release), to fix handling of @math, 
and it happens that with latex2html, the result cannot be
correct, since mixing of @-commands and tex commands is
allowed in @math, so something like
@math{@var{\phi}} is right, but badly interpreted by latex2html,
while with tex4ht the result is now right (since it now uses 
httexi for @math and httex for @tex). In my opinion this is 
a good reason to have a tex4ht dependency. What is your advice?

Hi Patrice, feel free to add the tex4ht dependency when the result with tex4ht
is right.

Ok, I'll do it for the texi2html release. I prefer
doing it later with post-texlive tex4ht in order to
have the right name.