Re: Documentation translation: first patch

[John Mandereau]

Jan Nieuwenhuizen wrote:
> Ok, thanks.  We may want to merge then and use my silly
> build-html-docs-twice solution.  Or was that reverted now, Han-Wen?

Since the translated documentation itself is ready to be released, merge
and apply your trick as you like.

So, I have a question about merging branches, since I may need to do it
sooner or later. IIRC, Han-Wen has once told Joe Neeman on the list that
it was better to merge with git-rebase. Let's take a concrete example:
suppose you want to merge fr-doc (I mean, a local branch with exactly
matches fr-doc on git.sv.gnu.org) onto stable/2.10, and suppose your
current checked out branch is fr-doc. If I understand correctly, the
command to issue would be

git-rebase stable/2.10

right? And then I guess the resulting branch may be pushed to
stable/2.10, is it ok?

Another example: once fr-doc has been merged, suppose you want to work
on fr-doc again, based on the current stable/2.10 branch; is the same
command above the best way to do it?


Even if I'm not ready to commit anything, I can tell you a bit about my
plans. I'm working on hardlinking most files from out-www directories
to /out-www/{offline,online}-root, because copying them twice (for the
both offline and online docs) would really be too slow. The HTML files
will be hardlinked to only one of the targets (e.g. the offline docs);
then add-html-footer.py will read the original from this target, and for
each target it will will process and write the page. I suppose this
solution minimizes disk I/O.

Note that I won't submit/push any patch for GUB, because I don't use it.

Btw, you haven't answered my proposition for language selection in
offline docs: is it OK to copy every foo.html file that is not
translated in LANG to foo.LANG.html, and then replacing *.html hrefs
with *.LANG.html in all (i.e. real translations and copies of the
English docs) *.LANG.html files?

Cheers,
-- 
John Mandereau <address@hidden>