I have a localization file that I created that works fine, I called it:
Labels.resx
Now in my global.asax.cs, if a particular querystring value is present, I change the language to french:
Thread.CurrentThread.CurrentCulture = new CultureInfo("fr-CA");
I created a new resource file:
Labels.fr-CA.resx
I just put a single entry in the new french local file to test it, now when the controller action executes, while debugging I can see in the immediate window that the culture has changed correctly, but my text label is not in french.
What could the issue be?
The properties for my Labels.fr-CA.resx file are exactly like my Labels.resx file:
embedded resource
PublicResXFileCodeGenerator
(same namespace)
Also, if the given key isn't found, does it automatically lookup the value in the Strings.resx key as a fallback or does it cause an exception?
Try add the folowing line to global.ajax.cs:
Thread.CurrentThread.CurrentUICulture = new CultureInfo("fr-CA");
Related
I know it's easy to localize Windows Forms App: set Localizable=True, change Language and set text in Controls for every Language. This information saves in resx-files and application will automatically select the required file. Great!
I know about disadvantages of this solution (you need to rebuild the app if there a typo, it's impossible to change language in runtime, etc), but it's not a problem for me and "resources" is the simpliest, built-in solution.
But this mechanism uses the property Culture of app's thread.
My app is the part ("plugin") of the bigger application and works in the same Thread.
The main application is multilingual too, but it doesn't use Culture to change interface's language. I can change the thread's culture globally, but it crushes the main app's interface.
So my question:
is it possible to manually set the resx-localizable resurce file that will be used? Not based on Culture, but, for example, on some variable in my app:
if (this.Language == "fr")
this.Resources.Add("Form1.fr.resx");
else
this.Resources.Add("Form1.en.resx");
Or something else.
Thank you!
My sandbox:
https://github.com/Tereami/WindowsFormsTestLanguage
The built resources file has a property ResourceManager that's used to return the desired content. This has an overload with a CultureInfo parameter. You can use it to request resources in individual languages:
var desiredCulture = new CultureInfo("en-us");
var text = MyStrings.ResourceManager.GetString(nameof(Resources.ExitMessage), desiredCulture);
If you want to set the culture globally for your resource file, you could also set it through the corresponding property:
var desiredCulture = new CultureInfo("en-us");
MyStrings.Culture = desiredCulture;
var text = MyStrings.ExitMessage;
I'm trying to localize my application with satellite assemblies.
I tried to follow this blog: http://msdn.microsoft.com/en-us/library/21a15yht(v=vs.110).aspx
I've created two files, one file has the name "Global.resx" with an english string, and the second file has the name "Global.nl-NL.resx" with a dutch string.
After this i created a .resources file from the dutch file with resgen. With al.exe I made a .dll called LocalizationLab.resources.dll and i stored it in the folder: /bin/debug/nl-NL.
in my application i set the CurrentUICulture to nl-NL. and i call the string with Global.test. See underneath
Thread.CurrentThread.CurrentUICulture = new CultureInfo("nl-NL");
Console.WriteLine(Global.Test);
This returns the english string instead of the dutch one. When i debug and take a look into Global and watch the resourcesets the resourcemanager is using, I see three resourcesets: "nl", "nl-NL" and "" all three of them have english string values in them.
Can anyone tell me what i'm doing wrong?
Thanks in advance.
I eventually found out what the problem was,
The problem was that the generated code for initializing the resourcemanager was looking like:
ResourceManager rm = new ResourceManager("LocalizationLab.Global", typeof(Global).Assembly);
After some puzzling i found out that it should be this:
ResourceManager rm = new ResourceManager("Global", typeof(Global).Assembly);
which worked!
Sorry, in advance for my English, its my first post here.
I've got strange problem with RESX, supported culture in Silverlight.
Its silverlight app with 1 web(asp.net) project which start whole silverlight app, 1 main project(silverlight, sl.Application) and others which are use as modules(silverlight) in main project (solution explorer screen: http://i.imgur.com/A4sHWRI.png?1 ). Sl.Application can invoke other projects and use theirs views as part of the main view placed in sl.application
I tried to add different cultures, so:
I add to my app Supported cultures EN and CS to each cs.proj.
<SupportedCultures>pl;en;cs;de;ru;cz;sk</SupportedCultures>
My Neutral culture is set to PL in assemby info in each project.
[assembly: NeutralResourcesLanguageAttribute("pl-PL")]
Create resx Files for different cultures, here fol PL, EN , CS: http://i.imgur.com/P6woiV2.png
At starting app you can choose which culture you want, by clicking on specific flag.
First lets start with PL - its neutral culture, so i dont have to change anything. Using
var culture = System.Threading.Thread.CurrentThread.CurrentUICulture;
var test_en = Resources.DrivesBook.ResourceManager.GetString("AdresArrival", culture);
I checked that culture is set to PL and resource (DriveBook.resx) return correct string in PL
Next:
Let's try EN, Start App, choose EN flag - change culture to en-GB.
System.Threading.Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo("en-GB");
Using same code as above, returns me EN string so its still good
The best begins when i tried to use CS.
Same as above, I choose CS flag - change culture to cs-CZ
Using in SL.Application
var culture = System.Threading.Thread.CurrentThread.CurrentUICulture;
its returns me cs-CZ culture so I thought that there will be ok, when I call
var test_cs = Resources.DrivesBook.ResourceManager.GetString("AdresArrival", culture);
it returns me string from CS culture, still all works fine, so where is the problem?
When i tried same in others projects (from Common or Modules folder), here comes magic :)
Same as above
Using in Modules.Auxiliary
var culture = System.Threading.Thread.CurrentThread.CurrentUICulture;
still OK, we got cs-CZ culture, seems to works fine, but
var test_cs = Resources.DrivesBook.ResourceManager.GetString("AdresArrival", culture);
it returns me string from PL culture, not from CS
Summation:
Changing culture works fine, for EN, whole app got EN string from resx files, but when I change to CS, only SL.Application can resolve *.cs.resx file, other projects looks like they have not seen *.cs.resx files. While adding En and CS I d exactly same work for both and EN work fine, but CS not. its there any posibily that there is some property in cs.proj that limit max supported cultures in current project, or do you have any idea what I did wrong?
ok, I solved it by myself
Problem was in my custom framework, which was responsible for differential loading resources. Resolving dll only via filename, not included filePath (here folder cs, en for different cultures) caused overwrite files depending on the lexical order, so CS.resx was loaded firstly, but later I load EN resource and overwrite cs.resx. This framework starts working when comes to loading main xap. Main sl project works, cuz it was loaded earlier, e.g. for loading screen so resource.cs.resx was loaded when my framework couldn't corrupt it
I have a website which currently uses EN-US and I also have resource file for french. what code should I need to write to make the application use the french version of the resource file.
The site is a commerce server and share point site that uses .NET
Any code examples would be great.
You have a couple of options. Option one is at the application level. You could do this in the system.web section of the web.config:
<globalization culture="fr-FR" uiCulture="fr-FR" />
Another option is on the page:
<%#Page Culture="fr-FR" Language="C#" %>
or by thread:
Thread.CurrentThread.CurrentCulture = new CultureInfo("fr-FR");
See http://support.microsoft.com/kb/306162 for more info.
I consider the main resource file's feature as the ability to retrieve localized strings according to the culture specified in the url through code such as:
localresourcestring = (String)GetLocalResourceObject("username")
//will retrieve the localized string for username from your resx (according to the resx's name)!
Here's a great place to start, including a Walkthrough and such..
I would set the language at the Application_BeginRequest() global event in the Global.asax file:
protected void Application_BeginRequest()
{
// Get the CultureInfo object that contains the French language specification
CultureInfo frenchCulture = CultureInfo.CreateSpecificCulture("fr-FR");
// Set the language the current thread uses (per-user)
Thread.CurrentThread.CurrentCulture = frenchCulture;
Thread.CurrentThread.CurrentUICulture = frenchCulture;
}
Hope it helps.
i have two Resources files in the Properties folder of a WPF-project (VS 2008):
Resources.resx
Resources.de-DE.resx
Selecting the culture "de-DE" does not work (no error, but always the strings from "Resources.resx" are used):
public App()
{
UntitledProject2.Properties.Resources.Culture = new CultureInfo("de-DE");
}
BUT: if I rename "Resources.de-DE.resx" to "Resources.fr-CA.resx" or "Resources.en-US.resx"
and then set it via
UntitledProject2.Properties.Resources.Culture = new CultureInfo("fr-CA");
it works!! But why!? Mysterious...
By default, WPF will always use "en-US"; at least it did the last time I checked (which was .net 3.5). If you want WPF to instead use the culture currently set by the system, you would execute this code block:
FrameworkElement.LanguageProperty.OverrideMetadata(
typeof(FrameworkElement),
new FrameworkPropertyMetadata(
XmlLanguage.GetLanguage(
CultureInfo.CurrentCulture.IetfLanguageTag)));
This will override the default value used for the FrameworkElement's Language dependency property, which, again, is "en-US" by default.
Execute this code once and early on in the lifetime of your application. AFter that, you shouldn't have to worry about it again, unless you expect your user to be switching the culture in the middle of program execution...