[Mono-winforms-list] Important ResourceManager notes

[Kornél Pál]

>I suggest to have our ResourceManager be smarter than MS's one, and
>first search non-neutral resources in the main assembly and just try
>the sattelite ones if not found. That way we are compatible with
>VS.NET projects generated assembly-sets but can accomodate a basic set
>of localizations in just one assembly, what would be nicer to compile
>and package/distribute.

I have the opinion that it were better to first look in the main assembly
for non-neutral resources as well. But Mono has the policy (for good reason)
to provied compatibility with MS.NET.

And if an application assumes any of these two orderst it will not be
compatible with the other one.

Assuming main assembly first satellite next (current Mono behaviour) or
satellite first main next (that is not used and was not used in Mono):
.NET Framework simply will ignore non-neutral assemblies in main assembly an
behave the same as they werent exists at all. This is a stange
incompatibility.

Assuming main-only neutral and satellite-only others (.NET Framework
behaviour in all versions):
Probably it will run exactly the same on Mono unless there are non-neutral
resource in the main assembly as well because in this case they will be used
on Mono instead of the satellite assembly. This incompatibility could be
accepted but the other one not.

>Or maybe the order should be reversed to allow for updated
>localizations being distributed as sattellites and override the basic
>internal set. Opinions are welcome.

Of course it is possible to use an overriden resource manager that reads
assemblies in different order but I think it's better if localized resources
can be distributed or updated independently of the code files.

For example .NET Framework has language packs and you can install as many as
you want but you don't have to install all of them if you know that you will
not need them.

And as Mono is maintained by a lot of people each language can have it's own
releases independent of the code files.

So I think the best solution is to move each non-neutral resource to
separate satellite assemblies.

I will post the updated ResourceManager to mono-devel-list as soon as both
the test suite and the class will be complete because the class is poorly
documented and has a lot of undocumented behaviour. Furthermore it will be
one of the most important classes of corlib when it will be used to localize
it's texts as every object will use it so it has to have a very extensive
test suite.

Kornél

On 6/10/05, Kornél Pál <kornelpal at hotmail.com> wrote:
> Hi,
>
> I am about post an extenive ResourceManager patch.
> I am still working on the test unit to make discover the correct behaviour
> of ResourceManager and prevent regressions.
>
> There were a lot of differences between Mono and .NET Framework
> implementation.
>
> The most important that will break Managed.Windows.Forms is that neutral
> resources has to be read from the main assembly any other resources has to
> be read from the appropriate satellite assembly.
>
> System.Windows.Forms.dll contains all the cultures of resources in the
> main
> assembly and only the neutral resources will be available in
> ResourceManager
> after the patch.
>
> Note that this change does not effect GetManifestResourceStream but it
> should not be used with localizable resources. (Managed.Windows.Forms is
> not
> using GetManifestResourceStream for localization)
>
> Kornél
>
> _______________________________________________
> Mono-winforms-list maillist  -  Mono-winforms-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-winforms-list
>


--
Rafael "Monoman" Teixeira
---------------------------------------
I'm trying to become a "Rosh Gadol" before my own eyes.
See http://www.joelonsoftware.com/items/2004/12/06.html for enlightment.
It hurts!