Fix typos for gnuchash/ doc/ bindings/ and misc.

Typos found via `codespell -q 3 -D ~/Projects/codespell/codespell_lib/data/dictionary.txt -S *.po,./po,*.min.js,./ChangeLog*,./NEWS,./doc/README*,./AUTHORS,./libgnucash/tax/us/txf-de*,./data/accounts -L ans,cas,dragable,gae,iff,iif,mut,nd,numer,startd,stoll`
This commit is contained in:
luz.paz
2019-09-13 20:26:03 -04:00
parent c675b5b5e4
commit 65bb60d621
96 changed files with 172 additions and 172 deletions

View File

@@ -83,7 +83,7 @@ def gnc_numeric_to_python_Decimal(numeric):
copy = GncNumeric(numeric.num(), numeric.denom())
result = copy.to_decimal(None)
if not result:
raise Exception("gnc numeric value %s can't be converted to deciaml" %
raise Exception("gnc numeric value %s can't be converted to decimal" %
copy.to_string() )
digit_tuple = tuple( int(char)
for char in str(copy.num())

View File

@@ -42,7 +42,7 @@ from datetime import date
# This script takes a gnucash url
# and creates a new file/db at a second url that has the same
# account tree and an equivilent opening balance on all the simple balance
# account tree and an equivalent opening balance on all the simple balance
# sheet accounts (not for income and expense accounts)
#
# This is done a per currency basis, one opening balance account for each
@@ -122,7 +122,7 @@ ACCOUNT_TYPES_TO_OPEN = ACCOUNT_TYPES_TO_OPEN.difference( set((
)) )
# this script isn't capable of properly setting up the transactions for
# ACCT_TYPE_TRADING, you'll have to create opening balances for them mannually;
# ACCT_TYPE_TRADING, you'll have to create opening balances for them manually;
# so, they are not included in the set of accounts used for opening balances
ACCOUNT_TYPES_TO_OPEN.remove(ACCT_TYPE_TRADING)

View File

@@ -1141,7 +1141,7 @@ def payBill(book, id, posted_account_guid, transfer_account_guid, payment_date,
xfer_acc = account_guid.AccountLookup(session.book)
# We pay the negitive total as the bill as this seemed to cause issues
# We pay the negative total as the bill as this seemed to cause issues
# with the split not being set correctly and not being marked as paid
bill.ApplyPayment(None, xfer_acc, bill.GetTotal().neg(), GncNumeric(0),
datetime.datetime.strptime(payment_date, '%Y-%m-%d'), memo, num)

View File

@@ -27,7 +27,7 @@
# gnucash-env python simple_business_create.py \
# sqlite3:///home/blah/blah.gnucash
#
# Specificically, this sets up a simple tree, creates a customer, job,
# Specifically, this sets up a simple tree, creates a customer, job,
# employee and vendor, creates an unposted invoice for each,
# and posts the customer invoice with a few entries and a tax table.
#

View File

@@ -48,7 +48,7 @@ class ClassFromFunctions(object):
add_method and add_methods_with_prefix.
"""
def __new__(cls, *args, **kargs):
# why reimpliment __new__? Because later on we're going to
# why reimplement __new__? Because later on we're going to
# use new to avoid creating new instances when existing instances
# already exist with the same __instance value, or equivalent __instance
# values, where this is desirable...

View File

@@ -93,7 +93,7 @@
%include <qofbackend.h>
// this function is defined in qofsession.h, but isnt found in the libraries,
// this function is defined in qofsession.h, but isn't found in the libraries,
// ignored because SWIG attempts to link against (to create language bindings)
%ignore qof_session_not_saved;
%include <qofsession.h>

View File

@@ -58,7 +58,7 @@
// receiving this pointer is going to make a copy of the data. After the
// function call, the memory for the time64 used to perform this conversion
// is going to be lost, so make damn sure that the recipient of this pointer
// is NOT going dereference it sometime after this function call takes place.
// is NOT going to dereference it sometime after this function call takes place.
//
// As far as I know, the xaccTransSetDate[Posted|Entered|Due]TS functions
// from Transaction.h are the only functions with time64 * that we re
@@ -71,7 +71,7 @@
//
// Mark Jenkins <mark@parit.ca>
//
// as far as I can see all occurences of pointers to time64 are now covered
// as far as I can see all occurrences of pointers to time64 are now covered
// by the named typemaps below (2019-04)
//
// Christoph Holtermann <mail@c-holtermann.net>