[Mono-devel-list] [PATCH] Reworked unified Locale classes
ClassDevelopment at A-SoftTech.com
Fri Jun 17 05:28:03 EDT 2005
First of all lets say this is obviously just my personal optionion:
> In the case you want to drop ResourceManager I have the following two
> Why are we working on Mono if we think that it unsuitable for it's own
> as well?
I always try to do as much things as possible natively in mono (In fact the
string class is still much less managed than I would like it to be) and I
think this should be done in mono.
> Why should we use a non existing infrastruncture for localization instead
> an already existing infrastructure?
Because you should look at the point that there are millions of possible
uses of mono. We are a plattform and I think making too many assumptions
about how it is used doesn't make sense. I believe that for the vast
majority of applications the existing infrastructure works just fine (I use
it myself for a lot of projects), however it imho wouldn't be a good thing
for mono itself.
There are lots of possible uses of mono apps:
In a Forms application this issue probably wouldn't be very problematic,
because the developer of the app doesn't expect it to use only a very small
amount of memory, however a console app developer might not be happy about a
substantial memory overhead. If somebody develops a service which runs in
the background and is allocating several megs of data - that gets never
freed again and is not shared - just because he once wrote "Network failed"
into a Logfile he will most likely be VERY unhappy about that fact.
I think the question which needs to be answered first is: Does it really
make sense to translate all errormessages at all? Would we even be able to
maintain these for a number of languages and which gain would we get from
More information about the Mono-devel-list