lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Latest (ja) Translation branch merge breaks make doc - possible new


From: David Kastrup
Subject: Re: Latest (ja) Translation branch merge breaks make doc - possible new syntax change ist he cause
Date: Mon, 31 Oct 2011 06:17:11 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux)

Francisco Vila <address@hidden> writes:

> 2011/10/30 Peekay Ex <address@hidden>:
>> Francisco,
>>
>> Since the latest Translation branch merge I get full doc build failure
>> during the 'ja' part - which corresponds to the japanese translation
>> checkin.
>>
>> I've only had a cursory glance at the error and it says
>>
>> error: unknown escaped string: `\makeStringTuning
>>
>> I wondered if this was anything to do with David's recent checkins
>>
>> commit  2e7e9b0b2bb077c3ec621c049555ddaed1724eb3
>
> Thank you. I have been looking at the history of recent changes to doc
> files related to string tuning, and it looks crazy.  Updates to files
> in existing translations were made in master branch, and they should
> habe been made in translation branch.  Therefore, new Japanese
> translations have not been changed accordingly. I am pushing such
> changes right now.
>
> Sorry for the inconvenience.

The syntax changed in incompatible ways.  Appropriate changes to
convertrules.py were made, and update-with-convert-ly was run on the
tree including the translations, keeping the translations compilable but
untranslated.  No manual changes were made to the translations.

Of course, this is a nuisance to translators, but I really don't see how
we could do any better than that.

We had the additional complication that the merges from staging changed
the structure of the commits and separated them into a commit doing the
syntax change itself, and the commit with the convert-ly run.  The
above-mentioned commit is such a syntax change commit leaving the tree
in uncompilable state without the immediately following commit.

We can do better than that and eventually will, but I don't think this
should cause your current problems.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]