I would like to change the language at runtime. I do not found any topic
about that in the documentation. Although restarting the program with a new
UIculture change to the according resources by putting:
' Sets the UI culture to French (France)
Thread.CurrentThread.CurrentUICulture = New CultureInfo("fr-FR")

in the "Public Sub New()" procedure as an example, I do not know how we can
reset all the strings at the runtime by selecting a menu option to the
desired language.

I am stuck with that problem and will appreciate any help about that.

Pat (by the way, now MSFT gratified me with the pseudo Robinson... why not,
it's may be one of my ancesters...)

--
Programmeur néolithique.

Hi Pat. You could store the language preference in a file or the registry,
then set the CurrentUICulture based on this stored value on next load.
Another option would be to reload the form, painting all its elements using
the new culture selection.

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
--------------------

Dear Garett,
Thank you for your help.
At this moment the language change is done by setting the local, like
"fr-FR" in a file, and then asking the user for restarting the application.
This is working well as the user is not normally switching all the time from
one to another language. However, it would be more elegant to restart on the
fly the form parameters, seemingly changing only the strings. I do not know
how to do this in a windows form. I have tried to do this by initiating a
call InitializeComponent() after changing the UIculture, to reload all the
form properties. This is not seeming working fully, because the form is not
repainted at the same place on the screen, and it seem that the childs forms
are not using the new define UIculture. I hav'nt yet found an example to do
this kind of thing "properly and cleanly", although I guess there is a clean
way to do it.
Have you any idea where I could find a paper about this subject?

Best regards
Pat

PS: So far I have investigate the language resource localization, there is a
lack of integration of this job in the Studio .NET IDE. I have discovered an
odd way to store the strings in addition of the form parameters stored in the
resources files Form.resx and Form.fr-FR.resx when you save your edited form
to disk. If you read these resources in XML form, then you can add the
strings used in the code related to this form. You must save your string in a
separate file because if you modify again the Form, then the resource.resx is
reset to the only parameters used by the Form itself. But when the form is
finally defined, you can even add string resourses using the resource input
editor. Using RESGEN it's easy to extract string between .txt text file and
..resx resources. This is working great for me and avoid me to deal (and even
to understand well) with external resources management, which are giving some
burden while dealing with obfuscation and/or strongnaming assemblies. I
wonder why [MSFT] has not provided this in the IDE, because it looks simple
for me.

"Garrett McGowan[MSFT]" wrote:

I have just completed a Winforms application (VS .NET 2003) successfully
with runtime language switching. It works beautifully.

Other than the starting Form1, all the other forms work nicely the next time
you load them after
you update System.Threading.Thread.CurrentThread.CurrentUICul ture to a new
value. This works if you don't keep your forms opened permanently.

However, in the end I did not use VS.NET's design time Localizable feature.
This is because if I use WINRES to do let someone do the translation, the
resx file cannot be used back in Visual Studio again. This is really silly
and spoils
the whole intention of Visual Studio design time IDE localization.

So I put all my message strings, form labels, and labels for menuitems into
a separate resource file and have each form load all its resources at the
Load event handler. In this way, I can even change Form1's menu text on the
fly at runtime anytime by just calling GetString. I compile the resource
files separately using
resgen and al. There are VERY STRICT UNDOCUMENTED NAMING REQUIREMENTS when
using resgen and al and I had to hack with ildasm to get it to work finally.
Maybe discussion for another day.

By not using VS's design time localization feature, I lose the ability to
resize controls and labels on the forms for different languages.

Yes, I faced the same problem you mentioned in your PS section. VS will
compile all those localized variables on the localized forms and create a
new appname.resources.dll that clobbers yours each time you rebuild. But
because I stop using the design time feature and have 100% of my localized
resources in my own resource file, I edited the .csproj file to manually
exclude any form.lang.resx files. Surprisingly, the Exclude From
Project function in Solution Explorer won't work for resource files.



"Robinson" <Robinson (AT) discussions (DOT) microsoft.com> wrote

Hello Chris,
Thank you for your testimony and tips. Yes I actually have developped a
version that works pretty well changing language at run time. But, we must
restart the application to validate the change. This is a minor limitation,
but would have been more elegant to do it without to have to end and restart
the application. Sure on that topic, MSFT staff had surely to work under
pressure and did'nt got the time to polish the localization problem. That's a
pity because this reduce the plaisure to work under the IDE and have it to
handle the burden of localizing and manipulating the resourse files. I think
it was not a big issue because the mechanics was allready in place, it was
only to accept in addition to the form variable, the associate form code
strings. For the moment I have turn about the problem but for a heavy
application running in many languages it will be very heavy to handle. I
hav'nt yet investiguated if this is better handled in .NET 2005. At my
opinion, it is counter productive to try to climb to a higher set of gadgets
in the IDE before having solved 100% of the programming problems that
basically any developper must handle in a complete application. MSFT is a
beautiful and powerful steam engine. But the brakes have not yet been
invented!
--
Programmeur néolithique.


"Chris Y" wrote: