[Mono-devel-list] String constants and localization

[Miguel de Icaza]

Hello,

> right now there is nearly no localization support in the Mono class
> libraries and all strings (mainly for errors) are hardcoded into the
> source-files.

Thanks for this proposal, I have some comments in this email about the
specifics of the proposal.

Initially, I wanted to use it, but it meant that we would have to:

	* deviate from the standard practice (something I would not
	  mind, if there were strong enough arguments for)

	* Create and maintain a new infrastructure for localization.
	  Not bad per-se, but it would minimize the reuse of existing
	  knowledge that people might acquire or obtain from the NET.

	* Reimplement the chunks we already have for handling resources
	  in corlib to cope with all the CultureInfo bits.

I also want to avoid loading all the strings in memory, but it is
possible to do so:

> with a call like
> Print (MS.GetString (MonoString.GenericENullNotAllowed));

We should use the Resource infrastructure in .NET here: there are many
issues related to loading the proper assembly given the selected
CultureInfo, and the code is mostly implemented.

The file format for resources allows for this case: it is possible to
fetch the information without having to load all the strings to
localize.  

What we need to do is improve the implementation of
ResourceSet.GetObject.  Basically we should define an internal method in
the ResourceReader that can do lookups based on strings, without having
to use the resource enumerator.

We already have an API that can load a string from an index, so the only
thing we have to do is perform a binary search on the strings in the
file (like Monodoc does now for its help).

> The Advantages are:
> * Smaller Assemblies (probably leads to faster runtime performance in
> Jit also because Jiting a constant int should be faster than Jiting a
> constant string)

Well, the space that you save on strings, say the string:

	"Null not provided"

Would be encoded into an enumeration:

	Null_Not_Provided

And that would end up in the metadata as well, so the change in size is
only half the size (strings are stored in 16-bit ucs-2 encoding).

Miguel.