Re: [PossibleSpam] Re: 2.16.1

[David Kastrup]

Francisco Vila <address@hidden> writes:

> 2012/10/23 David Kastrup <address@hidden>:
>
>> Well, the problem more or less is that changes.tely (in English or in
>> Spanish) does not have a \version header.  I don't really know whether
>> this is intentional.  It is possible that it is, in order to be able to
>> show before/after pairs of LilyPond syntax without having the before
>> version clobbered by convert-ly.
>
> In any case, incompatible syntax versions can not live simultaneously
> in the same file, it would be non-compilable. This is obvious. OTOH
> @example blocks with no music image are not compiled, but would they
> be affected by convert-ly?

convert-ly does not know where LilyPond code starts or stops.  Stuff in
@example will only escape conversion if some @{ @} or @@ inside confuses
a particular convert rule.  For that reason, @verbatim may be preferable
in documentation sometimes.

>> The problem now is not actually that Documentation/es/changes.tely
>> contained unconverted material.  The problem rather is that
>> Documentation/es is the _only_ translation containing a changes.tely
>> file at all!
>
> I can not see the problem.

Well, LilyPond could see a problem in connection with issue 2883.  Not
because of a Spanish version of changes.tely but because of outdated
syntax in the Spanish version, syntax that just was not present in the
English version, and that did not get converted with convert-ly.

I would lean towards giving changes.tely a version header so that
convert-ly gives it a lookover as well.  I think that less likely to
cause problems than not giving it one.  It would likely have avoided the
problem I have seen.

>> Now the changes have not been reset to empty in master yet as
>> translations are generally still in 2.16 state.
>
> Now they are, pushed to staging.

Thanks.

> Is there any problem in translation branch yet? changes.tely in there
> is intended to be compiled during 'make doc' with the very same
> lilypond version that is compiled from that same branch during 'make'.
>
> Oh dear, this could be written much better, but I have now only 5
> hours for sleeping, so I'm done for today.

I'll be checking tomorrow again.  Basically what I have reported so far
have not strictly been translation problems specifically, but rather
things holding up issue 2883 because of making "make doc" fail for it.
This last problem was not really a problem of the translation branch but
rather more a combined versioning and work timing problem.

So my current focus with translation is very much getting it to stop
interfering with my current pet project.  The importance of the required
changes for translation itself is sometimes dubious, so I am rather
grateful for the prompt reaction.

-- 
David Kastrup