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 <[EMAIL PROTECTED]> 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@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! _______________________________________________ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list