[Mono-devel-list] [PATCH] Reworked unified Locale classes

Kornél Pál kornelpal at hotmail.com
Fri Jun 10 13:07:28 EDT 2005


First of all:
This patch requires the following two applied:
[Mono-devel-list] [PATCH] ResourceManager - minor fix
[Mono-devel-list] [PATCH] StackTraces - remove some localization

The diff file is compressed because it's 163 KB.

CorlibResourceManager is a ResourceManager subclass intended to be used by
Locale.cs of corlib to avoid infinite GetString recursion because GetString
uses methods and classes that use GetString and this may cause recursion in

Locale.cs is a reworked version of the current Locale.cs. There are about 5
different Locale.cs versions in the Class Library and all of them can be
replaced with this one. Locale.cs of corlib inherits from
CorlibResourceManager but the rest is the same.

Note that altought the current Locale.cs is created by two authors (Miguel
de Icaza and Andreas Nahr) it usually contains a single GetText method that
returns the string passed as argument.

Some version contain a second GetText method that does formatting as well.

Managed.Windows.Forms has a GetResource method that wraps

Altough I don't like gettext () style resource management it is planed to be
used by Mono Class Library.

This new Locale.cs contains a ResourceManager subclass that returns the
identifier in GetString for the neutral culture but uses resources for
GetObject and all other cultures.

Altought currently using gettext () style resource management is easier
because Mono is not localized to any language other than English I do not
recommed using is because the following reasons:

Every modified character in English text has to be modified in all of the
other languages as well. This prevents distributing satellite assemblies
separately or using satellite assemblies that are not very up to date.
Furthermore it is wasting of disk space as identifiers are stores as UTF-16
while texts are stored as UTF-8. On the other hand it has better performance
on English messages because they are not looked up in a Hashtable but I
think it has too much disadvantages compared to this small advantage.

>From the current point of view of globalization both methods are the same
because localizable string has to be collected but this will change at
localization time.

I know that gettext () is widely spreaded on Linux but this does not have to
mean that it is the best solution and the Class Library has it's own
infrastructure for globalization using identifier based resources and
culture based resource files.

Comments are welcome about the two new files and gettext () style

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Locale.zip
Type: application/x-zip-compressed
Size: 5301 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20050610/0c73e28e/attachment.bin 

More information about the Mono-devel-list mailing list