Re: LyX version 2.3.0 (beta 1)
Kornel Benko wrote: > We may want to unify the output of msgmerge to possibly minimize the > differences in po-files. We tried and were not capable to unify it on Uwe's box, I am not going into the same debate again so it's completely your call. P
Re: LyX version 2.3.0 (beta 1)
Am Montag, 4. September 2017 um 02:28:33, schrieb Scott Kostyshak> On Sun, Sep 03, 2017 at 11:11:55PM +0200, Kornel Benko wrote: > > Am Donnerstag, 31. August 2017 um 13:07:46, schrieb Pavel Sanda > > > > > Scott Kostyshak wrote: > > > > > I did not make any stats, cherrypicking single commit (likely close > > > > > to worst-case) gives me uncompressed 45 megs in blobs: > > > > > $ git diff-tree -r -c -M -C --no-commit-id cf5d9e1 |acut -f 4 | git > > > > > cat-file --batch-check |acut -f 3|asum > > > > > 45175575 > > > > > > > > 45MB for all gmo commits ever? That does not seem bad at all to me. Good > > > > to know. > > > > > > No, 45MB uncompressed per _single_ commit. P > > > > We may want to unify the output of msgmerge to possibly minimize the > > differences in po-files. > > For instance while remerging using '--width� --sort-output' may create the > > same output on all platforms. > > I'm open to anything, but if there's something you want me specifically > to do, please let me know the exact steps. > > Scott Like the attached. (Not tested for automake) The expected effect is big commit at next remerge (po-files only, no need to remerge the gmo files too). It should pay of on later remerges. Korneldiff --git a/development/cmake/modules/FindLyXGettext.cmake b/development/cmake/modules/FindLyXGettext.cmake index 8533cbf..3e8a9b0 100755 --- a/development/cmake/modules/FindLyXGettext.cmake +++ b/development/cmake/modules/FindLyXGettext.cmake @@ -51,7 +51,7 @@ MACRO(GETTEXT_CREATE_TRANSLATIONS _potFile _firstPoFile) ADD_CUSTOM_COMMAND( OUTPUT ${_gmoFile} - COMMAND ${GETTEXT_MSGMERGE_EXECUTABLE} --quiet --update --backup=none ${_absFile} ${_absPotFile} + COMMAND ${GETTEXT_MSGMERGE_EXECUTABLE} --quiet --update --backup=none --width --sort-output ${_absFile} ${_absPotFile} COMMAND ${GETTEXT_MSGFMT_EXECUTABLE} -c --statistics -o ${_gmoFile}.1 ${_absFile} COMMAND ${CMAKE_COMMAND} -E rename ${_gmoFile}.1 ${_gmoFile} DEPENDS ${_absPotFile} ${_absFile} diff --git a/po/Makevars.template b/po/Makevars.template index 0648ec7..c318c89 100644 --- a/po/Makevars.template +++ b/po/Makevars.template @@ -63,7 +63,7 @@ MSGMERGE_OPTIONS # If you want to disable line wrapping when writing PO files, add # --no-wrap to MSGMERGE_OPTIONS, XGETTEXT_OPTIONS, and # MSGINIT_OPTIONS. -MSGINIT_OPTIONS +MSGINIT_OPTIONS = --width --sort-output # This tells whether or not to regenerate a PO file when $(DOMAIN).pot # has changed. Possible values are "yes" and "no". Set this to no if signature.asc Description: This is a digitally signed message part.
Re: LyX version 2.3.0 (beta 1)
On Sun, Sep 03, 2017 at 11:11:55PM +0200, Kornel Benko wrote: > Am Donnerstag, 31. August 2017 um 13:07:46, schrieb Pavel Sanda >> > Scott Kostyshak wrote: > > > > I did not make any stats, cherrypicking single commit (likely close to > > > > worst-case) gives me uncompressed 45 megs in blobs: > > > > $ git diff-tree -r -c -M -C --no-commit-id cf5d9e1 |acut -f 4 | git > > > > cat-file --batch-check |acut -f 3|asum > > > > 45175575 > > > > > > 45MB for all gmo commits ever? That does not seem bad at all to me. Good > > > to know. > > > > No, 45MB uncompressed per _single_ commit. P > > We may want to unify the output of msgmerge to possibly minimize the > differences in po-files. > For instance while remerging using '--width=80 --sort-output' may create the > same output on all platforms. I'm open to anything, but if there's something you want me specifically to do, please let me know the exact steps. Scott signature.asc Description: PGP signature
Re: LyX version 2.3.0 (beta 1)
Am Donnerstag, 31. August 2017 um 13:07:46, schrieb Pavel Sanda> Scott Kostyshak wrote: > > > I did not make any stats, cherrypicking single commit (likely close to > > > worst-case) gives me uncompressed 45 megs in blobs: > > > $ git diff-tree -r -c -M -C --no-commit-id cf5d9e1 |acut -f 4 | git > > > cat-file --batch-check |acut -f 3|asum > > > 45175575 > > > > 45MB for all gmo commits ever? That does not seem bad at all to me. Good > > to know. > > No, 45MB uncompressed per _single_ commit. P We may want to unify the output of msgmerge to possibly minimize the differences in po-files. For instance while remerging using '--width=80 --sort-output' may create the same output on all platforms. Kornel signature.asc Description: This is a digitally signed message part.
Re: LyX version 2.3.0 (beta 1)
On Thu, Aug 31, 2017 at 01:07:46PM +0200, Pavel Sanda wrote: > Scott Kostyshak wrote: > > > I did not make any stats, cherrypicking single commit (likely close to > > > worst-case) gives me uncompressed 45 megs in blobs: > > > $ git diff-tree -r -c -M -C --no-commit-id cf5d9e1 |acut -f 4 | git > > > cat-file --batch-check |acut -f 3|asum > > > 45175575 > > > > 45MB for all gmo commits ever? That does not seem bad at all to me. Good > > to know. > > No, 45MB uncompressed per _single_ commit. P Ah, thanks for the clarification. Scott signature.asc Description: PGP signature
Re: LyX version 2.3.0 (beta 1)
Scott Kostyshak wrote: > > I did not make any stats, cherrypicking single commit (likely close to > > worst-case) gives me uncompressed 45 megs in blobs: > > $ git diff-tree -r -c -M -C --no-commit-id cf5d9e1 |acut -f 4 | git > > cat-file --batch-check |acut -f 3|asum > > 45175575 > > 45MB for all gmo commits ever? That does not seem bad at all to me. Good > to know. No, 45MB uncompressed per _single_ commit. P
Re: LyX version 2.3.0 (beta 1)
On Wed, Aug 30, 2017 at 04:48:36PM +0200, Pavel Sanda wrote: > Scott Kostyshak wrote: > > > b) git archive become easily huge just because of such changes > > > > Do frequent commits of .gmo files significantly increase git archive? > > I did not make any stats, cherrypicking single commit (likely close to > worst-case) gives me uncompressed 45 megs in blobs: > $ git diff-tree -r -c -M -C --no-commit-id cf5d9e1 |acut -f 4 | git > cat-file --batch-check |acut -f 3|asum > 45175575 45MB for all gmo commits ever? That does not seem bad at all to me. Good to know. Scott signature.asc Description: PGP signature
Re: LyX version 2.3.0 (beta 1)
On 08/30/2017 04:32 AM, Scott Kostyshak wrote: > On Mon, Aug 28, 2017 at 11:08:52PM +0200, Pavel Sanda wrote: >> Scott Kostyshak wrote: >>> I think I have a fundamental misunderstanding. I thought that strings >>> were supposed to be remerged before asking translators for translations. >>> Then the translator returns the po file, and the po and the >>> corresponding gmo files are committed. What is the purpose of remerging >>> strings before a release? I was spoiled during 2.2.0 because I think >>> Georg and Uwe took care of all translation-related issues. That ended up >>> being a mistake because I realize that it is important for the release >>> manager to know all parts of the process, so I'm trying to learn. >> 1. Whenever new UI string is added or changed this change will propagate >> into .po files only via remerging strings. >> 2. Whenever new remerge is done *lot* of irrelevant stuff (i.e. source code >> lines for string) changes as well - resulting into huge diff. >>It gets even worse if different people do remerges because different >> archs produce slightly different formatting, resulting into even bigger >> patch (didn't check but we can easily talk megabytes per commit here). >> >> Point 1 implies it is good to remerge strings when you want translators >> working on up-to-date UI and if string change occurs (i.e. our minted flame). >> Point 2 implies you don't want to do it more often except when really >> neccessary because >> a) it creates hell when you do detailed seach through commit history via git >> log -p > Workaround (which does not negate your point of course since it is a > pain to remember): > > git log -p -- . ":(exclude)*.po" # git config alias.lognopo "log -p -- . ':(exclude)*.po'" # git lognopo Richard
Re: LyX version 2.3.0 (beta 1)
Scott Kostyshak wrote: > > b) git archive become easily huge just because of such changes > > Do frequent commits of .gmo files significantly increase git archive? I did not make any stats, cherrypicking single commit (likely close to worst-case) gives me uncompressed 45 megs in blobs: $ git diff-tree -r -c -M -C --no-commit-id cf5d9e1 |acut -f 4 | git cat-file --batch-check |acut -f 3|asum 45175575 You get similar size when looking at patch size: $ git show --binary cf5d9e1 > /tmp/patch $ ls -lh /tmp/patch -rw-r--r-- 1 xxx xxx 43M Aug 30 16:44 /tmp/patch $ tgz /tmp/patch #quick compress -rw-r--r-- 1 xxx xxx 11M Aug 30 16:46 patch.tgz Pavel
Re: LyX version 2.3.0 (beta 1)
On Mon, Aug 28, 2017 at 11:08:52PM +0200, Pavel Sanda wrote: > Scott Kostyshak wrote: > > I think I have a fundamental misunderstanding. I thought that strings > > were supposed to be remerged before asking translators for translations. > > Then the translator returns the po file, and the po and the > > corresponding gmo files are committed. What is the purpose of remerging > > strings before a release? I was spoiled during 2.2.0 because I think > > Georg and Uwe took care of all translation-related issues. That ended up > > being a mistake because I realize that it is important for the release > > manager to know all parts of the process, so I'm trying to learn. > > 1. Whenever new UI string is added or changed this change will propagate into > .po files only via remerging strings. > 2. Whenever new remerge is done *lot* of irrelevant stuff (i.e. source code > lines for string) changes as well - resulting into huge diff. >It gets even worse if different people do remerges because different archs > produce slightly different formatting, resulting into even bigger patch > (didn't check but we can easily talk megabytes per commit here). > > Point 1 implies it is good to remerge strings when you want translators > working on up-to-date UI and if string change occurs (i.e. our minted flame). > Point 2 implies you don't want to do it more often except when really > neccessary because > a) it creates hell when you do detailed seach through commit history via git > log -p Workaround (which does not negate your point of course since it is a pain to remember): git log -p -- . ":(exclude)*.po" > b) git archive become easily huge just because of such changes Do frequent commits of .gmo files significantly increase git archive? > So one has to find certain compromise between 1/2. I would say that when you > are close to release/string freeze then any string change is worth to remerge > & commit. > Also this time it's little easier because you already branched 2.3 so any > number of remerges won't spoil master history. > You can test necessity of remerge by checking stats in remerge (number of > translated/fuzzy/untranslated strings changes for some language which is not > under extreme care of maintainers who can do remerges of their language only > - typical case of de,sk,fr?,it?). > If you don't detect changes in stats, there is no need to remerge for > realease just to update code lines, because remerge IIRC happens > automatically inside tarball creation machinery. > If you finally kick JMarc to give you svn access, regularly updated > translation status web page might be handy for you. > > Ask if you have any question, Thanks a lot for that detailed explanation. I will be more careful with this, and am now building up a better understanding. Scott signature.asc Description: PGP signature
Re: LyX version 2.3.0 (beta 1)
On Thu, Aug 17, 2017 at 8:25 PM, Scott Kostyshakwrote: > Public release of LyX version 2.3.0beta1 > > > Ubuntu 'lyx2.3pre' packages are now available on the Development PPA: https://launchpad.net/~lyx-devel/+archive/ubuntu/daily The packages install independently of your existing stable 2.2.x installation. Regards, Liviu > We are proud to announce the first public beta of the new LyX 2.3 series. > This pre-release is meant for testing and should not be used for serious > work. > For curious users who would like to test in order to help catch bugs before > the 2.3.0 release, please back up all of your documents and be prepared for > the worst to happen. Most users (who desire a stable LyX version) should > not > use this pre-release. > > The 2.3 series has a rich set of new features compared to the current > stable > series. An overview of the new features can be found here: > > http://wiki.lyx.org/LyX/NewInLyX23 > > You can download LyX 2.3.0beta1 from ftp://ftp.lyx.org/pub/lyx/devel/. > > We appreciate your help in testing this pre-release! > > The file lib/RELEASE-NOTES lists some known issues and problems compared > to the current stable releases (LyX 2.2.x). We strongly recommend that > packagers of LyX on various platforms and distributions read this file. > > As with any major release, this one comes with a lot of new features but > also some bugs. If you think you have found a bug in LyX 2.3.0beta1, either > email the LyX developers' mailing list (lyx-devel at lists.lyx.org), > or open a bug report at https://www.lyx.org/trac/wiki/BugTrackerHome. > Please specify if the behavior you are reporting is different from behavior > in a previous LyX version. > > If you have trouble using LyX or have a question, consult the > documentation that comes with LyX (under Help) and the LyX wiki, which you > will find at https://wiki.lyx.org/. You can also send email to the LyX > users' > list (lyx-users at lists.lyx.org). > > The LyX team. > https://www.lyx.org > >
Re: LyX version 2.3.0 (beta 1)
Scott Kostyshak wrote: > I think I have a fundamental misunderstanding. I thought that strings > were supposed to be remerged before asking translators for translations. > Then the translator returns the po file, and the po and the > corresponding gmo files are committed. What is the purpose of remerging > strings before a release? I was spoiled during 2.2.0 because I think > Georg and Uwe took care of all translation-related issues. That ended up > being a mistake because I realize that it is important for the release > manager to know all parts of the process, so I'm trying to learn. 1. Whenever new UI string is added or changed this change will propagate into .po files only via remerging strings. 2. Whenever new remerge is done *lot* of irrelevant stuff (i.e. source code lines for string) changes as well - resulting into huge diff. It gets even worse if different people do remerges because different archs produce slightly different formatting, resulting into even bigger patch (didn't check but we can easily talk megabytes per commit here). Point 1 implies it is good to remerge strings when you want translators working on up-to-date UI and if string change occurs (i.e. our minted flame). Point 2 implies you don't want to do it more often except when really neccessary because a) it creates hell when you do detailed seach through commit history via git log -p b) git archive become easily huge just because of such changes So one has to find certain compromise between 1/2. I would say that when you are close to release/string freeze then any string change is worth to remerge & commit. Also this time it's little easier because you already branched 2.3 so any number of remerges won't spoil master history. You can test necessity of remerge by checking stats in remerge (number of translated/fuzzy/untranslated strings changes for some language which is not under extreme care of maintainers who can do remerges of their language only - typical case of de,sk,fr?,it?). If you don't detect changes in stats, there is no need to remerge for realease just to update code lines, because remerge IIRC happens automatically inside tarball creation machinery. If you finally kick JMarc to give you svn access, regularly updated translation status web page might be handy for you. Ask if you have any question, Pavel
Re: LyX version 2.3.0 (beta 1)
On 08/28/2017 01:09 AM, Scott Kostyshak wrote: > On Sun, Aug 27, 2017 at 03:23:42AM +0200, Pavel Sanda wrote: >> Scott Kostyshak wrote: >>> Public release of LyX version 2.3.0beta1 >> Scott, did you put on lyx wiki the release steps you are using when >> releasing tarballs? >> (If not, can you share it there?) > I just updated the wiki with the basic steps I am doing. I will try to > keep it updated as I make corrections (as it seems I should in the case > of merging strings). > > https://wiki.lyx.org/Devel/ReleaseProcedure#toc1 > > I hope to eventually organize all of my notes. I have some that are > organized as "only for alpha1", "only for beta1", etc., and other > informal things to check (e.g. for pre-releases use a different, > scarier, form of ANNOUNCE). > >> It seems strings were not properly remerged for beta. > I think I have a fundamental misunderstanding. I thought that strings > were supposed to be remerged before asking translators for translations. > Then the translator returns the po file, and the po and the > corresponding gmo files are committed. What is the purpose of remerging > strings before a release? I was spoiled during 2.2.0 because I think > Georg and Uwe took care of all translation-related issues. That ended up > being a mistake because I realize that it is important for the release > manager to know all parts of the process, so I'm trying to learn. I don't know the answer to this, but I do remerge strings before doing the mainteance releases, mostly because it said to do so on the wiki. (I've updated a lot of that myself now, so it's not as I found it.) Richard
Re: LyX version 2.3.0 (beta 1)
On Sun, Aug 27, 2017 at 03:23:42AM +0200, Pavel Sanda wrote: > Scott Kostyshak wrote: > > Public release of LyX version 2.3.0beta1 > > Scott, did you put on lyx wiki the release steps you are using when releasing > tarballs? > (If not, can you share it there?) I just updated the wiki with the basic steps I am doing. I will try to keep it updated as I make corrections (as it seems I should in the case of merging strings). https://wiki.lyx.org/Devel/ReleaseProcedure#toc1 I hope to eventually organize all of my notes. I have some that are organized as "only for alpha1", "only for beta1", etc., and other informal things to check (e.g. for pre-releases use a different, scarier, form of ANNOUNCE). > It seems strings were not properly remerged for beta. I think I have a fundamental misunderstanding. I thought that strings were supposed to be remerged before asking translators for translations. Then the translator returns the po file, and the po and the corresponding gmo files are committed. What is the purpose of remerging strings before a release? I was spoiled during 2.2.0 because I think Georg and Uwe took care of all translation-related issues. That ended up being a mistake because I realize that it is important for the release manager to know all parts of the process, so I'm trying to learn. Scott signature.asc Description: PGP signature
Re: LyX version 2.3.0 (beta 1)
Scott Kostyshak wrote: > Public release of LyX version 2.3.0beta1 Scott, did you put on lyx wiki the release steps you are using when releasing tarballs? (If not, can you share it there?) It seems strings were not properly remerged for beta. Pavel
Re: LyX version 2.3.0 (beta 1)
On Thu, Aug 24, 2017 at 09:41:44AM +0200, Enrico Forestieri wrote: > On Wed, Aug 23, 2017 at 09:38:04AM +0200, Enrico Forestieri wrote: > > Miscellaneous, I would say. > > I added it. Thanks, Scott signature.asc Description: PGP signature
Re: LyX version 2.3.0 (beta 1)
On Wed, Aug 23, 2017 at 09:38:04AM +0200, Enrico Forestieri wrote: > On Tue, Aug 22, 2017 at 10:33:51PM -0400, Scott Kostyshak wrote: > > On Fri, Aug 18, 2017 at 01:47:59AM -0400, Scott Kostyshak wrote: > > > On Thu, Aug 17, 2017 at 09:06:06PM +0200, Tommaso Cucinotta wrote: > > > > On 17/08/2017 20:25, Scott Kostyshak wrote: > > > > > An overview of the new features can be found here: > > > > > > > > > >http://wiki.lyx.org/LyX/NewInLyX23 > > > > > > > > AFAICR, the new shell-escape [+minted] support made it to the 2.3, but > > > > it's not mentioned (yet). > > > > > > Indeed, please feel free to put it. Or if you prefer that I do it that's > > > fine too. > > > > We do have the entry > > > > "Option to use the LaTeX package minted for the typesetting of code > > listings." > > > > We could add the shell-escape feature as a separate entry, but I'm not > > sure what we would put as the description. Something like the following? > > > > -shell-escape can now be enabled only for specific documents, rather > > than having to enable it globally in preferences. > > > > Which category should we put it? Miscellaneous or "Image formats and > > conversion"? > > Miscellaneous, I would say. I added it. -- Enrico
Re: LyX version 2.3.0 (beta 1)
On Tue, Aug 22, 2017 at 10:33:51PM -0400, Scott Kostyshak wrote: > On Fri, Aug 18, 2017 at 01:47:59AM -0400, Scott Kostyshak wrote: > > On Thu, Aug 17, 2017 at 09:06:06PM +0200, Tommaso Cucinotta wrote: > > > On 17/08/2017 20:25, Scott Kostyshak wrote: > > > > An overview of the new features can be found here: > > > > > > > >http://wiki.lyx.org/LyX/NewInLyX23 > > > > > > AFAICR, the new shell-escape [+minted] support made it to the 2.3, but > > > it's not mentioned (yet). > > > > Indeed, please feel free to put it. Or if you prefer that I do it that's > > fine too. > > We do have the entry > > "Option to use the LaTeX package minted for the typesetting of code > listings." > > We could add the shell-escape feature as a separate entry, but I'm not > sure what we would put as the description. Something like the following? > > -shell-escape can now be enabled only for specific documents, rather > than having to enable it globally in preferences. > > Which category should we put it? Miscellaneous or "Image formats and > conversion"? Miscellaneous, I would say. -- Enrico
Re: LyX version 2.3.0 (beta 1)
On Fri, Aug 18, 2017 at 01:47:59AM -0400, Scott Kostyshak wrote: > On Thu, Aug 17, 2017 at 09:06:06PM +0200, Tommaso Cucinotta wrote: > > On 17/08/2017 20:25, Scott Kostyshak wrote: > > > An overview of the new features can be found here: > > > > > >http://wiki.lyx.org/LyX/NewInLyX23 > > > > AFAICR, the new shell-escape [+minted] support made it to the 2.3, but it's > > not mentioned (yet). > > Indeed, please feel free to put it. Or if you prefer that I do it that's > fine too. We do have the entry "Option to use the LaTeX package minted for the typesetting of code listings." We could add the shell-escape feature as a separate entry, but I'm not sure what we would put as the description. Something like the following? -shell-escape can now be enabled only for specific documents, rather than having to enable it globally in preferences. Which category should we put it? Miscellaneous or "Image formats and conversion"? Scott signature.asc Description: PGP signature
Re: LyX version 2.3.0 (beta 1)
On Thu, Aug 17, 2017 at 09:06:06PM +0200, Tommaso Cucinotta wrote: > On 17/08/2017 20:25, Scott Kostyshak wrote: > > An overview of the new features can be found here: > > > >http://wiki.lyx.org/LyX/NewInLyX23 > > AFAICR, the new shell-escape [+minted] support made it to the 2.3, but it's > not mentioned (yet). Indeed, please feel free to put it. Or if you prefer that I do it that's fine too. Thanks for pointing it out, Scott signature.asc Description: PGP signature
Re: LyX version 2.3.0 (beta 1)
On 17/08/2017 20:25, Scott Kostyshak wrote: An overview of the new features can be found here: http://wiki.lyx.org/LyX/NewInLyX23 AFAICR, the new shell-escape [+minted] support made it to the 2.3, but it's not mentioned (yet). T.
LyX version 2.3.0 (beta 1)
Public release of LyX version 2.3.0beta1 We are proud to announce the first public beta of the new LyX 2.3 series. This pre-release is meant for testing and should not be used for serious work. For curious users who would like to test in order to help catch bugs before the 2.3.0 release, please back up all of your documents and be prepared for the worst to happen. Most users (who desire a stable LyX version) should not use this pre-release. The 2.3 series has a rich set of new features compared to the current stable series. An overview of the new features can be found here: http://wiki.lyx.org/LyX/NewInLyX23 You can download LyX 2.3.0beta1 from ftp://ftp.lyx.org/pub/lyx/devel/. We appreciate your help in testing this pre-release! The file lib/RELEASE-NOTES lists some known issues and problems compared to the current stable releases (LyX 2.2.x). We strongly recommend that packagers of LyX on various platforms and distributions read this file. As with any major release, this one comes with a lot of new features but also some bugs. If you think you have found a bug in LyX 2.3.0beta1, either email the LyX developers' mailing list (lyx-devel at lists.lyx.org), or open a bug report at https://www.lyx.org/trac/wiki/BugTrackerHome. Please specify if the behavior you are reporting is different from behavior in a previous LyX version. If you have trouble using LyX or have a question, consult the documentation that comes with LyX (under Help) and the LyX wiki, which you will find at https://wiki.lyx.org/. You can also send email to the LyX users' list (lyx-users at lists.lyx.org). The LyX team. https://www.lyx.org signature.asc Description: PGP signature