Re: Euro support in GNUstep

[Pascal Bourguignon]

Any  multi-currency  application  will   have  to  implement  its  own
mechanisms anyway.

I mean, if I had accounts in EUR, USD, JPY, etc, I would still want to
use only  one language for my  GNUstep applications. The  names of the
devises depend on the language too. 

What about Argentina, where they're  dealing with tree of four devises
in  their  daily  transactions?  (Or  more, since  the  provinces  are
entitled to create their own money).

I think  that's a  problem too  complicated to have  it solved  at the
system layer. The most we can  do, is to provide the applications that
don't deal with money with a  unique devise normally used by the user,
and to let the money applications manage multi-currency as they want.

Note that it's this introducing  of a "default" money, (in addition to
idiocy  of users  and programmers,  but this  we cannot  avoid), which
gives  Excell invoices  or budget  documents display  different values
depending  on  the  user's  currency,  US$1000.00  for  those  in  US,
ESP1000.00 for those in Spain, not quite the same value...

In conclusion,  there should not  be any currency in  the environment,
but if  we must  have it for  compatibility with OpenStep,  then let's
make  it  simple.  We  don't  need complicated  schemes  for  changing
conventions.


> From: Nicola Pero <nicola@brainstorm.co.uk>
> Date: Mon, 7 Jan 2002 14:17:00 +0000 (GMT)
> 
> > 
> > quick idea: 
> > 1. rename the old Language files to e.g. 'German.old', and have the file 
> > 'German' include the new values.
> > 2. introduce defaults setting like GSLoadOldLanguageFiles yes/no. 
> > 3. a) If setting is 'yes' try to load e.g. 'German.old' and fall back to 
> > 'German' if it does not exist. OR load 'German' first and then load 
> > 'German.old' (if it exists) so that German.old has to contain only the old 
> > currency related strings which will replace the ones loaded before from 
> > file 
> > 'German'. (the second approach seems better to me)
> >     b) if setting is 'no' just proceed as normal and load e.g. 'German'.
> > 
> > Don't know whether this is of any use or whether its too much
> > overkill to  implement. From March 1st the Euro is the only used
> > currency in those countries anyway.
> 
> I quite agree with Martin - I suggest that - 
> 
>  - all standard Language files involved switch to use the euro
>    immediately, before the new release of gnustep-base is done.
> 
>  - the old Language files (with the old currencies) are never loaded or
>    used unless specifically requested.
> 
> That makes gnustep-base useful to write new software making use of money,
> and also to compile and use existing software using money in current real
> life.
> 
> Old software having to deal with old accounts in national currency - thus
> having to deal with both old and new currencies is in trouble anyway :-)
> it needs to have a way to know, for each amount, in which currency it is
> expressed ... probably the Languages file are little help there, such kind
> of software will need to contain its own currency code anyway.
> 
> If I had such software, I would probably convert all old amounts into euro
> (if possible) and then switch the whole system into using euro both for
> historical and new data, it looks much simpler than having to keep a
> multi-currency system forever.  It also means you can more meaningfully
> compare old data with new ones since they are expressed in the same
> currency.
> 
> So I think we probably need not bother with old currencies, and just drop
> them all and switch to the euro.  But yes - we could keep the old
> Languages files around and perhaps even provide a way to load them ... as
> a temporary measure I would say, if we do it let's pick up a date, say 31
> December 2002, and let's drop all old currency code by that date.
> 
> This is just a suggestion under my feeling that there are not many users
> who need the double currencies ... if anybody has accounting software
> based on gnustep-base which needs support for the double currency please
> let us know.


-- 
__Pascal_Bourguignon__              (o_ Software patents are endangering
()  ASCII ribbon against html email //\ the computer industry all around
/\  and Microsoft attachments.      V_/ the world http://lpf.ai.mit.edu/
1962:DO20I=1.100  2001:my($f)=`fortune`;  http://petition.eurolinux.org/

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/IT d? s++:++(+++)>++ a C+++  UB+++L++++$S+X++++>$ P- L+++ E++ W++
N++ o-- K- w------ O- M++$ V PS+E++ Y++ PGP++ t+ 5? X+ R !tv b++(+)
DI+++ D++ G++ e+++ h+(++) r? y---? UF++++
------END GEEK CODE BLOCK------