[translations] Re: Another patch & questions

[John Mandereau <john.mandereau@xxxxxxxxx>]

Le dimanche 27 décembre 2009 à 01:03 +0100, Harmath Dénes a écrit : 
> On 2009.12.23., at 23:34, John Mandereau wrote: 
> > (It's a reminder for documentation editors in English that a node name
> > should be unique, which implies that some node names are intentionally a
> > bit weird.  The node name unicity requirement also holds for
> > translations.)
> 
> Oh, I see. Another argument for providing internal IDs in source for
> nodes instead of full, translated text. :)

Good idea, but not before Texinfo 6 or 7 (upcoming major version 5 will
replace Makeinfo with Texi2HTML).  There is currently no Texinfo
formatter which is flexible enough to implement what you suggest with a
reaonable difficulty (see also my rant below). 


> Thanks, this clarifies this. Fixed this.

Thanks, applied (I'm always wondering whether there is an email client
on GNU/Linux that can insert attachments in the middle of an email).
However, I'm afraid you get a silly conflict because of whitespace
(probably added by Emacs update-all-menus macro):

$ git am --whitespace=fix 0001-Docs-hu-Fix-Other-templates-in-menu.patch
Applying: Docs-hu: Fix Other templates in menu Translated website except of Community
/home/lilydev/git/lily/.git/rebase-apply/patch:389: trailing whitespace.
Minden logó és termékábrázolás szerzői joggal védett. 
/home/lilydev/git/lily/.git/rebase-apply/patch:405: trailing whitespace.
* Unix::                        
/home/lilydev/git/lily/.git/rebase-apply/patch:406: trailing whitespace.
* Mac OS X::                     
/home/lilydev/git/lily/.git/rebase-apply/patch:407: trailing whitespace.
* Windows::                     
/home/lilydev/git/lily/.git/rebase-apply/patch:408: trailing whitespace.
* Forrás::                      
warning: squelched 32 whitespace errors
warning: 37 lines applied after fixing whitespace errors.



> Of course a node reference should appear to end users as the exact
> node name, but in the sources, it must not. Computers can use
> automated processing to reduce dependency and avoid duplication, don't
> they? :)

You're right in theory.  As for the real world, LilyPond manuals are
probably the first Texinfo documents that are translated, and from my
2-years experience on Texinfo lists, LilyPond manuals have been the most
demanding for bugfixes and support of languages other than English.
This means that there is still little built-in support for translating a
Texinfo document, so translation of LilyPond manuals is still very
experimental and half-baked; even with the perl script Texi2HTML
replacing the old C implementation of Makeinfo, I don't see that
changing much within one year, as Texi2HTML code does not significantly
look less than a dish of spaghetti than Makeinfo, and its
customizability is quite coarse compared to e.g. LilyPond.  Moreover,
there is no standard object implementation in Perl as far as I know, so
almost all my concerns with Texi2HTML are the fact of the programming
language.



> Is there a way to achieve that files resulting from *.itexi files be
> rebuilt without touching their including *.texi files? I always forget
> to touch them, and though with 4 GB RAM, the docs build "only" in
> ~2:30, it is still discouraging to rebuild once again because of the
> forgotten touch. 

There is a way, but I'd better spend my time on other LilyPond tasks
than fine-tuning a build system that we're going to junk. 


> I think something like the following should be inserted in the
> Updating command section: 
> 
> If your working tree is dirty (you have modified some of the files),
> you can use 
> 
> git stash
> git pull -r
> git stash -pop

You meant 'git stash pop' (without a dash).


> to avoid conflicts when updating.

I prefer "to make pulling possible when pulled changes affect some files
that are also dirty in your working tree -- note that you may have to
resolve a conflict then, see section Conflicts in git-merge man page."

As the CG is being revised by Mark Polesky, I'll send this suggestion to
-devel list instead of pushing a commit on the CG.


> One more thing: somehow, the reference
> 
> @rweb{Könnyebb bevitel}
> 
> in hu/tutorial.tely didn't work. I hope it works at Kainhofer's server.

It looks like it doesn't depend on the build host but that
hu/macros.itexi is not up to date; check for check-translation in the CG
section about documentation translation (and/or reread a recent reply to
you from Francisco ;-)

Best,
John

Attachment: signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=