Hi,

I’m creating a project which uses Satellite Assemblies (SA) to isolate
localized resources. The solution contains eight library projects, one GUI
control project and one Windows Form project.

I know how to approach SA for library projects, but I do not have any idea
how to do it for Windows Forms and Controls. Should I use Localizable
properties on every win form and win control that I create and copy resource
files associated with form/control to SA? Or should I just create resource
file in SA with the exact name as the resx files of form/control?

Which approach is better? Or maybe there is another, different approach that
I should consider? Which approach will allow me to modify form/control in the
design view?

--Start: Different question but still about resources
Can I use String Resource Tools to create resx and corresponding cs file and
then split them into two separate projects – resx and string file (string
file is created by String Resources Tool) will go to SA, and cs file to new
library project? Or maybe I can access cs file in file created by SA?
--End.

I’ll be grateful for yours help.

Kind regards,
Jakub G.

Jakub,

set the "Localizable"-property of your Form to "true".

With the "Language"-property of the Form set to "default" (the inital value) fill in the properties of the elements (like
Button-text, Label-text, icons...) within the designer. They will be saved in the .resx-file associated with your Form (e.g.
"MyForm.resx" if you Form's class is named "MyForm").

Then, change the "Language"-property of the Form to one of your desired localized languages, e.g. "en-US". A new .resx-file
(MyForm.en-US.resx) is created. Fill in the localized versions of the elements' properties within the designer. They will be saved
within the new .resx-file. Proceed in this way for all desired localized languages.

Upon building the project the IDE will perfectly compile all .resx-files into satellite-assemblies and place them in the correct
subfolders below the project output folder (en-US,...). The satellite-assemblies all will be named
<default-namespace>.ressources.dll.
Within the "InitializeComponent()"-Method of your Form you will see that the localized properties are fetched from the
satellite-assemblies via a ResourceManager-object.




This works fine for all elements which can be localized within the designer. But there are some, that cannot be localized like e.g.
the ListViewItem-object. On the other hand you might need some fields like private variables of your Form's class which also shall
be localized.

For these objects you should add your own .resx-files (e.g. "MyStrings.resx", "MyStrings.en-US.resx",...) in Solution Explorer.

In these files define key-value pairs (e.g. "LVI_1_Text" in case of a ListViewItem) for the localized properties; of course they
must be named identical througout all .resx-files.

These .resx-files will then be compiled into the same satellite-assemblies I described above.



In your code, you will have to create a separate ResourceManager-object.

If your default-namespace e.g. is named "MyApp", then the satellite-assemblies will all be named "MyApp.ressources.dll".

The "MyStrings.resx"-, "MyStrings.en-US.resx" ... - files are embedded within the satellite-assemblies.

To correctly fetch your own key-value-pairs out of the satellite-assemblies, use the RessourceManager like this:
using System.Globalization;

ResourceManager rm = new ResourceManager("MyApp.MyStrings",System.Reflectio n.Assembly.GetExecutingAssembly());

Hope, this helps.



I did not really understand your last question.



Regards

Rolf






"Jakub G" <JakubG (AT) discussions (DOT) microsoft.com> schrieb im Newsbeitrag news:0E98BC11-7D4B-44CD-B7AE-B2821EAC88B8 (AT) microsoft (DOT) com...

Hi,

Thanks for the reply.

It's not exactly what I was asking for. Maybe may question wasn't clear
enough, sorry for that.

I had created a separate project for resources - MS calls these kinds of
projects; Satellite Assemblies. It is desired to be independent, in meaning
that after you deploy the application, you can replace all SA dll's with new
ones whenever you want , without having to rebuild and re-deploy the
application in the production environment.

And now, when you have Library Projects, Windows Form Projects and GUI
Control Projects, you can separate all resource files from these projects and
put them into the SA project.

My problem is, that I just don't know how to separate the resources from the
win forms and controls, in such a way that I could fully use meaning of SA.

Kind regards,
Jakub G

"Rolf Molini" wrote:

Rolf,
This is about the BEST explanation I have yet seen on how to make
internationalized apps.
The microsoft documentation should be as clear and precise, they should HIRE
you to make user docs.

Bob
"Rolf Molini" <molini (AT) web (DOT) de> wrote

Bob,

you are right: MSDN unfortunately is not very clear (not to say misleading) about this important issue. When I myself had to deal
with this it took me indeed some DAYS to correctly find out everything, within the boards I did not find a suitable explanation as
well.

During my efforts which after some time degraded to a kind of "Try and Error" I think I sent more curses to Redmond than Bill earns
bucks a year :-)

So, I think it is the right way to share what I have found out and to save others from this torture of uncertainty where you doubt
all the time if you will EVER find a way.

Regards
Rolf


"Bob" <bdufournosp (AT) sgiims (DOT) com> schrieb im Newsbeitrag news:eHM1iVSvFHA.2792 (AT) tk2msftngp13 (DOT) phx.gbl...

Jakub,

O.k., now I begin to understand what your intentions might be. In an application which comprises several different components (like
Forms, DLL libraries, separate Controls) you would like to gather ALL resources together within ONE additional Satellite Assembly.

I hope I am understanding this correctly up to here.


Well, this might be achieved if in your separate project (a "Resources project") you create various .resx-files for your various
other components, let's say they might be named

MyForm.resx
MyForm.en-US.resx
....

MyDLL.resx
MyDll.en-US.resx
....

MyControl.resx
MyControl.en-US.resx
....


It would be best if you give your "Resources project" a distinct default namespace in the project's settings, let's call it
"MyResources". The Satellite Assemblies created out of your .resx-files will then all be named "MyResources.resources.dll" and will
be put below the output-folder of your separate project.


Within each of your various components you first need to create a REFERENCE to your "Resources project" via Solution Explorer.

Then e.g. in your Form "MyForm" you go like

using System.Globalization;
using MyResources;

ResourceManager rm = new ResourceManager("MyResources.MyForm",System.Reflec tion.GetExecutingAssembly());


Or in your DLL you go like

using System.Globalization;
using MyResources;

ResourceManager rm = new ResourceManager("MyResources.MyDLL",System.Reflect ion.GetExecutingAssembly());




As long as your components contain a reference to a separate assembly and you use the "using" statement, you can of course make use
of resources embedded in this separate assembly.


But, after all explanations, allow me the question: What is the reason for this approach?


The "normal" Satellite Assemblies which are created automatically along with your Form can be exchanged or extended just as easly.
O.k., in case of a DLL-library you would anyway have to go the way I described because outside of "System.Windows.Forms" the
automatical procedure of Satellite Assemblies is not present.

Do you plan to "centralize" all resources for your various components within ONE Satellite Assembly? This might indeed be senseful
for a lager and heterogenous project.

On the other hand, regarding your Form (or Forms), you then let go the extreme simplicity of creating Satellite Assemblies via the
IDE Designer. You will have to do it all manually for every Form.

Regards

Rolf






"Jakub G" <JakubG (AT) discussions (DOT) microsoft.com> schrieb im Newsbeitrag news:5AD374EB-23EF-489E-BD7F-276442603337 (AT) microsoft (DOT) com...

Jakub,

to be fully clear, I make one more explanation.

In my last post I stated that in case of Forms (or, as I might add in case of Controls) according to your approach (extracting ALL
resources to ONE separate Satellite Assembly) you will have to do it all manually.

Let me explain in more detail what it would mean for you to do it ALL manually.

Well, in the first place this of course means creating key/value-pairs for EVERY ELEMENT in EVERY Form or EVERY Control of your
application. You will have to create

MyForm1.resx, MyForm1.en-US.resx,...
MyForm2.resx, MyForm2.en-US.resx,...
....

MyControl1.resx, MyControl1.en-US.resx,...
MyControl2.resx, MyControl2.en-US.resx,...
....


But this is only the FIRST part of your labour to come.

Consider, that the IDE will by itself create .resx-files for every Form or Control you add to the application. And consider further,
that - within the various "InitializeComponent()"-routines of the Forms or Controls the parameters for the localizable values will
initially be fetched via the automatically created ResourceManager-objects.



Example:

Within "MyForm1" there will be automatically created a ResourceManager-object like

ResourceManager resources = new ResourceManager (typeof(MyForm1));

(A different usage of ResourceManger which can be used - as far as I have found out - only by the IDE).


The parameters for ALL elements within your "MyForm1" will be fetched via this ResourceManager in the
"InitializeComponent()"-routine of "MyForm1".

To deflect this behaviour to your "private" Satellite Assembly, you will have to change ALL these statements within the
"InitializeComponent()"-routines of ALL your Forms or Controls.


Having the effort of creating key/value-pairs for ALL elements of ALL Forms/Controls of your application in mind, and adding the
additional effort of changing ALL respective statements within the "InitializeComponent()"-routines of ALL your Forms/Controls, you
might want to balance this immense labour against the simplicity of making use of the automatic creation of Satellite Assemblies for
each Form/Control.

If you made use of this simplicity all you additionally would have to do was creating Satellite Assemblies for the DLL-libraries.

The resources of your complete application then would not be "centralized" within ONE Satellite Assembly but each Satellite Assembly
of each Form/Control/DLL could as easily be exchanged as your original intention was.

Regards
Rolf









But consider this additional


"Jakub G" <JakubG (AT) discussions (DOT) microsoft.com> schrieb im Newsbeitrag news:5AD374EB-23EF-489E-BD7F-276442603337 (AT) microsoft (DOT) com...

And let me add just one or two other (more general) thoughts regarding your intended approach:

Suppose, your application is large, complex and heterogenous (Forms, DLLs, Controls).

Will it really help you as a developer to comprise all localized key/value-pairs of all elements of all components of your
application within ONE Satellite Assembly?

On the one hand this will lead to tremendous work you will have to do (as I described before).

Furthermore you will have to do a good job to identify the key/value-pairs of a single element's property belonging to one of the
various Forms/Controls within your huge application.

On the other hand, from a viewpoint of structure: Is it really helpful to centralize information which belongs to completely
different parts of your application?

CENTRALIZING is a viewpoint of developing which goes more in the direction of database- or directory-focused programming. It mostly
makes sense where COMPLETELY DIFFERENT APPLICATIONS have to rely on the same set of information. As far as I have understood your
intention we don't talk about different applications.

Now chaning the focus to ONE application:
Don't forget about the advantages of OBJECT-oriented programming and its various advantages. The motto here is: Keep information
where it immediately belongs to, make ways of information short. This in turn will help you as a programmer to keep an overview of
all information spread througout your application.



Regards
Rolf


"Jakub G" <JakubG (AT) discussions (DOT) microsoft.com> schrieb im Newsbeitrag news:5AD374EB-23EF-489E-BD7F-276442603337 (AT) microsoft (DOT) com...

Thank you, gentlemen, for your feedback on this topic and for sharing what
you learned. Rolf, was this one of the articles on MSDN that you found
misleading?

http://msdn.microsoft.com/library/de...us/vbcon/html/
vbwlkwalkthroughlocalizingwindowsforms.asp

There are ongoing opportunities to improve our samples and Help topics, and
this type of feedback is vital to that process. If you didn't find this
article helpful, what additional information would you like to see covered
in a revision?

(As an aside, Windows Forms applications in Visual Studio 2005 include
strongly-typed resources, which helps simplify the localization process,
especially when dealing with strings.)

Cheers,
Garrett McGowan [MSFT Developer International]

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
--------------------
embly());