[Mono-devel-list] Small change in handling string localization

[Andreas Nahr]

> Hello,
>
> > Only a small change:
> > Right now the Locale class resides inside the System.Globalization
> > namespace.
> >
> > I would do the following:
> > Move Locale class to the Assembly directory (where available) and remove
the
> > namespace for Locale class
> > This has the following advantages:
> > 1. You can use Locale.GetText from any class without having to add a
using
> > System.Globalization statement (we would have to add this to every class
> > that wants to localize something, which will be practically every class
in
> > some namespaces.
> > 2. We get rid of the System.Globalization namespace which does natively
only
> > exist in corlib, but in no other assemblies.
> >
> > If nobody objects I'll make the change for the system assembly (The
change
> > should not break existing code)
>
> This sounds ideal.
>
> Then we have three options (and I dont care which route we go) about the
class:
>
> * Option 1: Keep the name of the class as Locale, and the routine
>   called GetText, and then in classes that want to do translations,
>   we can do the same trick that nunit-gtk does, which is that
>   each class defines a helper routine:
>
> static string _ (string s)
> {
> return Locale.GetText (s);
> }
>
>   This is to make the code look more like what the C people are used
>   to deal with for translations, and we could use the small
>   perl script that lives in nunit-gtk/src/getstrings.pl for that
>
> * Option 2: We partially like the use of underscores, but we dont
>   want to create too many functions, so we rename class "Locale"
>   to class "L", like this:
>
>
> internal class L {
> // this is used to translate strings.
> public static string _ (string s)
> {
> ...
> }
>
> // This is used to "tag" strings historically
> public static string N_ (string s)
> {
> return s;
> }
> }
>
>    And our code would use it like this:
>
> Console.WriteLine (L._ ("Hello World"));
>
> * Option 3: Maybe the best: we keep things how they are, and
>   we manually do:
>
> Console.WriteLine (Locale.GetText ("Hello World"));
>
> My vote goes for 3, but I have seen the other two being used.

My vote definatelly goes for 3 also.
If somebody is worried about the more compiled code it will create: As this
is internal you can easily apply obfuscation after compiling to reduce the
assembly size.

Maybe it also would be a nice compiler optimization feature.