GnuCash setup for multi-country use / and reply-all should be discouraged

[cognitive.libertarian+ml at gmail.com]

* Derek Atkins <warlord at MIT.EDU> [2010-02-20 18:23]:
> 
> Note that a Split itself doesn't have a currency -- it takes the
> currency from the Split->Account->Currency.  But you're proposing
> that an Account no longer have a single currency, which is where we
> have the disconnect.

I'm not necessarily proposing that expense accounts do not have a
currency.  I was deliberately vague.  I'm proposing that they at least
*appear* to be currency-free.  I could also imagine a simple solution
where the GUI merely hides the fact that expense accounts are
mono-currency.

Eg. in the register view, the user sees the expense account:

  Expense:Transport:Train

But perhaps /internally/ this really unfolds into multiple mono
currency accounts that are created on an as-needed basis (but
invisible to the user):

  Expense:Transport:Train:_eur
  Expense:Transport:Train:_gbp
  Expense:Transport:Train:_chf

Maybe in some cases the user would have to see these account names,
but it would be a small price to pay for the current maintenance
burden of having to select from a massive tree on every transaction,
and then have to pick through the clutter in the accounts page.  

The internal account names could probably be hidden in most views, if
not all.

> This would also imply a major data file rewrite..  Which means
> you're no longer data-file compatible backwards or forwards.

In an upgrade to a version using the solution above, multi-currency
users would want to rename Expense:Transport:Train:USD to
Expense:Transport:Train:_usd, for example, to align with whatever the
internal representation becomes.  But they wouldn't have to.
Presumably the accounts would continue working as they did previously.

And I wouldn't think going backwards would be a problem either.  It
would just perhaps be a matter of relatively ugly internal account
names becoming visible.

> I'm not going to argue the merits of feature requests that imply
> huge architectural changes to GnuCash.  Sometimes I think we should
> take on the MythTV approach; their tracker is only for bugs.  They
> automatically close any enhancement request without a patch.

Aren't enhancements easily filtered?  Developers could simply ignore
them.  I'm not sure if voting or bounties are possible in the gnucash
bug database, but those would be useful to have to collect and measure
interest, even if they're being ignored by contributors.