lilypad is localized?
I can't remember if LilyPad for Windows is localized and I don't have Windows machines to test it myself. Just to know if I should translate the lilypad menus in the Documentation or not. Thanks Federico ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypad is localized?
Federico Bruni fedel...@gmail.com writes: I can't remember if LilyPad for Windows is localized and I don't have Windows machines to test it myself. Just to know if I should translate the lilypad menus in the Documentation or not. That question is easy to answer: _you_ should not translate the Lilypad menus in the documentation: we don't want the menus in the documentation look different from what the user would see on his computer. So the real question _if_ it is localized is how you can figure out the translations used in the localized versions so that you can _copy_ them into the documentation and/or put better translations in _both_ places. Graham? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypad is localized?
On Sat, Sep 28, 2013 at 08:24:13AM +0200, David Kastrup wrote: So the real question _if_ it is localized is how you can figure out the translations used in the localized versions so that you can _copy_ them into the documentation and/or put better translations in _both_ places. Graham? I have a very vague memory of seeing different language pngs in Documentation/pictures/, but that's it. I certainly have no direct knowledge of windows lilypad. If there's nothing obvious in Documentation/pictures/ then I'd just assume there's no localization. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypad is localized?
- Original Message - From: Graham Percival gra...@percival-music.ca To: David Kastrup d...@gnu.org Cc: lilypond-devel lilypond-devel@gnu.org Sent: Saturday, September 28, 2013 8:26 AM Subject: Re: lilypad is localized? On Sat, Sep 28, 2013 at 08:24:13AM +0200, David Kastrup wrote: So the real question _if_ it is localized is how you can figure out the translations used in the localized versions so that you can _copy_ them into the documentation and/or put better translations in _both_ places. Graham? I have a very vague memory of seeing different language pngs in Documentation/pictures/, but that's it. I certainly have no direct knowledge of windows lilypad. If there's nothing obvious in Documentation/pictures/ then I'd just assume there's no localization. - Graham I believe lilypad for Windows is localised - see https://github.com/gperciva/lilypad/tree/master/windows All those .rc files are Windows resource files in different languages. I've no idea how it works, though. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypad is localized?
2013/9/28 Phil Holmes m...@philholmes.net I believe lilypad for Windows is localised - see https://github.com/gperciva/**lilypad/tree/master/windowshttps://github.com/gperciva/lilypad/tree/master/windows All those .rc files are Windows resource files in different languages. I've no idea how it works, though. I think I can test it later I've just remembered that I have a virtualbox file with Windows inside ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add backup option to convert-ly (Issue 3572) (issue 14040043)
Please review. https://codereview.appspot.com/14040043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
LSR imports and version numbers?
Hi, I've seen the last LSR import do nothing but bump the version number on a large number of files from 2.17.25 to 2.15.27. Now that's consistent with the current documentation on convert-ly which states: The following options can be given: -d,--diff-version-update increase the \version string only if the file has actually been changed. Without this option (or when any conversion has changed the file), the version header reflects the last considered conversion rule. Now this documentation was written by myself after reverse-engineering the code. But frankly, it does not make sense. If the version is not even touched unless the file is changed, then it does not make sense to update the version number to the last _considered_ conversion rather than the last version actually making a difference. _Without_ using -d, it's ok that the version header is bumped across all conversions that will not be considered in future. But it does not make sense to do that when the _trigger_ for an update is an actually happening conversion. Can we agree on that? Because if we can, it will mean that LSR imports will not keep increasing version numbers higher than necessary, I think. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR imports and version numbers?
- Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Saturday, September 28, 2013 1:25 PM Subject: LSR imports and version numbers? Hi, I've seen the last LSR import do nothing but bump the version number on a large number of files from 2.17.25 to 2.15.27. Now that's consistent with the current documentation on convert-ly which states: The following options can be given: -d,--diff-version-update increase the \version string only if the file has actually been changed. Without this option (or when any conversion has changed the file), the version header reflects the last considered conversion rule. Now this documentation was written by myself after reverse-engineering the code. But frankly, it does not make sense. If the version is not even touched unless the file is changed, then it does not make sense to update the version number to the last _considered_ conversion rather than the last version actually making a difference. _Without_ using -d, it's ok that the version header is bumped across all conversions that will not be considered in future. But it does not make sense to do that when the _trigger_ for an update is an actually happening conversion. Can we agree on that? Because if we can, it will mean that LSR imports will not keep increasing version numbers higher than necessary, I think. -- David Kastrup The bumping of version numbers is a pain for me, too - it makes it tedious to check what makelsr has _really_ done. I think we should have 2 alternatives: a) bump the version if the file is updated, and not if it hasn't or b) bump to the current version regardless. We should use a) with makelsr. There is a question in my mind as to what a) should bump the version to: i) current version; or ii) version that the update related to. Simplest is probably i). -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR imports and version numbers?
Phil Holmes m...@philholmes.net writes: The bumping of version numbers is a pain for me, too - it makes it tedious to check what makelsr has _really_ done. I think we should have 2 alternatives: a) bump the version if the file is updated, and not if it hasn't or b) bump to the current version regardless. We should use a) with makelsr. There is a question in my mind as to what a) should bump the version to: i) current version; or ii) version that the update related to. Simplest is probably i). Uh, i) is what's currently happening and it's _exactly_ what causes this annoyance. Any file imported from the LSR (which is at 2.14 or similar) that gets changed at all gets bumped up to current. Since the imports are a one-way street, we just get an increasingly larger number of files getting bumped up to current on each import. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR imports and version numbers?
- Original Message - From: David Kastrup d...@gnu.org To: Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org Sent: Saturday, September 28, 2013 1:36 PM Subject: Re: LSR imports and version numbers? Phil Holmes m...@philholmes.net writes: The bumping of version numbers is a pain for me, too - it makes it tedious to check what makelsr has _really_ done. I think we should have 2 alternatives: a) bump the version if the file is updated, and not if it hasn't or b) bump to the current version regardless. We should use a) with makelsr. There is a question in my mind as to what a) should bump the version to: i) current version; or ii) version that the update related to. Simplest is probably i). Uh, i) is what's currently happening and it's _exactly_ what causes this annoyance. Any file imported from the LSR (which is at 2.14 or similar) that gets changed at all gets bumped up to current. Since the imports are a one-way street, we just get an increasingly larger number of files getting bumped up to current on each import. -- David Kastrup Ah - OK - I understand now. I'd forgotten that we always start with old files, rather than the most recent updated file. Yes, if we can make option ii) work, it would solve this problem. I'm in favour. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR imports and version numbers?
Phil Holmes writes Saturday, September 28, 2013 2:19 PM From: David Kastrup d...@gnu.org Phil Holmes m...@philholmes.net writes: There is a question in my mind as to what a) should bump the version to: i) current version; or ii) version that the update related to. Simplest is probably i). Uh, i) is what's currently happening and it's _exactly_ what causes this annoyance. Any file imported from the LSR (which is at 2.14 or similar) that gets changed at all gets bumped up to current. Since the imports are a one-way street, we just get an increasingly larger number of files getting bumped up to current on each import. Ah - OK - I understand now. I'd forgotten that we always start with old files, rather than the most recent updated file. Yes, if we can make option ii) work, it would solve this problem. I'm in favour. Option (ii) looks the more sensible one to me too. Any snippet, not just those in LSR, is more useful if version references the earliest version of LilyPond that can correctly compile it. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add backup option to convert-ly (Issue 3572) (issue 14040043)
I'd prefer a single tilde to indicate the a backup file after the version string. https://codereview.appspot.com/14040043/diff/6001/scripts/convert-ly.py File scripts/convert-ly.py (right): https://codereview.appspot.com/14040043/diff/6001/scripts/convert-ly.py#newcode243 scripts/convert-ly.py:243: back_up = file + '.~' + str(n) + '~' back_up = file + '.' + str(n) + ~ # I think mysource.ly.0~ or myinclude.ily.45~ is just as distinctive as a # convert-ly backup file as mysource.ly.~0~ or myinclude.ily.~45~ . # The first ~ makes it harder for humans to read, and doesn't hinder programs # identifying it as a convert-ly backup file. https://codereview.appspot.com/14040043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add backup option to convert-ly (Issue 3572) (issue 14040043)
https://codereview.appspot.com/14040043/diff/6001/scripts/convert-ly.py File scripts/convert-ly.py (right): https://codereview.appspot.com/14040043/diff/6001/scripts/convert-ly.py#newcode243 scripts/convert-ly.py:243: back_up = file + '.~' + str(n) + '~' On 2013/09/29 01:00:49, Ian Hulin (gmail) wrote: back_up = file + '.' + str(n) + ~ # I think mysource.ly.0~ or myinclude.ily.45~ is just as distinctive as a # convert-ly backup file as mysource.ly.~0~ or myinclude.ily.~45~ . # The first ~ makes it harder for humans to read, and doesn't hinder programs # identifying it as a convert-ly backup file. The name here was chosen to correspond with the numbered backups of Emacs. Emacs will recognize a numbered backup file (joining the backup scheme) only when there is a good match. In addition, this makes it recognize that the real file extension is .ly rather than .45. https://codereview.appspot.com/14040043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
