Bug 725296 reports that setting LANG=sv_SE fails to set the language.
This turns out to be an error in gettext, but it can be worked around
by setting LANG=Swedish_Sweden. That broke looking up the localized
account directory, so this special-cases "Swedish_Sweden" and
"Swedish_Finland" when looking up the account directory.
It's possible for OSX to create locales that while legal aren't
supported by setlocale, and we have account trees for some of these.
Retrieving the locale from NSLocale ignores the fixup done in
gnucash-bin to ensure that a reasonable and supported locale is used.
Release notes snippet for this change:
The default date completion when entering partial dates has been
changed from "always complete in current calendar year" to
"complete to a sliding window starting 11 months before current month".
For example if you enter "1/23" (January 23rd) while today is
December 10th 2015, the date will be expanded to
January 23rd 2016 rather than 2015.
If you prefer to keep the old behaviour, you can restore to it
via Edit->Preferences->Date/Time->Date Completion.
In addition if you were already using the sliding window
before, but didn't change the previous 6 months before
default, you will now also get the new default 11 months before.
Again if you prefer the old behaviour it can be restored via
the same Preference.
This commit adds code to check & repair that removes the read only status of the bogus transactions so the user can go in the AP/AR account and delete these bad transactions.
Translators: this commit introduces a new translatable string.
When auto-completing a transaction that was originally created in another
account with a different currency the balancing code will try to apply
conversions in the wrong direction if one edits the transaction. Explicitly
setting the transaction currency to the current register's currency
prevents the conversions being applied and allows the transaction to
balance correctly.
When a transaction with existing splits had its currency changed, the
function would change the values to use the new currency's denominator
without changing the actual value. The balancing code would then apply
the price of the the new "other" split to the amount, changing it as
well. Changing the transaction currency back would convert the value in
the other split correctly so that it would equal the amount that the
balancing code wouldn't change anything. I actually detected this bug
when I wrote the test but didn't recognize it as a bug.
The new code first calculates a new price and then applies it to each
split so that the transaction balances correctly in the new transaction
currency. This also round-trips correctly
This is a follow-up commit to fix the core of the issue.
With this commit gnucash is more liberal at accepting
counter formats. It will accept either li, lli, I64i and
whatever is defined for G_GINT_64 or PRIx64 on the user's
platform. Internally the code will always convert the
specifier set by the user with PRIx64, which should always
be the correct one on any platform.
Additionally a few extra tests were added to stress the
counter format code a bit more.
even if bill is already posted and results in extra $ posted to A/P
This adds a test in gncInvoice to return NULL it already posted.
Adds checks in dialog-invoice to test for already posted invoices. Messages
user and refuses to post entire selection if more than one selected.
Translators: This adds a message string.
Change some function names to better reflect there use and change
look_for_old_mapping to return map_account and use this to see if we
need to convert entry
