Re: Regarding LSR translation work
Original Message - From: Graham Percival gra...@percival-music.ca To: Federico Bruni fedel...@gmail.com Currently, makelsr.py adds different amounts of blank lines to some .ly files depending on whether you run it as a full import vs. when you run it locally. It would be nice if that didn't happen. FWIW, I'm pretty certain I now know what causes the additional blank lines. It's code added with this comment: # workaround for a bug in the regex's that I'm not smart # enough to figure out. -gp ;-) If my new plan works, it won't be necessary to fix this anyway. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
Il 25/04/2012 12:04, Graham Percival ha scritto: [..] I'm trying to learn Python and I'd like to contribute to some frog tasks requiring python (I've starred some frog issues in the tracker). Probably this is too much difficult for a newbie. Actually, I've got a good suggestion on how you could get started with python and all this stuff. Currently, makelsr.py adds different amounts of blank lines to some .ly files depending on whether you run it as a full import vs. when you run it locally. It would be nice if that didn't happen. [I've just started looking at this.] I think that blank lines are not the only problem. git log shows that most of the snippets' commits are related to the update of committish in translated texidoc strings. It's what we are talking about in this thread: in order to mark a snippet as updated, a translator updates the committish in the .texidoc file and run makelsr, which copies the new committish in the snippet. So the snippet gets a new (unnecessary?) commit, which makes all the other translations of that snippet out-of-date. It's a dog chasing its tail. These committishes copied inside the snippets are needed? IIUC, check-translation doesn't care about the committishes placed inside a file; it just check the latest git commit hash: line 38 of check-translation.py: vc_revision_parse = 'git log -1 --pretty=format:%%H %s' What happens if we remove all the %% Translation of GIT committish: strings in the snippets and change makelsr so that it will ignore the first line of .texidoc files when it copies them in the snippets? I don't believe that check-translation will stop working. The benefits would be: - no unuseful stuff in the commits of snippets -- cleaner git log - cleaner git log -- less output in check-translation Does it make sense? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
Le 04/05/2012 17:34, Francisco Vila disait : 2012/5/4 Phil Holmesm...@philholmes.net: I think the way to do this would be to have makelsr.py extract the texidoc and doctitle strings from the snippets and to put them into Documentation/texidoc/. In principle it would delete them from the snippet, and then put them back in again, as I believe it does for translated strings. However, that seems pointless - if it just copies the strings to the directory, the translators can monitor those, as they do for other documents. Is that accurate? Our problem is not just what to track and how, but the fact that English and translated strings are mixed in the same files, any change to those generates warnings for translators making them to think there is any translation work to do, and if they do it, that in turn makes changes to the same files generating the warnings again for the rest of translators. Your solution above seems to go in the good direction as long as - what we track are English-only strings - makelsr copies those strings to another place but does not change them in place. - check-translation generates output based on changes to original English files, not on the result of makelsr as it currently does. I think that's all, forwarding to translations list for more opinions. As this may be the only best way to just track the headers, I totally agree. And, on a second thought, all languages would then adopt in some way the same tree and reflect the same contents, which in my opinion is not a bad thing. Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
On Sat, May 05, 2012 at 10:35:02AM +0200, Federico Bruni wrote: Il 25/04/2012 12:04, Graham Percival ha scritto: [..] I'm trying to learn Python and I'd like to contribute to some frog tasks requiring python (I've starred some frog issues in the tracker). Probably this is too much difficult for a newbie. Currently, makelsr.py adds different amounts of blank lines to some .ly files depending on whether you run it as a full import vs. when you run it locally. It would be nice if that didn't happen. I think that blank lines are not the only problem. Of course it isn't. But it's the *easiest*, most *harmless*, way that you could get started. It's not an urgent job. Once somebody knows python and that script, it's a 5-minute job to fix it. That's why I thought it would be perfect for you to start with. As a general rule of thumb, 5 minutes of experienced developer time translates to about 5 hours for a complete beginner. If you're not a complete beginner at python and the script, then reduce the estimate according to however you rank your own skill. -snip- Does it make sense? It's plausible, but I really don't know how the system works. You could try asking John Mandereau. I still think you should start with an easy job, but if you want to jump straight into the hard stuff, go ahead. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
- Original Message - From: Federico Bruni fedel...@gmail.com To: Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org Sent: Tuesday, April 24, 2012 1:29 PM Subject: Re: Regarding LSR translation work 2012/4/24 Phil Holmes m...@philholmes.net: 1) I don't understand what say hello to LSR means. sorry, I meant goodbye to LSR 2) I don't really understand how LSR snippets are translated, so can't comment knowledgably See CG, 5.8.3, Updating translation committishes (last two paragraphs). The translations are saved in Documentation/MY-LANGUAGE/texidocs. Running makelsr will copy the new translations to the relevant files. That's why the committish stuff breaks: - a snippet gets a new committish - only the latest language added has the latest makelsr committish and therefore it's up-to-date for check-translation - all the other languages will be out-of-date even if they are not I'm afraid that the only way to avoid this is putting the english texidoc= and doctitle= strings in Documentation/texidocs and change makelsr.py accordingly. Translators would then translate and track Documentation/texidoc/* and ignore totally Documentation/snippets/ I hope that what I wrote makes sense. Just having a little think about this. I think the way to do this would be to have makelsr.py extract the texidoc and doctitle strings from the snippets and to put them into Documentation/texidoc/. In principle it would delete them from the snippet, and then put them back in again, as I believe it does for translated strings. However, that seems pointless - if it just copies the strings to the directory, the translators can monitor those, as they do for other documents. Is that accurate? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
2012/5/4 Phil Holmes m...@philholmes.net: I think the way to do this would be to have makelsr.py extract the texidoc and doctitle strings from the snippets and to put them into Documentation/texidoc/. In principle it would delete them from the snippet, and then put them back in again, as I believe it does for translated strings. However, that seems pointless - if it just copies the strings to the directory, the translators can monitor those, as they do for other documents. Is that accurate? Our problem is not just what to track and how, but the fact that English and translated strings are mixed in the same files, any change to those generates warnings for translators making them to think there is any translation work to do, and if they do it, that in turn makes changes to the same files generating the warnings again for the rest of translators. Your solution above seems to go in the good direction as long as - what we track are English-only strings - makelsr copies those strings to another place but does not change them in place. - check-translation generates output based on changes to original English files, not on the result of makelsr as it currently does. I think that's all, forwarding to translations list for more opinions. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
On Tue, Apr 24, 2012 at 02:28:21PM +0200, Federico Bruni wrote: 2012/4/24 Graham Percival gra...@percival-music.ca: 2) ask the LSR author to add the possibility to insert translated titles and descriptions (the website itself could benefit from this, since it may enable language negotiation). But managing the updates may be a problem.. You'd be asking him to do about 30 hours of unpaid work. Yes, I'm aware of it. There's nothing to lose in asking politely for a new feature. You're right. Ok, go ahead and ask Sebastiano if he would be interested in adding multi-language support to LSR, where the alternate languages would be output in texidoc strings inside the .ly file. For bonus points, ask him in Italian. :) I want the documentation to look exactly the same as it does right now. And most of all I'd like the documentation maintainance for translators to be not buggy like it is now. Python is the only requirement for this task, right? Python, make, maybe texinfo, maybe stepmake, etc. Depends on exactly what you're trying to do. I'm trying to learn Python and I'd like to contribute to some frog tasks requiring python (I've starred some frog issues in the tracker). Probably this is too much difficult for a newbie. Actually, I've got a good suggestion on how you could get started with python and all this stuff. Currently, makelsr.py adds different amounts of blank lines to some .ly files depending on whether you run it as a full import vs. when you run it locally. It would be nice if that didn't happen. i.e. if you ran makelsr.py lsr-downloaded-today-date/ once, then did: makelsr.py makelsr.py lsr-downloaded-today-date/ makelsr.py ... etc... it shouldn't change between after each makelsr.py As far as this type of build system stuff goes, this is a pretty easy task. But if you're beginning python now, I'd expect it to take 5-10 hours for you to fix. On the plus side, once you've done this you'll understand the current system much better. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
- Original Message - From: Federico Bruni fedel...@gmail.com To: lilypond-devel@gnu.org Sent: Monday, April 23, 2012 11:04 PM Subject: Re: Regarding LSR translation work Il 21/04/2012 13:09, Graham Percival ha scritto: From a very basic-no-progamming skill perspective, why can't we just have an extra texidoc entry in the snippet itself and add the translation manually, like we would for any updated snippet? Because then it would be overwritten whenever we do a LSR import. In fact, why do we even need a texidoc string*inside* the snippet? I don't use one for @lilypond examples. Because snippets come from LSR, and that needs a texidoc to display some text for the snippet. So it seems that there are only two possible solutions (I'm just daydreaming): 1) manage all the docs snippets in Git and say hello to LSR (see bottom of my email) 1) I don't understand what say hello to LSR means. 2) I don't really understand how LSR snippets are translated, so can't comment knowledgably 3) Graham is wrong when he says writing snippets is not a good introduction to lilypond. I started by doing a fair few that documented undocumented features shown in the regtests. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
On Tue, Apr 24, 2012 at 07:52:55AM +0100, Phil Holmes wrote: 3) Graham is wrong when he says writing snippets is not a good introduction to lilypond. I started by doing a fair few that documented undocumented features shown in the regtests. Sorry, I came on too strong there. I didn't mean to say that writing snippets is not a good introduction -- it's probably the best introduction we have. In fact, I myself began with lilypond by working on snippets (they were called input/test/ back then)! I'm disappointed that there hasn't been more interest in LSR, and more volunteers working on it [1]. But that's a social problem, not a technical one. If we can solve that social problem, I'd be much more ethusiastic about defending the status quo [2]. [1] of course there was some recent interest in this. But to put some numbers on it: I was expecting ~3 contributors per year to do serious work within LSR, and to have ~1 new LSR editor per year. I think that over the lifetime of LSR (i.e. 7 years) we've had about 5 contributors doing serious work and 2 or 3 editors. [2] I mean, defending the status quo for positive reasons, not just because it'll be a big mess to change anything. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
I _am_ topposting. Let me explain a copule of things. Ciao is Italian for hello and also for goodbye, so if you untranslate and then translate back, all becomes clear, at least for me. The problem is not LSR itself. Yes, the docs will look the same after, but it's not how the docs look like, either. The problem is maintainance, our current system has a bug, to put it simple. The makecheck script is great so please keep it. Just the _part of_ makecheck that checks lsr snippets is broken because it warns about tons of out-of-sync lines that are not really out-of-sync, that's all. That, and what it involves: making all those warnings to dissapear from makecheck output is done with a macropatch which in turn forces other translators to fix the warnings with another macopatch. I am afraid about not being able to explain this more clearly to non-translators. John Mandereau will present his PhD thesis in october if I'm not wrong. _If_ after that he wants to help a bit with this, given that he created it, I can wait. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
2012/4/24 Francisco Vila paconet@gmail.com: I _am_ topposting. Let me explain a copule of things. Ouch! -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
2012/4/24 Graham Percival gra...@percival-music.ca: On Tue, Apr 24, 2012 at 12:04:57AM +0200, Federico Bruni wrote: 1) manage all the docs snippets in Git and say hello to LSR (see bottom of my email) Do you mean goodbye instead of hello ? sorry, yes of course I meant goodbye 2) ask the LSR author to add the possibility to insert translated titles and descriptions (the website itself could benefit from this, since it may enable language negotiation). But managing the updates may be a problem.. You'd be asking him to do about 30 hours of unpaid work. Yes, I'm aware of it. There's nothing to lose in asking politely for a new feature. I hope that he has interest in it, otherwise no problem. I really don't see any way to rescue the snippet system. It was a gamble that hasn't paid off; it was supposed to be a standalone Since the gamble hasn't paid off (i.e. it didn't encourage *potential contributors*), why keeping this structure that is really annoying current translators (i.e. *real contributors*)? Because any change involves work. So there are no strong reasons against stopping the LSR import. But I've read also your next reply where you say that you'd defend more enthusiastically the status quo if people started contributing more to LSR. Still, if this magically happened tomorrow, I don't see the advantage of keeping the LSR import. I think that it would be better to think the LSR as a community project (easy to access for normal users) and keep the doc snippets separated and edited by contributors in Git. Personally, I'm a bit worried about going on with translating NR when I know that keeping it up-to-date will be an hassle. Let's manage all the doc snippets in Git and say hello to LSR import! Which are the arguments against this change? It involves work. In particular, horrible build system work, which always takes an order of magnitude longer than you might expect. Really a lot of work? Removing LSR import could only simplify the current system. Of course it involves some work, but i can imagine is more about removing and adapting than adding. Any non-trivial change to the current system will take a minimum of 10 hours of work, and I would not be the slightest bit surprised if it ends up taking 50 hours. Are *you* offering to do all that work? To spend 50 hours, and at the end of all that work, have the documentation look exactly the same as it does right now? I want the documentation to look exactly the same as it does right now. And most of all I'd like the documentation maintainance for translators to be not buggy like it is now. Python is the only requirement for this task, right? I'm trying to learn Python and I'd like to contribute to some frog tasks requiring python (I've starred some frog issues in the tracker). Probably this is too much difficult for a newbie. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
2012/4/24 Carl Sorensen c_soren...@byu.edu: Let's manage all the doc snippets in Git and say hello to LSR import! Which are the arguments against this change? It involves work. In particular, horrible build system work, which always takes an order of magnitude longer than you might expect. If the proposal is to eliminate makelsr.py, and just manage our own snippets in Documentation/snippets, it seems to me that the primary task is to eliminate the Do not edit fields from the contents of Documentation/snippets. Is there more that I'm not aware of? We should also decide how to include the translations. And how to track the changes. Trying to understand better how the current system work is in my TODO list since a couple of months. Unfortunately time is a scarce resource (and I need a lot of time to understand it :-)). ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
2012/4/24 Phil Holmes m...@philholmes.net: 1) I don't understand what say hello to LSR means. sorry, I meant goodbye to LSR 2) I don't really understand how LSR snippets are translated, so can't comment knowledgably See CG, 5.8.3, Updating translation committishes (last two paragraphs). The translations are saved in Documentation/MY-LANGUAGE/texidocs. Running makelsr will copy the new translations to the relevant files. That's why the committish stuff breaks: - a snippet gets a new committish - only the latest language added has the latest makelsr committish and therefore it's up-to-date for check-translation - all the other languages will be out-of-date even if they are not I'm afraid that the only way to avoid this is putting the english texidoc= and doctitle= strings in Documentation/texidocs and change makelsr.py accordingly. Translators would then translate and track Documentation/texidoc/* and ignore totally Documentation/snippets/ I hope that what I wrote makes sense. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
- Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: Federico Bruni fedel...@gmail.com; lilypond-devel@gnu.org Sent: Tuesday, April 24, 2012 8:42 AM Subject: Re: Regarding LSR translation work [1] of course there was some recent interest in this. But to put some numbers on it: I was expecting ~3 contributors per year to do serious work within LSR, and to have ~1 new LSR editor per year. I think that over the lifetime of LSR (i.e. 7 years) we've had about 5 contributors doing serious work and 2 or 3 editors. I think you tend to see the LSR as a way of providing examples for the docs, which it does. However, it has a much more significant value as a searchable source of tweaks and inspiration. It's worth supporting for that alone. Thomas and David are now supporting it with my help as git pusher, and I hope the upgrade to 2.16 will happen quite promptly. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
- Original Message - From: Francisco Vila paconet@gmail.com To: Graham Percival gra...@percival-music.ca Cc: Phil Holmes m...@philholmes.net; lilypond-devel@gnu.org Sent: Tuesday, April 24, 2012 9:10 AM Subject: Re: Regarding LSR translation work The problem is not LSR itself. Yes, the docs will look the same after, but it's not how the docs look like, either. The problem is maintainance, our current system has a bug, to put it simple. The makecheck script is great so please keep it. Just the _part of_ makecheck that checks lsr snippets is broken because it warns about tons of out-of-sync lines that are not really out-of-sync, that's all. I'd be happy to make this a summer project, if you and Federico want to collaborate. Can't start until the end of this year of college, though. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
- Original Message - From: Federico Bruni fedel...@gmail.com To: Graham Percival gra...@percival-music.ca Cc: lilypond-devel@gnu.org Sent: Tuesday, April 24, 2012 1:28 PM Subject: Re: Regarding LSR translation work 2) ask the LSR author to add the possibility to insert translated titles and descriptions (the website itself could benefit from this, since it may enable language negotiation). But managing the updates may be a problem.. You'd be asking him to do about 30 hours of unpaid work. Yes, I'm aware of it. There's nothing to lose in asking politely for a new feature. I hope that he has interest in it, otherwise no problem. There is, I believe, a tarball of the source in the LSR downloads directory, so it doesn't have to be Sebastiano who does this. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
On 4/24/12 7:56 AM, Phil Holmes m...@philholmes.net wrote: - Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: Federico Bruni fedel...@gmail.com; lilypond-devel@gnu.org Sent: Tuesday, April 24, 2012 8:42 AM Subject: Re: Regarding LSR translation work [1] of course there was some recent interest in this. But to put some numbers on it: I was expecting ~3 contributors per year to do serious work within LSR, and to have ~1 new LSR editor per year. I think that over the lifetime of LSR (i.e. 7 years) we've had about 5 contributors doing serious work and 2 or 3 editors. I think you tend to see the LSR as a way of providing examples for the docs, which it does. However, it has a much more significant value as a searchable source of tweaks and inspiration. It's worth supporting for that alone. In my opinion, the LSR as a user-contributable source of tweaks and inspiration is certainly useful, and I wouldn't want to see it go away. However, I can see some arguments for not having the LSR be the repository for our documentation snippets. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
Il 24/04/2012 16:00, Phil Holmes ha scritto: I'd be happy to make this a summer project, if you and Federico want to collaborate. Can't start until the end of this year of college, though. Thanks Phil, that would be great. Let us know when you start, I'll try to help as much as I can. Cheers, Federico ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
2012/4/24 Federico Bruni fedel...@gmail.com: Il 24/04/2012 16:00, Phil Holmes ha scritto: I'd be happy to make this a summer project, if you and Federico want to collaborate. Can't start until the end of this year of college, though. Thanks Phil, that would be great. Let us know when you start, I'll try to help as much as I can. Same. Thanks! -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
Il 21/04/2012 13:09, Graham Percival ha scritto: From a very basic-no-progamming skill perspective, why can't we just have an extra texidoc entry in the snippet itself and add the translation manually, like we would for any updated snippet? Because then it would be overwritten whenever we do a LSR import. In fact, why do we even need a texidoc string*inside* the snippet? I don't use one for @lilypond examples. Because snippets come from LSR, and that needs a texidoc to display some text for the snippet. So it seems that there are only two possible solutions (I'm just daydreaming): 1) manage all the docs snippets in Git and say hello to LSR (see bottom of my email) 2) ask the LSR author to add the possibility to insert translated titles and descriptions (the website itself could benefit from this, since it may enable language negotiation). But managing the updates may be a problem.. I really don't see any way to rescue the snippet system. It was a gamble that hasn't paid off; it was supposed to be a standalone system that would let normal unprivileged users contribute to the docs with almost no oversight by anybody with git access. With all the developer effort that's gone into build and maintaing it, we could have made it easier to do stuff in git and/or trained more doc editors. Since the gamble hasn't paid off (i.e. it didn't encourage *potential contributors*), why keeping this structure that is really annoying current translators (i.e. *real contributors*)? Personally, I'm a bit worried about going on with translating NR when I know that keeping it up-to-date will be an hassle. Let's manage all the doc snippets in Git and say hello to LSR import! Which are the arguments against this change? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
On Tue, Apr 24, 2012 at 12:04:57AM +0200, Federico Bruni wrote: Il 21/04/2012 13:09, Graham Percival ha scritto: Because snippets come from LSR, and that needs a texidoc to display some text for the snippet. So it seems that there are only two possible solutions (I'm just daydreaming): 1) manage all the docs snippets in Git and say hello to LSR (see bottom of my email) Do you mean goodbye instead of hello ? 2) ask the LSR author to add the possibility to insert translated titles and descriptions (the website itself could benefit from this, since it may enable language negotiation). But managing the updates may be a problem.. You'd be asking him to do about 30 hours of unpaid work. I really don't see any way to rescue the snippet system. It was a gamble that hasn't paid off; it was supposed to be a standalone Since the gamble hasn't paid off (i.e. it didn't encourage *potential contributors*), why keeping this structure that is really annoying current translators (i.e. *real contributors*)? Because any change involves work. Personally, I'm a bit worried about going on with translating NR when I know that keeping it up-to-date will be an hassle. Let's manage all the doc snippets in Git and say hello to LSR import! Which are the arguments against this change? It involves work. In particular, horrible build system work, which always takes an order of magnitude longer than you might expect. Any non-trivial change to the current system will take a minimum of 10 hours of work, and I would not be the slightest bit surprised if it ends up taking 50 hours. Are *you* offering to do all that work? To spend 50 hours, and at the end of all that work, have the documentation look exactly the same as it does right now? I don't see this as a wise investment right now. We have much more urgent problems to tackle. And even if we didn't, I think we could get better bang for our buck by putting that amount of energy a different direction. Organizing ly/, organizing the regtests, make Patchy handle automatic countdowns, maybe start GLISS...? there's a *ton* of great projects which would be less work and would produce better rewards. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
On 4/23/12 6:25 PM, Graham Percival gra...@percival-music.ca wrote: On Tue, Apr 24, 2012 at 12:04:57AM +0200, Federico Bruni wrote: Personally, I'm a bit worried about going on with translating NR when I know that keeping it up-to-date will be an hassle. Let's manage all the doc snippets in Git and say hello to LSR import! Which are the arguments against this change? It involves work. In particular, horrible build system work, which always takes an order of magnitude longer than you might expect. If the proposal is to eliminate makelsr.py, and just manage our own snippets in Documentation/snippets, it seems to me that the primary task is to eliminate the Do not edit fields from the contents of Documentation/snippets. Is there more that I'm not aware of? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
Il 17/04/2012 23:40, Francisco Vila ha scritto: 2012/4/17 Federico Brunifedel...@gmail.com: Another solution could be keeping the current structure and changing only check-translation.py so that, when looking at the files in Documentation/snippets, it should check only the changes inside texidoc = and doctitle = strings. Yes, I intially thougth this. What made me to discard proposing it, is that it would break the 'elegancy' of the a file is outdated, mark it as such and show the differences principle. Not a part of a file if you know what I mean. Thinking twice... I realize that the regexp would only reduce the output of check-translation but the files would still be marked as outdated for most languages, because of the committishes. So, Francisco, your solution seems like the only way to go. Do you agree? (you know I always get confused about this subject ;-)) So I believe that the best solution would be: - moving the english texidoc= and doctitle= strings in a separate directory, e.g. Documentation/texidocs/ - changing makelsr.py so that also the english strings in Documentation/texidocs are included in the snippets This implies that snippets editors will have to search the title and description of snippets in a separate file. But it's not a big hassle, as they change very rarely. How do developers feel about it? Should we create an issue in the tracker? Thanks, Federico ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
Le 21/04/2012 10:57, Federico Bruni disait : Il 17/04/2012 23:40, Francisco Vila ha scritto: 2012/4/17 Federico Brunifedel...@gmail.com: Another solution could be keeping the current structure and changing only check-translation.py so that, when looking at the files in Documentation/snippets, it should check only the changes inside texidoc = and doctitle = strings. Yes, I intially thougth this. What made me to discard proposing it, is that it would break the 'elegancy' of the a file is outdated, mark it as such and show the differences principle. Not a part of a file if you know what I mean. Thinking twice... I realize that the regexp would only reduce the output of check-translation but the files would still be marked as outdated for most languages, because of the committishes. So, Francisco, your solution seems like the only way to go. Do you agree? (you know I always get confused about this subject ;-)) So I believe that the best solution would be: - moving the english texidoc= and doctitle= strings in a separate directory, e.g. Documentation/texidocs/ - changing makelsr.py so that also the english strings in Documentation/texidocs are included in the snippets This makes me believe it would be a good opportunity to have the English version follow the same rule as translations. Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
Hello, On 21 April 2012 10:13, Jean-Charles Malahieude lily...@orange.fr wrote: ... This makes me believe it would be a good opportunity to have the English version follow the same rule as translations. Err.. not sure what you mean by that technically but it's complicated enough with snippets as it is, to follow the translation method adds even more complexity (if the CG is anything to go by). Remember that unless you are doing this all the time (which the translators will be) it isn't that straightforward. We want to encourage contributors not push them away. From a very basic-no-progamming skill perspective, why can't we just have an extra texidoc entry in the snippet itself and add the translation manually, like we would for any updated snippet? Having another set of files to edit just to put in an explanation seems silly and now we have to link files to those as well? So in the NR we have an @snippet that links to a dir with the snippet that now has to link to a texidoc for that snippet in another dir. How is that better? In fact, why do we even need a texidoc string *inside* the snippet? I don't use one for @lilypond examples. Why not explicitly translate the snippet 'text' in the manual like we do for everything else. Wouldn't that be easier long term? James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
On Sat, Apr 21, 2012 at 11:33:49AM +0100, James wrote: Err.. not sure what you mean by that technically but it's complicated enough with snippets as it is, to follow the translation method adds even more complexity (if the CG is anything to go by). +1 We want to encourage contributors not push them away. Arguably the complexity of the current system pushes translators away, so Jean-Charles' has a point there. However, I am extremely skeptical of any major work on this part of our build system and policies. Unless you know that you know more about the build system and LSR than I do[1], I really don't recommend getting into this. I see any work on this becoming a huge time sink which probably won't end up with a simpler system anyway. [1] John Mandereau is the chief candidate for this. From a very basic-no-progamming skill perspective, why can't we just have an extra texidoc entry in the snippet itself and add the translation manually, like we would for any updated snippet? Because then it would be overwritten whenever we do a LSR import. In fact, why do we even need a texidoc string *inside* the snippet? I don't use one for @lilypond examples. Because snippets come from LSR, and that needs a texidoc to display some text for the snippet. I really don't see any way to rescue the snippet system. It was a gamble that hasn't paid off; it was supposed to be a standalone system that would let normal unprivileged users contribute to the docs with almost no oversight by anybody with git access. With all the developer effort that's gone into build and maintaing it, we could have made it easier to do stuff in git and/or trained more doc editors. I view any major effort on the snippets as throwing good money after bad. Or, to put it more technically, it's reached the level of the sunk cost fallacy. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
Le 21/04/2012 12:33, James disait : Hello, On 21 April 2012 10:13, Jean-Charles Malahieudelily...@orange.fr wrote: ... This makes me believe it would be a good opportunity to have the English version follow the same rule as translations. Err.. not sure what you mean by that technically but it's complicated enough with snippets as it is, to follow the translation method adds even more complexity (if the CG is anything to go by). Remember that unless you are doing this all the time (which the translators will be) it isn't that straightforward. I mean that the tree should be the same for every language, or more precisely for every part of the documentation which might be translated. In my opinion, it is not well ordered when I see that text.itely does not lie at the same level when in English than in Czech or Chinese or French. We should keep, and why not move it in a Common or Shared subdir, all the material that is not supposed to be translated (CG and the non annotated pictures or headwords examples) as it is, and adopt the same tree for the normal documentations. Another way to go, but without my preference, would be do discard the directory per language structure and add a language suffix and have something like Documentation/learning/tweaks.LL.itely We want to encourage contributors not push them away. Agreed. It goes even worse for the translator's community! Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Regarding LSR translation work
Hello all, As you know, we translators are constantly aware of how much pendant work we have, thanks to 'make check-translation'. For example, right now cd Documentation make ISOLANG=es check-translation | wc -l gives ten thousand lines as result, most of them from Documentation/snippets/. The annoying thing is, 99 percent of this output is not relevant, yet it has to be reviewed by hand. The wrong concept involved in our LSR translation-checking process is that any translators' work counts as pendant work for others. This is so because we have translations to all languages mixed in the same files which, if they change, count as, well, modified files. This is a loop and leads to absurdity. I do a local makelsr and commit a huge patch, only to mark all snippets/* as outdated for the rest of translators, which in turn can only fix this with a huge patch. I'd like to propose an issue aimed to fix it. In my opinion, English text for snippets should be kept apart with no translations in the same files. If code for the snippet is in the same file, check-translation should be smart enough to ignore it. Doc build process could take originals from there, and take translations from where they currently are, namely ll/texidocs. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
Le 17/04/2012 11:46, Francisco Vila disait : Hello all, As you know, we translators are constantly aware of how much pendant work we have, thanks to 'make check-translation'. For example, right now cd Documentation make ISOLANG=es check-translation | wc -l gives ten thousand lines as result, most of them from Documentation/snippets/. The annoying thing is, 99 percent of this output is not relevant, yet it has to be reviewed by hand. The wrong concept involved in our LSR translation-checking process is that any translators' work counts as pendant work for others. This is so because we have translations to all languages mixed in the same files which, if they change, count as, well, modified files. This is a loop and leads to absurdity. I do a local makelsr and commit a huge patch, only to mark all snippets/* as outdated for the rest of translators, which in turn can only fix this with a huge patch. And you then have to run again the merry-go-round! I'd like to propose an issue aimed to fix it. In my opinion, English text for snippets should be kept apart with no translations in the same files. If code for the snippet is in the same file, check-translation should be smart enough to ignore it. Doc build process could take originals from there, and take translations from where they currently are, namelyll/texidocs. This might as well solve this unfortunate problem we have regarding the impossibility to link to Snippets, and why not allow to have it translated (most of its content being already translated when in other manuals). Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
Hi Francisco, thanks for bringing this to the attention of developers! Il 17/04/2012 11:46, Francisco Vila ha scritto: Hello all, As you know, we translators are constantly aware of how much pendant work we have, thanks to 'make check-translation'. For example, right now cd Documentation make ISOLANG=es check-translation | wc -l gives ten thousand lines as result, most of them from Documentation/snippets/. The annoying thing is, 99 percent of this output is not relevant, yet it has to be reviewed by hand. The list of files is given by: make ISOLANG=es check-translation | grep 'diff git' Well, looking at this output I'm so happy that I've not translated as much as you did :-) The wrong concept involved in our LSR translation-checking process is that any translators' work counts as pendant work for others. This is so because we have translations to all languages mixed in the same files which, if they change, count as, well, modified files. This is a loop and leads to absurdity. I do a local makelsr and commit a huge patch, only to mark all snippets/* as outdated for the rest of translators, which in turn can only fix this with a huge patch. I'd like to propose an issue aimed to fix it. In my opinion, English text for snippets should be kept apart with no translations in the same files. If code for the snippet is in the same file, check-translation should be smart enough to ignore it. Doc build process could take originals from there, and take translations from where they currently are, namelyll/texidocs. Another solution could be keeping the current structure and changing only check-translation.py so that, when looking at the files in Documentation/snippets, it should check only the changes inside texidoc = and doctitle = strings. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
2012/4/17 Federico Bruni fedel...@gmail.com: Another solution could be keeping the current structure and changing only check-translation.py so that, when looking at the files in Documentation/snippets, it should check only the changes inside texidoc = and doctitle = strings. Yes, I intially thougth this. What made me to discard proposing it, is that it would break the 'elegancy' of the a file is outdated, mark it as such and show the differences principle. Not a part of a file if you know what I mean. But thanks, let's hope all ideas contribute to a solution sooner or later. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
