Re: Book-currency feature and cost accounting
On Thursday 09 October 2014 14:30:28 Alex Aycinena wrote: > Developers, > > I am planning to add a feature to gnucash, primarily, but not > exclusively, related to currency accounting, and wanted to summarize > what I was thinking of. I would welcome feedback. > > Since version 2.4.0, GnuCash supports trading accounts as described in > 'Tutorial on multiple currency accounting' and 'Multiple currency > accounting in GnuCash' by P. Selinger (see > http://wiki.gnucash.org/wiki/Trading_Accounts). I believe Mike > Alexander added this feature. > > In his tutorial, he (P. Selinger) mentions a 'reference currency > method' as an alternative to the use of trading accounts. This is > essentially the feature I wish to add. > > Today, in file->properties->Accounts tab, you can turn "trading > accounts" on or off. I propose to change this to a selection of three > alternatives: use trading accounts, specify a 'book currency', or > neither trading accounts nor book currency. If trading accounts is > selected, it would work as implemented by Mike. If neither is > selected, it would work as gnucash does now without trading accounts > selected. So no one would be forced to use the new feature. > What benefit does the current situation (without trading accounts) have on its own compared to your new proposal ? In other words should we really keep the old way or can it be modeled in your new proposal as well by for example assuming a default currency ? Or a related question: how hard would it be to migrate an existing multi-currency book without trading accounts to your proposal ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash maint: Remove bare percent sign in taxinvoice.scm, replace with English.
On Monday 13 October 2014 13:53:51 John Ralls wrote: > commit 289bfc2aefdf203881bc3e130cc98aa720e558df > Author: Jeff Earickson > Date: Sun Oct 12 22:29:40 2014 -0400 > > Remove bare percent sign in taxinvoice.scm, replace with English. > > The bare percent sign in this string messes with po translation > files and causes difficulties compiling without backslashes and > other pain. Cleans up the English by using real words. > I'm still pondering if this patch should have been applied or not. The '10%' and '32px' are literal examples of values to enter in the text box. '10 percent' and '32 pixels' are not so the help message lost some of its helpfulness. What problems do you experience during translation ? Geert > diff --git a/src/report/business-reports/taxinvoice.scm > b/src/report/business-reports/taxinvoice.scm index 106f8d7..ce7c0ed > 100644 > --- a/src/report/business-reports/taxinvoice.scm > +++ b/src/report/business-reports/taxinvoice.scm > @@ -193,7 +193,7 @@ > (N_ "Name of a file containing a logo to be used on > the report.") "")) >(add-option (gnc:make-string-option > -displaypage optname-logo-width "f" (N_ "Width of the > logo in CSS format, e.g. 10% or 32px. Leave blank to display the logo > at its natural width. The height of the logo will be scaled > accordingly.") "")) +displaypage optname-logo-width > "f" (N_ "Width of the logo in CSS format, e.g. 10 percent or 32 > pixels. Leave blank to display the logo at its natural width. The > height of the logo will be scaled accordingly.") "")) (add-option > (gnc:make-simple-boolean-option displaypage optname-border-collapse > " > g" (N_ "Border-collapse?") #f)) (add-option > (gnc:make-string-option displaypage optname-border-color-th > "h" (N_ > "CSS color.") "black")) (add-option > (gnc:make-string-option displaypage optname-border-color-td > "i" (N_ > "CSS color.") "black")) > > > > Summary of changes: > src/engine/gnc-budget.c| 6 -- > src/report/business-reports/taxinvoice.scm | 2 +- > 2 files changed, 5 insertions(+), 3 deletions(-) > > ___ > gnucash-changes mailing list > gnucash-chan...@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-changes ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Exporting GnuCash Log from GnuCash Android
Hello everyone, At the moment, there is no easy/compatible way to import from GnuCash Android into GnuCash desktop. GnuCash Android supports both QIF and OFX, but each of them have their own issues. OFX does not support double-entry, QIF does not support multi-currencies etc etc. At the moment, we have it under consideration to implement exporting in the GnuCash log format so that it can be replayed on the desktop. This would resolve most of the issues with importing. I just want to ask if there are any pitfalls or known limitations to this approach which we may be missing. Thanks. Looking forward to your feedback. Cheers, Ngewi ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash maint: Remove bare percent sign in taxinvoice.scm, replace with English.
Geert, Well, "10 percent" and "32 pixels" are literal examples too. In my efforts on getting the Indic language translations to compile, poedit and/or the compile sequence always seems to choke on this spot. The English translation of: :... e.g. 10% or 32px" ends up in the following translated string as: "[characters in Devanagari]% [more chars] 32px [more chars]" and the compiler sees the "%" as a "bare character" when it expects "%d" or "%s" or "\%" or "%%" or something in proper C format. Compiler error. I have tried all of the usual C/perl forms of making it a compilable string, like "\%", "%%", adding a space in front of it -- no success. My usual work-around is to simply remove the percent sign, which is wrong. I am open to suggestions here. I am hoping/assuming that most languages would have some equivalent of the English word "percent" that could be used, even if it reads as "parts per hundred" in the native language. I am less concerned about changing "px" to "pixel", but I like proper English. --- Jeff Earickson On Tue, Oct 21, 2014 at 11:28 AM, Geert Janssens wrote: > On Monday 13 October 2014 13:53:51 John Ralls wrote: > > commit 289bfc2aefdf203881bc3e130cc98aa720e558df > > Author: Jeff Earickson > > Date: Sun Oct 12 22:29:40 2014 -0400 > > > > Remove bare percent sign in taxinvoice.scm, replace with English. > > > > The bare percent sign in this string messes with po translation > > files and causes difficulties compiling without backslashes and > > other pain. Cleans up the English by using real words. > > > I'm still pondering if this patch should have been applied or not. > > The '10%' and '32px' are literal examples of values to enter in the text > box. '10 percent' and '32 > pixels' are not so the help message lost some of its helpfulness. > > What problems do you experience during translation ? > > Geert > > > diff --git a/src/report/business-reports/taxinvoice.scm > > b/src/report/business-reports/taxinvoice.scm index 106f8d7..ce7c0ed > > 100644 > > --- a/src/report/business-reports/taxinvoice.scm > > +++ b/src/report/business-reports/taxinvoice.scm > > @@ -193,7 +193,7 @@ > > (N_ "Name of a file containing a logo to be used on > > the report.") "")) > >(add-option (gnc:make-string-option > > -displaypage optname-logo-width "f" (N_ "Width of the > > logo in CSS format, e.g. 10% or 32px. Leave blank to display the logo > > at its natural width. The height of the logo will be scaled > > accordingly.") "")) +displaypage optname-logo-width > > "f" (N_ "Width of the logo in CSS format, e.g. 10 percent or 32 > > pixels. Leave blank to display the logo at its natural width. The > > height of the logo will be scaled accordingly.") "")) (add-option > > (gnc:make-simple-boolean-option displaypage > optname-border-collapse " > > g" (N_ "Border-collapse?") #f)) (add-option > > (gnc:make-string-option displaypage > optname-border-color-th "h" (N_ > > "CSS color.") "black")) (add-option > > (gnc:make-string-option displaypage > optname-border-color-td "i" (N_ > > "CSS color.") "black")) > > > > > > > > Summary of changes: > > src/engine/gnc-budget.c| 6 -- > > src/report/business-reports/taxinvoice.scm | 2 +- > > 2 files changed, 5 insertions(+), 3 deletions(-) > > > > ___ > > gnucash-changes mailing list > > gnucash-chan...@gnucash.org > > https://lists.gnucash.org/mailman/listinfo/gnucash-changes > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash maint: Remove bare percent sign in taxinvoice.scm, replace with English.
But in the message to be translated, "10%" and "32px" are not English, they are CSS. Translating them as if they were English would give the wrong result -- you can't, in a Chinese-translated version, enter "10百分" into the text box specified and have it work right; it has to be "10%". The same goes with the "32px" as well. If the "%" is giving trouble, there are other CSS width specifiers that could work as alternative examples: "2em", "24pt", "1cm", etc. None are equivalent to either "10%" or "32px", but neither of those are equivalent to each other, either. On Tue, Oct 21, 2014 at 11:56 AM, Jeff Earickson wrote: > Geert, > > Well, "10 percent" and "32 pixels" are literal examples too. In my efforts > on getting the Indic language translations to compile, poedit and/or the > compile sequence always seems to choke on this spot. The English > translation of: > > :... e.g. 10% or 32px" > > ends up in the following translated string as: > > "[characters in Devanagari]% [more chars] 32px [more chars]" > > and the compiler sees the "%" as a "bare character" when it expects "%d" or > "%s" or "\%" or "%%" or something in proper C format. Compiler error. > > I have tried all of the usual C/perl forms of making it a compilable > string, like "\%", "%%", adding a space in front of it -- no success. My > usual work-around is to simply remove the percent sign, which is wrong. I > am open to suggestions here. > > I am hoping/assuming that most languages would have some equivalent of the > English word "percent" that could be used, even if it reads as "parts per > hundred" in the native language. I am less concerned about changing "px" > to "pixel", but I like proper English. > > --- Jeff Earickson > > On Tue, Oct 21, 2014 at 11:28 AM, Geert Janssens < > geert.gnuc...@kobaltwit.be > > wrote: > > > On Monday 13 October 2014 13:53:51 John Ralls wrote: > > > commit 289bfc2aefdf203881bc3e130cc98aa720e558df > > > Author: Jeff Earickson > > > Date: Sun Oct 12 22:29:40 2014 -0400 > > > > > > Remove bare percent sign in taxinvoice.scm, replace with English. > > > > > > The bare percent sign in this string messes with po translation > > > files and causes difficulties compiling without backslashes and > > > other pain. Cleans up the English by using real words. > > > > > I'm still pondering if this patch should have been applied or not. > > > > The '10%' and '32px' are literal examples of values to enter in the text > > box. '10 percent' and '32 > > pixels' are not so the help message lost some of its helpfulness. > > > > What problems do you experience during translation ? > > > > Geert > > > > > diff --git a/src/report/business-reports/taxinvoice.scm > > > b/src/report/business-reports/taxinvoice.scm index 106f8d7..ce7c0ed > > > 100644 > > > --- a/src/report/business-reports/taxinvoice.scm > > > +++ b/src/report/business-reports/taxinvoice.scm > > > @@ -193,7 +193,7 @@ > > > (N_ "Name of a file containing a logo to be used on > > > the report.") "")) > > >(add-option (gnc:make-string-option > > > -displaypage optname-logo-width "f" (N_ "Width of the > > > logo in CSS format, e.g. 10% or 32px. Leave blank to display the logo > > > at its natural width. The height of the logo will be scaled > > > accordingly.") "")) +displaypage optname-logo-width > > > "f" (N_ "Width of the logo in CSS format, e.g. 10 percent or 32 > > > pixels. Leave blank to display the logo at its natural width. The > > > height of the logo will be scaled accordingly.") "")) (add-option > > > (gnc:make-simple-boolean-option displaypage > > optname-border-collapse " > > > g" (N_ "Border-collapse?") #f)) (add-option > > > (gnc:make-string-option displaypage > > optname-border-color-th "h" (N_ > > > "CSS color.") "black")) (add-option > > > (gnc:make-string-option displaypage > > optname-border-color-td "i" (N_ > > > "CSS color.") "black")) > > > > > > > > > > > > Summary of changes: > > > src/engine/gnc-budget.c| 6 -- > > > src/report/business-reports/taxinvoice.scm | 2 +- > > > 2 files changed, 5 insertions(+), 3 deletions(-) > > > > > > ___ > > > gnucash-changes mailing list > > > gnucash-chan...@gnucash.org > > > https://lists.gnucash.org/mailman/listinfo/gnucash-changes > > > > ___ > > gnucash-devel mailing list > > gnucash-devel@gnucash.org > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash maint: Remove bare percent sign in taxinvoice.scm, replace with English.
Could you provide the exact compiler error you get, including the commands to reproduce it? -derek Sent on my mobile. Please forgive any typos. - Reply message - From: "Jeff Earickson" To: "Geert Janssens" Cc: "Gnucash-devel" Subject: gnucash maint: Remove bare percent sign in taxinvoice.scm, replace with English. Date: Tue, Oct 21, 2014 11:56 AM Geert, Well, "10 percent" and "32 pixels" are literal examples too. In my efforts on getting the Indic language translations to compile, poedit and/or the compile sequence always seems to choke on this spot. The English translation of: :... e.g. 10% or 32px" ends up in the following translated string as: "[characters in Devanagari]% [more chars] 32px [more chars]" and the compiler sees the "%" as a "bare character" when it expects "%d" or "%s" or "\%" or "%%" or something in proper C format. Compiler error. I have tried all of the usual C/perl forms of making it a compilable string, like "\%", "%%", adding a space in front of it -- no success. My usual work-around is to simply remove the percent sign, which is wrong. I am open to suggestions here. I am hoping/assuming that most languages would have some equivalent of the English word "percent" that could be used, even if it reads as "parts per hundred" in the native language. I am less concerned about changing "px" to "pixel", but I like proper English. --- Jeff Earickson On Tue, Oct 21, 2014 at 11:28 AM, Geert Janssens wrote: > On Monday 13 October 2014 13:53:51 John Ralls wrote: > > commit 289bfc2aefdf203881bc3e130cc98aa720e558df > > Author: Jeff Earickson > > Date: Sun Oct 12 22:29:40 2014 -0400 > > > > Remove bare percent sign in taxinvoice.scm, replace with English. > > > > The bare percent sign in this string messes with po translation > > files and causes difficulties compiling without backslashes and > > other pain. Cleans up the English by using real words. > > > I'm still pondering if this patch should have been applied or not. > > The '10%' and '32px' are literal examples of values to enter in the text > box. '10 percent' and '32 > pixels' are not so the help message lost some of its helpfulness. > > What problems do you experience during translation ? > > Geert > > > diff --git a/src/report/business-reports/taxinvoice.scm > > b/src/report/business-reports/taxinvoice.scm index 106f8d7..ce7c0ed > > 100644 > > --- a/src/report/business-reports/taxinvoice.scm > > +++ b/src/report/business-reports/taxinvoice.scm > > @@ -193,7 +193,7 @@ > > (N_ "Name of a file containing a logo to be used on > > the report.") "")) > >(add-option (gnc:make-string-option > > -displaypage optname-logo-width "f" (N_ "Width of the > > logo in CSS format, e.g. 10% or 32px. Leave blank to display the logo > > at its natural width. The height of the logo will be scaled > > accordingly.") "")) +displaypage optname-logo-width > > "f" (N_ "Width of the logo in CSS format, e.g. 10 percent or 32 > > pixels. Leave blank to display the logo at its natural width. The > > height of the logo will be scaled accordingly.") "")) (add-option > > (gnc:make-simple-boolean-option displaypage > optname-border-collapse " > > g" (N_ "Border-collapse?") #f)) (add-option > > (gnc:make-string-option displaypage > optname-border-color-th "h" (N_ > > "CSS color.") "black")) (add-option > > (gnc:make-string-option displaypage > optname-border-color-td "i" (N_ > > "CSS color.") "black")) > > > > > > > > Summary of changes: > > src/engine/gnc-budget.c| 6 -- > > src/report/business-reports/taxinvoice.scm | 2 +- > > 2 files changed, 5 insertions(+), 3 deletions(-) > > > > ___ > > gnucash-changes mailing list > > gnucash-chan...@gnucash.org > > https://lists.gnucash.org/mailman/listinfo/gnucash-changes > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Security implications of loading custom reports (was: Re: Custom reports do not load after upgrade to 2.6.4 on OSX)
I have moved this thread from gnucash-user as it was getting rather technical... On Tuesday 21 October 2014 08:43:04 John Ralls wrote: > > > > > > One possible solution is to get Guile out of the file-opening > > > loop. > > > Having a configuration file that’s directly executed by Guile is a > > > rather glaring security hole; it would be much better to make it > > > an > > > ini-style file and do everything in C/C++ up to passing the > > > contents > > > of the files to a Guile function that registers them as add-on > > > reports. That’s not really a suitable change for the maint branch, > > > but we should consider it for 2.8. > > > > I understand your reasoning. However a custom report in itself is > > essentially unrestricted scheme code as well. So how is loading > > such a file via C/C++ any less of a glaring security hole than > > having it done in guile ? > It’s not if the C/C++ code just passes arbitrary code to Guile for > immediate execution. I’m proposing that the custom report should be > passed to the report-registration code instead so that the report > must be selected from the menu to execute. I'm not sure this is possible in guile only. A report is written as a guile module. Loading the module already executes code (gnc:define-report). That code can be abused do bad things when loading a custom report. Thinking further on your .ini file we could perhaps indeed split the current report in two parts: - an ini file as you propose which holds the parameters we currently set in the call to gnc:define- report - a guile module with all the functions that can be called by the report. That would reduce the execution of arbitrary code to when the report is effectively called. Note that our built-in reports use the same loading mechanism and for user-friendliness we probably want to keep only one load interface. Which means we would want to convert our built-in reports as well. Next if the goal is to prevent arbitrary code execution we will also have to rewrite the saved- report code, because it is also running a guile file from DOT_GNUCASH_DIR. And loading of stylesheets. By now it starts to look like a rewrite of the report system. Which I'm not sure I would want to do in guile again... > It would be even better if > reports could be sandboxed, but that’s probably too hard. > Agreed. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Exporting GnuCash Log from GnuCash Android
Hi, Ngewi Fet writes: > Hello everyone, > At the moment, there is no easy/compatible way to import from GnuCash > Android into GnuCash desktop. GnuCash Android supports both QIF and OFX, > but each of them have their own issues. > OFX does not support double-entry, QIF does not support multi-currencies > etc etc. > > At the moment, we have it under consideration to implement exporting in the > GnuCash log format so that it can be replayed on the desktop. This would > resolve most of the issues with importing. > > I just want to ask if there are any pitfalls or known limitations to this > approach which we may be missing. Thanks. There are a few pitfalls: 1) the log format is ad-hoc. There is no standard or even documentation. It's already changed at least once. 2) The log ONLY tracks basic transaction information. If you create new accounts that info isn't the log, and if you then create a new transaction against that new account you will get a crash. 3) The log replay performs no verification, so you could easily end up with duplicate entries or broken entries (or a crash) Is there any way you could just emit multiple QIF files, one per currency? IMHO that would be the "best". > Looking forward to your feedback. > Cheers, > > Ngewi -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Security implications of loading custom reports (was: Re: Custom reports do not load after upgrade to 2.6.4 on OSX)
On Oct 21, 2014, at 9:27 AM, Geert Janssens wrote: > I have moved this thread from gnucash-user as it was getting rather > technical... > > On Tuesday 21 October 2014 08:43:04 John Ralls wrote: > > > > > > > > One possible solution is to get Guile out of the file-opening > > > > loop. > > > > Having a configuration file that’s directly executed by Guile is a > > > > rather glaring security hole; it would be much better to make it > > > > an > > > > ini-style file and do everything in C/C++ up to passing the > > > > contents > > > > of the files to a Guile function that registers them as add-on > > > > reports. That’s not really a suitable change for the maint branch, > > > > but we should consider it for 2.8. > > > > > > I understand your reasoning. However a custom report in itself is > > > essentially unrestricted scheme code as well. So how is loading > > > such a file via C/C++ any less of a glaring security hole than > > > having it done in guile ? > > It’s not if the C/C++ code just passes arbitrary code to Guile for > > immediate execution. I’m proposing that the custom report should be > > passed to the report-registration code instead so that the report > > must be selected from the menu to execute. > > I'm not sure this is possible in guile only. A report is written as a guile > module. Loading the module already executes code (gnc:define-report). That > code can be abused do bad things when loading a custom report. Wow. That’s an incredible failure for something that’s promoted as an application scripting language. > > Thinking further on your .ini file we could perhaps indeed split the current > report in two parts: > - an ini file as you propose which holds the parameters we currently set in > the call to gnc:define-report > - a guile module with all the functions that can be called by the report. > That would reduce the execution of arbitrary code to when the report is > effectively called. > > Note that our built-in reports use the same loading mechanism and for > user-friendliness we probably want to keep only one load interface. Which > means we would want to convert our built-in reports as well. > > Next if the goal is to prevent arbitrary code execution we will also have to > rewrite the saved-report code, because it is also running a guile file from > DOT_GNUCASH_DIR. And loading of stylesheets. > > By now it starts to look like a rewrite of the report system. Which I'm not > sure I would want to do in guile again… That might be overstating it a bit, though it would require a fair amount of surgery to convert all of the existing reports. That might be doable with a bit of perl to extract the data into an ini-style file and remove the block from each report’s scheme file. Not that I like the current system: I’d prefer a report definition consisting of a query for the data feeding canned graphing and table-drawing functions with CSS to make it pretty. Depending on how the query part is implemented it might run the risk of SQL injection, but that’s less of a risk than allowing arbitrary code as we do now. I would prefer that such a thing be written in a different language from Scheme. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Book-currency feature and cost accounting
Geert, On Tue, Oct 21, 2014 at 7:25 AM, Geert Janssens wrote: > On Thursday 09 October 2014 14:30:28 Alex Aycinena wrote: > > > Developers, > > > > > > I am planning to add a feature to gnucash, primarily, but not > > > exclusively, related to currency accounting, and wanted to summarize > > > what I was thinking of. I would welcome feedback. > > > > [snip] > >If neither is > > > selected, it would work as gnucash does now without trading accounts > > > selected. So no one would be forced to use the new feature. > > > > > What benefit does the current situation (without trading accounts) have on > its own compared to your new proposal ? In other words should we really > keep the old way or can it be modeled in your new proposal as well by for > example assuming a default currency ? > > > In my personal view, none. But I don't claim to be aware of all the ways gnucash is used across its installed base. > Or a related question: how hard would it be to migrate an existing > multi-currency book without trading accounts to your proposal ? > > > > Geert > The way I am proposing to do it, an existing multi-currency book without trading accounts should have no migration issues (as long as the new feature is not turned on then back off again - in which case the 'feature kvp' would prevent it from being read by an earlier version). It would simply work the same way. At least that is my intention. I think it is much safer to put the new feature out as an option, then perhaps later, after it has been in use for some time, and adjustments made based on real world use, revisit the question as to whether the non-trading-accounts case should simply work this way (i.e., there would only be two ways rather than three, as I think you are suggesting). By not forcing users to use the new feature, we won't mess-up someone's use case that we are not aware of. Another question that could be raised later is whether (and how) lot tracking might be used in an integrated way with trading accounts after it has been in use with this new feature. It is clear in my mind how it would generally work with a book-currency; not so much with trading accounts. Regards, Alex ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Book-currency feature and cost accounting
On Sun, Oct 19, 2014 at 9:00 AM, wrote: > -- Forwarded message -- > From: Wm > To: gnucash-devel@gnucash.org > Cc: > Date: Sun, 19 Oct 2014 09:28:22 +0100 > Subject: Re: Book-currency feature and cost accounting > Mon, 13 Oct 2014 10:04:35 dlmqo229m5spxzndd79ajh8ex...@mail.gmail.com> Alex Aycinena < > alex.aycin...@gmail.com> > > [cost accounting] > > I was using the term loosely, in the context of foreign currercies > for: "accounting for the cost of foreign currencies in order to calculate > gain/losses on dispositions". The work would also apply to > commodities/securities, though. > > Re-reading your post at the top of this thread what is it that would be > achieved by what you propose ? <-- open question > Lot tracking for non-book-currency splits would be used in an integrated fashion during data entry. This would allow the system to (optionally) track costs for non-book-currency account balances with the lots and calculate gains/losses for dispositions and generate the associated splits while interacting with the user. Some (most?) of these activities can be done with the system today by using the lot viewer/scrubber. But it takes extra steps. You can also manually make sure you have a cost in what you would consider a 'book-currency' today by making sure you always enter a transaction from an account of that 'book-currency', even if no splits in the transaction involve the 'book-currency' (but you have to do some manual cost calculations before the data entry in order to have the correct amounts ahead of time); you are kind of 'faking out' the system to achieve this. > > If the gnc user has Trading accounts ON don't they have all the > transactional information available to them to report on ? <-- is there > something missing from what is recorded > > Lot tracking is not integrated. Extra steps outside of data entry are used to track costs and gain/losses. > I'm wondering if this isn't so much a new feature so much as a report that > wants to be written ? <-- did you try to write a report and gave up > > -- > Wm... > > There is (at least) one report needed and I already have a working version. To get the information on it to come out correctly, I have had to do all those extra steps I mention above. Alex ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash maint: Remove bare percent sign in taxinvoice.scm, replace with English.
Derek, Hmmm... Trying to reproduce here. Sometimes msgfmt will compile the po file fine, but poedit will complain, so the two are not consistent. In the case I just tried, poedit said: "Error: 'msgstr'' is not a valid C format string, unlike 'msgid'. Reason: the character that erminates the directive number 1 is not a valid conversion specifier." But that same exact file just compiled with msgfmt just fine. Ugh. --- Jeff A. Earickson, Ph.D Senior Server System Administrator Colby College, 4214 Mayflower Hill, Waterville ME, 04901-8842 207-859-4214 (fax 207-859-4186) Eastern Time Zone, USA --- On Tue, Oct 21, 2014 at 12:20 PM, Derek Atkins wrote: > Could you provide the exact compiler error you get, including the > commands to reproduce it? > > -derek > > Sent on my mobile. Please forgive any typos. > > - Reply message - > From: "Jeff Earickson" > To: "Geert Janssens" > Cc: "Gnucash-devel" > Subject: gnucash maint: Remove bare percent sign in taxinvoice.scm, > replace with English. > Date: Tue, Oct 21, 2014 11:56 AM > > Geert, > > Well, "10 percent" and "32 pixels" are literal examples too. In my efforts > on getting the Indic language translations to compile, poedit and/or the > compile sequence always seems to choke on this spot. The English > translation of: > > :... e.g. 10% or 32px" > > ends up in the following translated string as: > > "[characters in Devanagari]% [more chars] 32px [more chars]" > > and the compiler sees the "%" as a "bare character" when it expects "%d" or > "%s" or "\%" or "%%" or something in proper C format. Compiler error. > > I have tried all of the usual C/perl forms of making it a compilable > string, like "\%", "%%", adding a space in front of it -- no success. My > usual work-around is to simply remove the percent sign, which is wrong. I > am open to suggestions here. > > I am hoping/assuming that most languages would have some equivalent of the > English word "percent" that could be used, even if it reads as "parts per > hundred" in the native language. I am less concerned about changing "px" > to "pixel", but I like proper English. > > --- Jeff Earickson > > On Tue, Oct 21, 2014 at 11:28 AM, Geert Janssens > wrote: > > > On Monday 13 October 2014 13:53:51 John Ralls wrote: > > > commit 289bfc2aefdf203881bc3e130cc98aa720e558df > > > Author: Jeff Earickson > > > Date: Sun Oct 12 22:29:40 2014 -0400 > > > > > > Remove bare percent sign in taxinvoice.scm, replace with English. > > > > > > The bare percent sign in this string messes with po translation > > > files and causes difficulties compiling without backslashes and > > > other pain. Cleans up the English by using real words. > > > > > I'm still pondering if this patch should have been applied or not. > > > > The '10%' and '32px' are literal examples of values to enter in the text > > box. '10 percent' and '32 > > pixels' are not so the help message lost some of its helpfulness. > > > > What problems do you experience during translation ? > > > > Geert > > > > > diff --git a/src/report/business-reports/taxinvoice.scm > > > b/src/report/business-reports/taxinvoice.scm index 106f8d7..ce7c0ed > > > 100644 > > > --- a/src/report/business-reports/taxinvoice.scm > > > +++ b/src/report/business-reports/taxinvoice.scm > > > @@ -193,7 +193,7 @@ > > > (N_ "Name of a file containing a logo to be used on > > > the report.") "")) > > >(add-option (gnc:make-string-option > > > -displaypage optname-logo-width "f" (N_ "Width of the > > > logo in CSS format, e.g. 10% or 32px. Leave blank to display the logo > > > at its natural width. The height of the logo will be scaled > > > accordingly.") "")) +displaypage optname-logo-width > > > "f" (N_ "Width of the logo in CSS format, e.g. 10 percent or 32 > > > pixels. Leave blank to display the logo at its natural width. The > > > height of the logo will be scaled accordingly.") "")) (add-option > > > (gnc:make-simple-boolean-option displaypage > > optname-border-collapse " > > > g" (N_ "Border-collapse?") #f)) (add-option > > > (gnc:make-string-option displaypage > > optname-border-color-th "h" (N_ > > > "CSS color.") "black")) (add-option > > > (gnc:make-string-option displaypage > > optname-border-color-td "i" (N_ > > > "CSS color.") "black")) > > > > > > > > > > > > Summary of changes: > > > src/engine/gnc-budget.c| 6 -- > > > src/report/business-reports/taxinvoice.scm | 2 +- > > > 2 files changed, 5 insertions(+), 3 deletions(-) > > > > > > ___ > > > gnucash-changes mailing list > > > gnucash-chan...@gnucash.org > > > https://lists.gnucash.org/mailman/listinfo/gnucash-changes > > > > ___ > > gnucash-devel mailing list > > gnucash-devel@gnucash.org > > https://lists.gnucash.org
Re: gnucash maint: Remove bare percent sign in taxinvoice.scm, replace with English.
Buddha is right. It says "in CSS format" right there in the message string. Cascading Style Sheets did not register in my mind, I was too focused on the % sign. I will withdraw this in bugzilla. - Jeff Earickson On Tue, Oct 21, 2014 at 12:11 PM, Buddha Buck wrote: > But in the message to be translated, "10%" and "32px" are not English, > they are CSS. Translating them as if they were English would give the wrong > result -- you can't, in a Chinese-translated version, enter "10百分" into the > text box specified and have it work right; it has to be "10%". The same > goes with the "32px" as well. > > If the "%" is giving trouble, there are other CSS width specifiers that > could work as alternative examples: "2em", "24pt", "1cm", etc. None are > equivalent to either "10%" or "32px", but neither of those are equivalent > to each other, either. > > > On Tue, Oct 21, 2014 at 11:56 AM, Jeff Earickson > wrote: > >> Geert, >> >> Well, "10 percent" and "32 pixels" are literal examples too. In my >> efforts >> on getting the Indic language translations to compile, poedit and/or the >> compile sequence always seems to choke on this spot. The English >> translation of: >> >> :... e.g. 10% or 32px" >> >> ends up in the following translated string as: >> >> "[characters in Devanagari]% [more chars] 32px [more chars]" >> >> and the compiler sees the "%" as a "bare character" when it expects "%d" >> or >> "%s" or "\%" or "%%" or something in proper C format. Compiler error. >> >> I have tried all of the usual C/perl forms of making it a compilable >> string, like "\%", "%%", adding a space in front of it -- no success. My >> usual work-around is to simply remove the percent sign, which is wrong. I >> am open to suggestions here. >> >> I am hoping/assuming that most languages would have some equivalent of the >> English word "percent" that could be used, even if it reads as "parts per >> hundred" in the native language. I am less concerned about changing "px" >> to "pixel", but I like proper English. >> >> --- Jeff Earickson >> >> On Tue, Oct 21, 2014 at 11:28 AM, Geert Janssens < >> geert.gnuc...@kobaltwit.be >> > wrote: >> >> > On Monday 13 October 2014 13:53:51 John Ralls wrote: >> > > commit 289bfc2aefdf203881bc3e130cc98aa720e558df >> > > Author: Jeff Earickson >> > > Date: Sun Oct 12 22:29:40 2014 -0400 >> > > >> > > Remove bare percent sign in taxinvoice.scm, replace with English. >> > > >> > > The bare percent sign in this string messes with po translation >> > > files and causes difficulties compiling without backslashes and >> > > other pain. Cleans up the English by using real words. >> > > >> > I'm still pondering if this patch should have been applied or not. >> > >> > The '10%' and '32px' are literal examples of values to enter in the text >> > box. '10 percent' and '32 >> > pixels' are not so the help message lost some of its helpfulness. >> > >> > What problems do you experience during translation ? >> > >> > Geert >> > >> > > diff --git a/src/report/business-reports/taxinvoice.scm >> > > b/src/report/business-reports/taxinvoice.scm index 106f8d7..ce7c0ed >> > > 100644 >> > > --- a/src/report/business-reports/taxinvoice.scm >> > > +++ b/src/report/business-reports/taxinvoice.scm >> > > @@ -193,7 +193,7 @@ >> > > (N_ "Name of a file containing a logo to be used on >> > > the report.") "")) >> > >(add-option (gnc:make-string-option >> > > -displaypage optname-logo-width "f" (N_ "Width of the >> > > logo in CSS format, e.g. 10% or 32px. Leave blank to display the logo >> > > at its natural width. The height of the logo will be scaled >> > > accordingly.") "")) +displaypage optname-logo-width >> > > "f" (N_ "Width of the logo in CSS format, e.g. 10 percent or 32 >> > > pixels. Leave blank to display the logo at its natural width. The >> > > height of the logo will be scaled accordingly.") "")) (add-option >> > > (gnc:make-simple-boolean-option displaypage >> > optname-border-collapse " >> > > g" (N_ "Border-collapse?") #f)) (add-option >> > > (gnc:make-string-option displaypage >> > optname-border-color-th "h" (N_ >> > > "CSS color.") "black")) (add-option >> > > (gnc:make-string-option displaypage >> > optname-border-color-td "i" (N_ >> > > "CSS color.") "black")) >> > > >> > > >> > > >> > > Summary of changes: >> > > src/engine/gnc-budget.c| 6 -- >> > > src/report/business-reports/taxinvoice.scm | 2 +- >> > > 2 files changed, 5 insertions(+), 3 deletions(-) >> > > >> > > ___ >> > > gnucash-changes mailing list >> > > gnucash-chan...@gnucash.org >> > > https://lists.gnucash.org/mailman/listinfo/gnucash-changes >> > >> > ___ >> > gnucash-devel mailing list >> > gnucash-devel@gnucash.org >> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel >> > >>
Re: gnucash maint: Remove bare percent sign in taxinvoice.scm, replace with English.
Jeff, Thank you for the details. I have experimented a bit with the kok.po file. The issue is not in the % sign but in the fact that the string is marked as a c-format string. Removing this line from the comment block right above the msgid fixes the msgfmt error for that particular translation string. The c-format comment is unfortunately automatically (and erroneously) generated by xgettext while parsing guile-strings.c. This is a bug. I have a patch in my queue that can fix this. This patch however requires at least intl-tool version 0.50, which is still fairly recent. This means I can't apply the patch (yet) to our maint branch and the c-format comment will continue to pop up for the time being. To work around this until we can apply my patch, I'll redo the string in a different way in the scm file to put the examples outside of the translatable string. Note that the current kok.po file still has two other errors which are valid IMO. You can see them by running msgfmt -c on the file. Can you look into fixing these ? Some of the other Indic language files that got recently contributed have similar errors. I'll list them here for your convenience: brx.po:12727: number of format specifications in 'msgid_plural' and 'msgstr[1]' does not match brx.po:26200: 'msgstr' is not a valid C format string, unlike 'msgid'. Reason: The character that terminates the directive number 1 is not a valid conversion specifier. brx.po:30500: format specifications in 'msgid' and 'msgstr' for argument 1 are not the same brx.po:30509: format specifications in 'msgid' and 'msgstr' for argument 1 are not the same msgfmt: found 4 fatal errors kok.po:12155: 'msgstr' is not a valid C format string, unlike 'msgid'. Reason: The character that terminates the directive number 2 is not a valid conversion specifier. kok.po:19974: number of format specifications in 'msgid' and 'msgstr' does not match kok.po:26045: 'msgstr' is not a valid C format string, unlike 'msgid'. Reason: The character that terminates the directive number 1 is not a valid conversion specifier. msgfmt: found 3 fatal errors ks.po:99: number of format specifications in 'msgid' and 'msgstr' does not match ks.po:4535: number of format specifications in 'msgid' and 'msgstr' does not match ks.po:12736: number of format specifications in 'msgid_plural' and 'msgstr[1]' does not match ks.po:18093: number of format specifications in 'msgid_plural' and 'msgstr[1]' does not match ks.po:19325: number of format specifications in 'msgid' and 'msgstr' does not match ks.po:26224: 'msgstr' is not a valid C format string, unlike 'msgid'. Reason: The character that terminates the directive number 1 is not a valid conversion specifier. msgfmt: found 6 fatal errors mr.po:404: 'msgstr' is not a valid C format string, unlike 'msgid'. Reason: The character that terminates the directive number 2 is not a valid conversion specifier. mr.po:422: 'msgstr' is not a valid C format string, unlike 'msgid'. Reason: The character that terminates the directive number 2 is not a valid conversion specifier. mr.po:20309: 'msgstr' is not a valid C format string, unlike 'msgid'. Reason: In the directive number 1, the character ':' is not a valid conversion specifier. mr.po:26714: 'msgstr' is not a valid C format string, unlike 'msgid'. Reason: The character that terminates the directive number 1 is not a valid conversion specifier. msgfmt: found 4 fatal errors ta.po:26932: 'msgstr' is not a valid C format string, unlike 'msgid'. Reason: The character that terminates the directive number 1 is not a valid conversion specifier. msgfmt: found 1 fatal error te.po:12659: number of format specifications in 'msgid_plural' and 'msgstr[1]' does not match te.po:18572: number of format specifications in 'msgid' and 'msgstr' does not match te.po:21060: 'msgstr' is not a valid C format string, unlike 'msgid'. Reason: In the directive number 4, the character 'U' is not a valid conversion specifier. te.po:26517: 'msgstr' is not a valid C format string, unlike 'msgid'. Reason: The character that terminates the directive number 1 is not a valid conversion specifier. msgfmt: found 4 fatal errors ur.po:12773: format specifications in 'msgid' and 'msgstr' for argument 1 are not the same ur.po:27301: 'msgstr' is not a valid C format string, unlike 'msgid'. Reason: The character that terminates the directive number 1 is not a valid conversion specifier. msgfmt: found 2 fatal errors For those errors pointing at the CSS attribute you can temporarily fix it by removing the c- format comment until I have pushed the modified base string. Thank you for your work. Geert On Tuesday 21 October 2014 16:03:14 Jeff Earickson wrote: > Derek, > > Hmmm... Trying to reproduce here. Sometimes msgfmt will compile the > po file fine, but poedit will complain, so the two are not > consistent. > > In the case I just tried, poedit said: > > "Error: 'msgstr'' is not a valid C format strin
Re: gnucash maint: Remove bare percent sign in taxinvoice.scm, replace with English.
On Tuesday 21 October 2014 22:56:40 Geert Janssens wrote: > Jeff, > > Thank you for the details. I have experimented a bit with the kok.po > file. > > The issue is not in the % sign but in the fact that the string is > marked as a c-format string. Removing this line from the comment > block right above the msgid fixes the msgfmt error for that > particular translation string. > > The c-format comment is unfortunately automatically (and erroneously) > generated by xgettext while parsing guile-strings.c. This is a bug. I > have a patch in my queue that can fix this. This patch however > requires at least intl-tool version 0.50, which is still fairly > recent. > > This means I can't apply the patch (yet) to our maint branch and the > c-format comment will continue to pop up for the time being. > > To work around this until we can apply my patch, I'll redo the string > in a different way in the scm file to put the examples outside of the > translatable string. > While browsing the translation wiki page I found that it already explains briefly that this particular error could be fixed by removing the c-format comment [1]. So perhaps that's the better interim solution here rather than changing the string. Changing the string will invalidate the translation for all other languages as well. Regards, Geert [1] http://wiki.gnucash.org/wiki/Translation#Special_characters_and_other_tips ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Exporting GnuCash Log from GnuCash Android
Thanks for the feedback. Yes, we already do export multiple QIF files, one per currency. On Tue, Oct 21, 2014 at 8:46 PM, Derek Atkins wrote: > Hi, > > Ngewi Fet writes: > > > Hello everyone, > > At the moment, there is no easy/compatible way to import from GnuCash > > Android into GnuCash desktop. GnuCash Android supports both QIF and OFX, > > but each of them have their own issues. > > OFX does not support double-entry, QIF does not support multi-currencies > > etc etc. > > > > At the moment, we have it under consideration to implement exporting in > the > > GnuCash log format so that it can be replayed on the desktop. This would > > resolve most of the issues with importing. > > > > I just want to ask if there are any pitfalls or known limitations to this > > approach which we may be missing. Thanks. > > There are a few pitfalls: > > 1) the log format is ad-hoc. There is no standard or even >documentation. It's already changed at least once. > > 2) The log ONLY tracks basic transaction information. If you create new >accounts that info isn't the log, and if you then create a new >transaction against that new account you will get a crash. > > 3) The log replay performs no verification, so you could easily end up >with duplicate entries or broken entries (or a crash) > > Is there any way you could just emit multiple QIF files, one per > currency? IMHO that would be the "best". > > > Looking forward to your feedback. > > Cheers, > > > > Ngewi > > -derek > > -- >Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory >Member, MIT Student Information Processing Board (SIPB) >URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH >warl...@mit.eduPGP key available > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
