Jean-Charles Malahieude writes:
> Le 18/07/2014 16:58, David Kastrup disait :
>> "Phil Holmes" writes:
>>
>>> OK - running makelsr on current master does not touch any files, and
>>> they all have the wrong address. I propose to rerun my script, only
>>> changing the address of the LSR this tim
"Phil Holmes" writes:
>> Perhaps look at
>> the history of those snippets in snippets/new. If they have a version
>> before the "isolated duration" change, that's possibly LSR material.
>
> I don't understand what you mean by this: could you elaborate?
git log -p Documentation/snippets/new
and
"Phil Holmes" writes:
> OK - I've now confirmed the issue that has made me hold off a full LSR
> import to date. In (for example)
> adding-an-extra-staff-at-a-line-break.ly the snippet in the LSR has:
>
> \once \override Staff.TimeSignature.stencil = ##f
>
> The snippet in git has:
>
> \once \om
- Original Message -
From: "David Kastrup"
To: "Phil Holmes"
Cc:
Sent: Friday, July 18, 2014 3:58 PM
Subject: Re: LSR updates
"Phil Holmes" writes:
OK - running makelsr on current master does not touch any files, and
they all have the wrong address.
Le 18/07/2014 16:58, David Kastrup disait :
"Phil Holmes" writes:
OK - running makelsr on current master does not touch any files, and
they all have the wrong address. I propose to rerun my script, only
changing the address of the LSR this time...
I'll then update the LSR itself: there are n
- Original Message -
From: "Phil Holmes"
To: "David Kastrup"
Cc:
Sent: Friday, July 18, 2014 3:36 PM
Subject: Re: LSR updates
- Original Message -
From: "David Kastrup"
To: "Phil Holmes"
Cc:
Sent: Friday, July 18, 2014 2:02 PM
"Phil Holmes" writes:
> OK - running makelsr on current master does not touch any files, and
> they all have the wrong address. I propose to rerun my script, only
> changing the address of the LSR this time...
>
> I'll then update the LSR itself: there are now only 7 /new snippets
> that don't c
- Original Message -
From: "David Kastrup"
To: "Phil Holmes"
Cc:
Sent: Friday, July 18, 2014 2:02 PM
Subject: Re: LSR updates
"Phil Holmes" writes:
- Original Message -
From: "David Kastrup"
To: "Phil Holmes"
Cc:
Se
"Phil Holmes" writes:
> - Original Message -
> From: "David Kastrup"
> To: "Phil Holmes"
> Cc:
> Sent: Friday, July 18, 2014 1:49 PM
> Subject: Re: LSR updates
>
>
>> With regard to LSR links one probably needs to check w
- Original Message -
From: "David Kastrup"
To: "Phil Holmes"
Cc:
Sent: Friday, July 18, 2014 1:49 PM
Subject: Re: LSR updates
With regard to LSR links one probably needs to check whether they are
(re-)introduced via makelsr or some other script if one really wan
"Phil Holmes" writes:
[...]
>> But Documentation/snippets is not the baseline. It's pretty much
>> completely a generated directory. The baseline is the LSR after running
>> convert-ly on it, with Documentation/snippets/new acting as override.
>>
>> So what you want to be doing is another LSR
- Original Message -
From: "David Kastrup"
To: "Phil Holmes"
Cc:
Sent: Friday, July 18, 2014 1:06 PM
Subject: Re: LSR updates
"Phil Holmes" writes:
- Original Message -
From: "David Kastrup"
To: "Phil Holmes"
Cc:
Sen
"Phil Holmes" writes:
> - Original Message -
> From: "David Kastrup"
> To: "Phil Holmes"
> Cc:
> Sent: Friday, July 18, 2014 11:26 AM
> Subject: Re: LSR updates
>
>
>> "Phil Holmes" writes:
>>
>>> -
- Original Message -
From: "David Kastrup"
To: "Phil Holmes"
Cc:
Sent: Friday, July 18, 2014 11:26 AM
Subject: Re: LSR updates
"Phil Holmes" writes:
- Original Message -
From: "David Kastrup"
To: "Phil Holmes"
Cc:
"Phil Holmes" writes:
> - Original Message -
> From: "David Kastrup"
> To: "Phil Holmes"
> Cc:
> Sent: Thursday, July 17, 2014 12:07 PM
> Subject: Re: LSR updates
>
>
>> Phil Holmes writes:
>>
>>> I'm st
- Original Message -
From: "David Kastrup"
To: "Phil Holmes"
Cc:
Sent: Thursday, July 17, 2014 12:07 PM
Subject: Re: LSR updates
Phil Holmes writes:
I'm starting work on bringing the snippets in git up to date to match
those in the LSR. Stage one is to
Phil Holmes writes:
> I'm starting work on bringing the snippets in git up to date to match
> those in the LSR. Stage one is to change the LSR address of dsi to di in
> them all and to bring their version numbers up to 2.18.0. This isn't best
> done with makelsr because it does not blindly u
- Original Message -
From: "Phil Holmes"
To:
Sent: Thursday, July 17, 2014 11:42 AM
Subject: LSR updates
I'm starting work on bringing the snippets in git up to date to match
those in the LSR. Stage one is to change the LSR address of dsi to di in
them all and
I'm starting work on bringing the snippets in git up to date to match
those in the LSR. Stage one is to change the LSR address of dsi to di in
them all and to bring their version numbers up to 2.18.0. This isn't best
done with makelsr because it does not blindly update sll the snippets,
which
- Original Message -
From: "Phil Holmes"
To: "David Kastrup" ; "Pierre Perol-Schneider"
; "Devel"
Sent: Sunday, April 13, 2014 11:18 AM
Subject: LSR updates
OK: the LSR tarball now has snippets at 2.18.0 :-). However, this appears
to cause a
Hi Phil,
Hi Dev Team,
See Seb's message below.
Cheers,
Pierre
2014-04-13 20:29 GMT+02:00 Sebastiano Vigna :
>
>
> Uffa. There was a constant in the Java code that I forgot about. It should
> be OK now.
>
> Ciao,
>
> seba
>
>
__
- Original Message -
From: "Phil Holmes"
To: "Graham Percival"
Cc: "David Kastrup" ; "Pierre Perol-Schneider"
; "Devel"
Sent: Sunday, April 13, 2014 12:44 PM
Subject: Re: LSR updates
- Original Message -
From: "G
- Original Message -
From: "Graham Percival"
To: "Phil Holmes"
Cc: "David Kastrup" ; "Devel" ; "Pierre
Perol-Schneider"
Sent: Sunday, April 13, 2014 11:40 AM
Subject: Re: LSR updates
On Sun, Apr 13, 2014 at 11:18:43AM +0100,
On Sun, Apr 13, 2014 at 11:18:43AM +0100, Phil Holmes wrote:
> -\version "2.17.30"
> +\version "2.14.2"
>
> So it appears to be ignoring updated syntax and setting the version
> back to 2.14. Or simply not updating the syntax at all. Anyone any
> thoughts why this might be?
It's running convert
(I'm sending this to David and Pierre as well as the list. As I mentioned
before, mail I initiate and send to the list seems to be silently ignored.
Please copy my text in any reply.)
I've just run an LSR import and makelsr. I'm confused about the outcome of
the makelsr run. It appears that
I've just pushed a couple of patches to staging - patchy is now running to
move them to master.
The first updates the way the snippet lists are generated. It used to
happen before the snippets themselves were generated, using a different
method depending on whether it was a local or tarball u
Le mardi 26 juin 2012 à 08:06 +0100, Graham Percival a écrit :
> If you're going to rename stuff, I strongly suggest a bigger
> rename or you're asking for trouble. I suggest
> Documentation/lsr/ ? and Documentation/lsr/new/ ? and then the
> corresponding /build/ dirs will be created.
Regarding
On Mon, Jun 25, 2012 at 12:31:45PM +0100, Phil Holmes wrote:
> - Original Message - From: "Graham Percival"
>
> To: "Phil Holmes"
> Cc: "Devel"
> Sent: Thursday, June 21, 2012 7:47 PM
> Subject: Re: LSR updates and translations
>
>
On Mon, Jun 25, 2012 at 12:50:15PM +0100, Phil Holmes wrote:
> I think the major challenge for me in changing the way the snippets
> are managed will be updating the various makefiles so that all the
> dependencies of the snippets are built from the new directory in
> /build rather than the old one
On 25/06/2012 1:53 PM, John Mandereau wrote:
Il giorno lun, 25/06/2012 alle 18.50 +0100, Phil Holmes ha scritto:
And John M could no doubt help. It's a question of how much time they have
to contribute.
If what we want to achieve is well enough specified, then I can offer to
go for it.
Cheers
Il giorno lun, 25/06/2012 alle 12.31 +0100, Phil Holmes ha scritto:
> Yes, that directory exists. Good point. perhaps the best name would be
> /build/Documentation/snippet-src?
What about $(top-build-dir)/Documentation/snippets/out? (read
$(top-build-dir) as "build/" if you prefer)
> The same
Il giorno lun, 25/06/2012 alle 18.50 +0100, Phil Holmes ha scritto:
> And John M could no doubt help. It's a question of how much time they have
> to contribute.
If what we want to achieve is well enough specified, then I can offer to
go for it.
Cheers,
John
___
- Original Message -
From: "Francisco Vila"
I think Julien Rioux is a good candidate for this.
And John M could no doubt help. It's a question of how much time they have
to contribute.
--
Phil Holmes
___
lilypond-devel mailing l
2012/6/25 Phil Holmes :
> I think the major challenge for me in changing the way the snippets are
> managed will be updating the various makefiles so that all the dependencies
> of the snippets are built from the new directory in /build rather than the
> old one in /Documents. If anyone with build
- Original Message -
From: "John Mandereau"
To: "Jean-Charles Malahieude"
Cc: "Phil Holmes" ; "Devel"
Sent: Thursday, June 21, 2012 10:35 AM
Subject: Re: LSR updates and translations
Il giorno mer, 20/06/2012 alle 19.40 +0200, Jean-Charle
- Original Message -
From: "Graham Percival"
To: "Phil Holmes"
Cc: "Devel"
Sent: Thursday, June 21, 2012 7:47 PM
Subject: Re: LSR updates and translations
On Wed, Jun 20, 2012 at 10:50:42AM +0100, Phil Holmes wrote:
I'd like to propose a pretty
2012/6/21 Graham Percival :
> [2] let me give a huge disclaimer here: the way that we track
> translations, or translation update notifications, or whatever,
> could probably be improved.
It can be improved because it is broken.
> I have no clue what those git
> committishes are doing; at first
On Wed, Jun 20, 2012 at 10:50:42AM +0100, Phil Holmes wrote:
> I'd like to propose a pretty radical change to this process. I
> propose that /Documentation/snippets/ is a straight copy of a recent
> LSR tarball.
I assume you mean the doc-related LSR tarball, not the full LSR
tarball.
> It's the
Il giorno mer, 20/06/2012 alle 19.40 +0200, Jean-Charles Malahieude ha
scritto:
> Just a nitpick: since info files are built during the "make" phase, it
> might be more judicious to attach "make snippets" to this phase.
Oh, that's right, I forgot about those Info files without images; in
make lan
2012/6/20 Phil Holmes :
> My idea would be that, using the new system, changed snippets would look
> exactly like changed documentation files. If I modify, say,
> /Documentation/notation/ancient.itely, how do the translators pick up that
> this has been changed?
Sorry, this is moving very fast. I
Le 20/06/2012 11:50, Phil Holmes disait :
I'd like to propose a pretty radical change to this process. I propose
that /Documentation/snippets/ is a straight copy of a recent LSR
tarball. It's the task of the LSR meister to keep this up to date. We
have a new directory: build/Documentation/sni
2012/6/20 Phil Holmes :
> - Original Message - From: "Francisco Vila"
> To: "Phil Holmes"
>
>
>> Good, I like it in principle, but how will be changes being tracked
>> using SHA IDs?
>>
>> Currently, translations have a SHA ID which is that of the snippet it
>> is a translation of. Any ch
- Original Message -
From:
To: "Phil Holmes"
Cc: "Devel"
Sent: Wednesday, June 20, 2012 11:38 AM
Subject: Re: LSR updates and translations
On 20 juin 2012, at 12:29, Phil Holmes wrote:
- Original Message - From: "Francisco Vila"
To: "
Hi Phil,
Il giorno mer, 20/06/2012 alle 10.50 +0100, Phil Holmes ha scritto:
> I'd like to propose a pretty radical change to this process. I propose that
> /Documentation/snippets/ is a straight copy of a recent LSR tarball. It's
> the task of the LSR meister to keep this up to date. We have
On 20 juin 2012, at 12:29, Phil Holmes wrote:
> - Original Message - From: "Francisco Vila"
> To: "Phil Holmes"
>
>> Good, I like it in principle, but how will be changes being tracked
>> using SHA IDs?
>>
>> Currently, translations have a SHA ID which is that of the snippet it
>> is a
Hi Francisco,
Il giorno mer, 20/06/2012 alle 12.04 +0200, Francisco Vila ha scritto:
> Good, I like it in principle, but how will be changes being tracked
> using SHA IDs?
>
> Currently, translations have a SHA ID which is that of the snippet it
> is a translation of. Any change to the original sn
- Original Message -
From: "Francisco Vila"
To: "Phil Holmes"
Good, I like it in principle, but how will be changes being tracked
using SHA IDs?
Currently, translations have a SHA ID which is that of the snippet it
is a translation of. Any change to the original snippet is done in a
2012/6/20 Phil Holmes :
> I'd like to propose a pretty radical change to this process. I propose that
> /Documentation/snippets/ is a straight copy of a recent LSR tarball. It's
> the task of the LSR meister to keep this up to date. We have a new
> directory: build/Documentation/snippets. This
I've been having a think about how LSR snippets and the translations are
managed in our build system. At present, I understand the system works as
follows.
We would start with a downloaded tarball of snippets, and run makelsr.py
using that as an argument. This takes the snippets from the tar
On Sun, Apr 08, 2012 at 04:39:50PM +0100, Phil Holmes wrote:
> It'll be a ginormous patch - I can't imagine anyone reviewing it.
> My suggestion is that I push it directly to staging, given the
> number of times I'll have tested it?
I don't mind. I mean, I _will_ be looking at the patch, but I
ha
- Original Message -
From: "Graham Percival"
To: "Phil Holmes"
Cc: "Devel"
Sent: Sunday, April 08, 2012 1:25 PM
Subject: Re: LSR updates
On Sun, Apr 08, 2012 at 12:36:05PM +0100, Phil Holmes wrote:
OK. I'm in the final throes of updat
On Sun, Apr 08, 2012 at 12:36:05PM +0100, Phil Holmes wrote:
> OK. I'm in the final throes of updating the LSR and have found 2
> issues exemplified by a single file. In snippets/new we used to
> have a file called screech-boink.ly, with a doctitle of "Screech and
> Boink" and an LSR tag of "head
OK. I'm in the final throes of updating the LSR and have found 2 issues
exemplified by a single file. In snippets/new we used to have a file called
screech-boink.ly, with a doctitle of "Screech and Boink" and an LSR tag of
"headwords".
First problem. If this is added to the LSR with that Ti
New patch set.
http://codereview.appspot.com/5696069/diff/1/Documentation/contributor/lsr-work.itexi
File Documentation/contributor/lsr-work.itexi (right):
http://codereview.appspot.com/5696069/diff/1/Documentation/contributor/lsr-work.itexi#newcode302
Documentation/contributor/lsr-work.itexi:3
http://codereview.appspot.com/5696069/diff/1/Documentation/contributor/lsr-work.itexi
File Documentation/contributor/lsr-work.itexi (right):
http://codereview.appspot.com/5696069/diff/1/Documentation/contributor/lsr-work.itexi#newcode302
Documentation/contributor/lsr-work.itexi:302: @item
On 201
One suggestion.
Regards,
Julien
http://codereview.appspot.com/5696069/diff/1/Documentation/contributor/lsr-work.itexi
File Documentation/contributor/lsr-work.itexi (right):
http://codereview.appspot.com/5696069/diff/1/Documentation/contributor/lsr-work.itexi#newcode302
Documentation/contributor
Reviewers: ,
Message:
Please review.
I'm very busy with GSoC now, so if you identify deficiencies, please
write verbose changes you want done. Otherwise i will update it
somewhere in March, sorry :(
Janek
Description:
CG: Use latest convert-ly for LSR updates (fix 2346)
Suggested by T
Graham Percival writes:
> On Tue, Feb 21, 2012 at 09:57:54PM +0100, David Kastrup wrote:
>> Graham Percival writes:
>> > oh, I see. That was actually a clean-up from 2.15.30, because the
>> > tag got lost because release/unstable didn't merge into master
>> > properly. (why? no clue; I just f
On Tue, Feb 21, 2012 at 09:57:54PM +0100, David Kastrup wrote:
> Graham Percival writes:
> > oh, I see. That was actually a clean-up from 2.15.30, because the
> > tag got lost because release/unstable didn't merge into master
> > properly. (why? no clue; I just followed the instructions in the
Graham Percival writes:
> On Tue, Feb 21, 2012 at 09:40:26PM +0100, David Kastrup wrote:
>> I just bungled staging with bad Texinfo in a regtest and saw that you
>> merged into it right after that, presumably because of a release. I can
>> either replace the merge (it will no longer have the sam
On Tue, Feb 21, 2012 at 09:40:26PM +0100, David Kastrup wrote:
> I just bungled staging with bad Texinfo in a regtest and saw that you
> merged into it right after that, presumably because of a release. I can
> either replace the merge (it will no longer have the same commit id) or
> throw it out
Graham Percival writes:
> On Tue, Feb 21, 2012 at 08:49:21PM +0100, David Kastrup wrote:
>> Uh, Graham? Just fixed another regression discovered by an LSR failure
>> and pushed to staging. It would appear that this needs to be in 2.16
>> according to our policies.
>
> Well, there's already 2 Cr
On Tue, Feb 21, 2012 at 08:49:21PM +0100, David Kastrup wrote:
> Uh, Graham? Just fixed another regression discovered by an LSR failure
> and pushed to staging. It would appear that this needs to be in 2.16
> according to our policies.
Well, there's already 2 Critical issues, and I think that 23
David Kastrup writes:
> Thomas Morley writes:
>
>> I didn't manage to fix:
>> filtering-parts-from-the-command-line.ly
>
> You just did not try hard enough. It was a really obscure bug in the
> lexer. I'll commit a fix to staging once make check goes through.
>
> I think I need a beer.
Uh, Gr
On Mon, Jan 02, 2012 at 11:50:07AM -, Phil Holmes wrote:
> I'd like to push
> this to staging, but would appreciate someone else (David, Graham?)
> looking at it just to check. I'd prefer not to go to a Rietveld for
> this simple change.
LGTM.
Cheers,
- Graham
__
- Original Message -
From: "David Kastrup"
To:
Sent: Monday, January 02, 2012 11:56 AM
Subject: Re: LSR updates (again)
"Phil Holmes" writes:
OK - I'm having another go at getting the LSR updates into git.
Graham's recommended method for this (whi
On Jan 2, 2012, at 12:56 PM, David Kastrup wrote:
> "Phil Holmes" writes:
>
>> OK - I'm having another go at getting the LSR updates into git.
>> Graham's recommended method for this (which I will add to the CG) is
>> to run makelsr locally, with n
"Phil Holmes" writes:
> OK - I'm having another go at getting the LSR updates into git.
> Graham's recommended method for this (which I will add to the CG) is
> to run makelsr locally, with no downloaded updates - this simply
> aligns git with any changes makels
OK - I'm having another go at getting the LSR updates into git. Graham's
recommended method for this (which I will add to the CG) is to run makelsr
locally, with no downloaded updates - this simply aligns git with any
changes makelsr automatically makes. Attached is a patch
On Sat, Nov 26, 2011 at 12:53:55PM -, Phil Holmes wrote:
> - Original Message - From: "Graham Percival"
>
> >if you skim over the patch in gitk, you shouldn't see anything
> >weird. commit that and push directly to staging.
>
> Depends what counts as weird. I see lots of commitish c
- Original Message -
From: "Graham Percival"
To: "Phil Holmes"
Cc: "Devel"
Sent: Friday, November 25, 2011 7:10 PM
Subject: Re: LSR updates and Issue 1971
On Fri, Nov 25, 2011 at 05:59:04PM -, Phil Holmes wrote:
I've got a large patch that up
On Fri, Nov 25, 2011 at 05:59:04PM -, Phil Holmes wrote:
> I've got a large patch that updates the snippets from the LSR and
> fixes Issue 1971. It's a few hundred files. make and make doc are
> fine after adding it. Should I push to staging or do something like
> a review - it seems unlikel
On 11/25/11 11:46 AM, "Phil Holmes" wrote:
>- Original Message -
>From: "Carl Sorensen"
>To: "Phil Holmes" ; "Devel"
>Sent: Friday, November 25, 2011 6:35 PM
>Subject: Re: LSR updates and Issue 1971
>
>
>>
>>
&g
- Original Message -
From: "Carl Sorensen"
To: "Phil Holmes" ; "Devel"
Sent: Friday, November 25, 2011 6:35 PM
Subject: Re: LSR updates and Issue 1971
On 11/25/11 10:59 AM, "Phil Holmes" wrote:
I've got a large patch that updates t
On 11/25/11 10:59 AM, "Phil Holmes" wrote:
>I've got a large patch that updates the snippets from the LSR and fixes
>Issue 1971. It's a few hundred files. make and make doc are fine after
>adding it. Should I push to staging or do something like a review - it
>seems unlikely anyone will have
I've got a large patch that updates the snippets from the LSR and fixes
Issue 1971. It's a few hundred files. make and make doc are fine after
adding it. Should I push to staging or do something like a review - it
seems unlikely anyone will have the enthusiasm to review all 300-odd changed
f
Le lundi 27 juillet 2009 à 17:12 +0200, John Mandereau a écrit :
> Le dimanche 28 juin 2009 à 17:58 +0300, Till Paala a écrit :
> > I called it without any argument and it updated some 4
> > snippets in input/lsr with convert-ly to a new lilypond-version -- but
> > it didn't touch anything that
Le dimanche 28 juin 2009 à 17:58 +0300, Till Paala a écrit :
> it seems I just did the same mistake and commited everything in
> input/texidoc. But I really don't understand makelsr.py and how it
> should work.
Then please read the CG.
> I called it without any argument and it updated some 4
Le dimanche 28 juin 2009 à 17:33 +0200, Francisco Vila a écrit :
> The current scheme of committishes on texidoc files makes hard to do
> this automatically, because languages can be in any order into the
> file. How can it be said what language it belongs? I suggest to mark
> the line with the lan
2009/7/2 Till Paala :
> Francisco Vila schrieb:
> What I did when there were hundredths of outdated files was to copy
> them all to another directory, change all their committishes to the
> updated one in all languages (which is temporally wrong for all but
> for your language), then call repeated
Francisco Vila schrieb:
2009/6/28 Till Paala :
If it is easy for you to somehow just update all German commitishes in
input/texidocs, run makelsr.py, so that the changes get into the .ly files
and commit the whole story I would be really greatful.
The current scheme of committishes on
2009/6/28 Till Paala :
> If it is easy for you to somehow just update all German commitishes in
> input/texidocs, run makelsr.py, so that the changes get into the .ly files
> and commit the whole story I would be really greatful.
The current scheme of committishes on texidoc files makes hard to do
John Mandereau schrieb:
Till Rettig a écrit :
its great fun, there is really a lot. ;-) The changes are about the
German translation being also added to the .ly file. That's a tricky
case. I will always have to update snippets two times: one time when
translated and the second time after the n
Francisco Vila a écrit :
Yes, I don't see anything strange except a "not smart enough" message.
I am using only an installed, fresh compiled Git snapshot.
Did you pass makeslr.py an argument? You shouldn't have, unless you know
why.
No.
Then makelsr.py must be bogus; it should not de
2009/5/26, John Mandereau :
> Before looking at your (rather scary in this case) "git status" output,
> have you examined output of makelsr.py?
Yes, I don't see anything strange except a "not smart enough" message.
> Have you realized makelsr.py requires fresh snapshots compiled from Git of
> l
Francisco Vila a écrit :
2009/5/25, John Mandereau :
You should run makelsr.py *before* you commit changes to texidocs, not
after. Try it as explained in the CG, and you'll see (how) it works.
Hello, I'm in trouble. I have run makelsr.py and git status gives
Before looking at your
2009/5/25, John Mandereau :
> You should run makelsr.py *before* you commit changes to texidocs, not
> after. Try it as explained in the CG, and you'll see (how) it works.
Hello, I'm in trouble. I have run makelsr.py and git status gives
# On branch lilypond/translation
# Changed but not updated
Francisco Vila a écrit :
2009/5/22 John Mandereau :
For previous work it is too late, but for future work, run makelsr.py
before committing to Git -- read the CG on snippet handling for more
details.
I'm afraid I don't understand how running makelsr.py changes what is
committed, if you
2009/5/22 John Mandereau :
> Till Rettig a écrit :
>>
>> its great fun, there is really a lot. ;-) The changes are about the German
>> translation being also added to the .ly file. That's a tricky case. I will
>> always have to update snippets two times: one time when translated and the
>> second t
Francisco Vila a écrit :
By default I couldn't guess which one to put,
What about the last revision of the associated .ly file in input/lsr?
Isn't it the place where you took the text to translate?
input/new/foo.ly would be OK if we had all snippets there.
so I put the comm. of a
merge node
Till Rettig a écrit :
its great fun, there is really a lot. ;-) The changes are about the
German translation being also added to the .ly file. That's a tricky
case. I will always have to update snippets two times: one time when
translated and the second time after the next lsr-update that adds
John Mandereau schrieb:
Francisco Vila a écrit :
Well, it seems that we can ignore all the diff lines that do not touch
texidoc= or doctitle= fields on files in lsr/ ; so it's not that bad.
Is this right?
It is. This will remain as much cumbersome until LSR snippets (and the
associated data
John Mandereau schrieb:
Till Rettig a écrit :
This translation interface is getting more and more tricky it seems
(I mean technically)
Speaking of, my next task on the translation infrastructure is
simplyfing it a little, i.e. translating node names and titles in
Texinfo sources, which will ta
Francisco Vila a écrit :
Well, it seems that we can ignore all the diff lines that do not touch
texidoc= or doctitle= fields on files in lsr/ ; so it's not that bad.
Is this right?
It is. This will remain as much cumbersome until LSR snippets (and the
associated data: title, description...)
2009/5/22 Francisco Vila :
> 10459
> :-(
Well, it seems that we can ignore all the diff lines that do not touch
texidoc= or doctitle= fields on files in lsr/ ; so it's not that bad.
Is this right?
--
Francisco Vila. Badajoz (Spain)
www.paconet.org
__
2009/5/22 John Mandereau :
> Speaking of, my next task on the translation infrastructure is simplyfing it
> a little, i.e. translating node names and titles in Texinfo sources, which
> will take 10 hours including the multiple cycles of checking the results and
> adjusting the translation script.
2009/5/22 John Mandereau :
> Francisco Vila a écrit :
>> committishes themselves are not checked
>
> They can now, but I was puzzled by the truckload of bad committishes I found
> in Spnaish texidocs,
They were all the same, and no one existed before that.
>so I applied my auto-committish-setting
Francisco Vila a écrit :
it is done;
Cool, thanks!
committishes themselves are not checked
They can now, but I was puzzled by the truckload of bad committishes I
found in Spnaish texidocs, so I applied my auto-committish-setting hack
to them too. I'm not very sure on the correctness of the
Till Rettig a écrit :
This translation interface is getting more and more tricky it seems (I
mean technically)
Speaking of, my next task on the translation infrastructure is
simplyfing it a little, i.e. translating node names and titles in
Texinfo sources, which will take 10 hours including the
Francisco Vila schrieb:
2009/5/18 John Mandereau :
Francisco Vila a écrit :
Permission to bulk fix it into the last version, in all languages.
...I'm doing my best to update the script and fix committishes
with regexp substitution before next week.
Well, I was really
1 - 100 of 106 matches
Mail list logo
