I'm making an app in C#, with a lot of forms and other stuff.
I wanted to localize it, so I used the integrated localization functions in VS.
The app was originally in French (cause I am) with English translation RESXes, but now that it is on Codeplex with some other developers who doesn't speak french, I want to change the "default" language in the app and the RESX files so they can translate to other languages without reading French.
Cause when you choose another language in VS Form Designer, it shows the default language (here, French). I tried to rename all the files, but the problem is all the form properties are stored in the default RESX, the French one, so if I rename, it will break all the stuff. Is it possible to change the default language to English?
EDIT: I think I need to be more precise.
The app is originally in French. Then I localized it in English. There is now a MainWindow.resx that contains form properties + original french localization and a MainWindow.en-US.resx that contains ONLY english localization. So if in the Designer, in "Language" I choose "(default)" it shows me the MainWindow.resx FRENCH, and if I want to translate, It shows me the French texts. To make the translation more easy for the other developers, I want to make the MainWindow.resx ENGLISH localization and create a seperate MainWindow.fr-FR.resx. I also tried to change "Neutral Language" in AssemblyInfo.cs, no effect.
While you could do renames in file system to achieve neutral culture/resource change, you need to update project file as well, which is cumbersome. I found the simplest way was to do this via Visual studio extension named ResXManager.
Steps in detail:
1. Run & configure ResXManager
In VS: Tools -> ResXManager.
Choose configuration tab (below)
Disable option "Confirm adding new resource files". Otherwise you would have to click later per each file to accept its creation.
Set Neutral Resource language so it would show up with a correct flag for your viewing pleasure.
Switch back to main tab where you see all solution resources with translations side-by-side.
2. Extract neutral culture resources as explicitly French
Adda a new column for French using the "Add new language" button in the toolbar.
Copy all French resources from existing neutral language column (CTRL-SHIFT-DOWN helps top select full column)
Paste all resources to new French column.
Note that ResXManager will create new resx files for you and add them to project file.
3. Set neutral culture reousrces to English ones
Copy all English resources from specific culture column
Paste all resources to Neutral culture column
4. Inform .Net that neutral culture is now english
[assembly: NeutralResourcesLanguage("en-GB", UltimateResourceFallbackLocation.MainAssembly)]
5. Remove explicit English resx files.
Since the neutral resx files now already contain english resources then you don't need to keep them the culture-specific ones. Unfortunately ResXManager didn't seem to have a button for this but you can I chose to use VS solution manager filter "en-GB.resx" and deleted all files it found. Again, doing it within VS automatically updates your project file.
All done.
You can change the CurrentCulture and CurrentUICulture in your application through code.
It's the same approach that is used to change the apps language at runtime.
Have a look at this code:
Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US");
Thread.CurrentThread.CurrentUICulture = new CultureInfo("en-US");
Hope it helps.
Related
I have my loacalized *.resx files in another project to which I set a reference (it's a solution with mulltiple projects, so we have a *.Common project where we have styles, localization...). by now I have two *resx:
TextObjects.resx ------> english/invariant
TextObjects.de.resx --> german
How can i get these Files (the cultures of it)? Because I use WPFLocalizeExtension the *.resx-files need to be embedded resources.
I found only a way to watch inside the Resourcefile and get it's Keys, but not how many and which files i have.
Also I face two other problems:
The default invariant Language ist shown as this. Is there a way, without an Converter, to show it as english?
I like do set the systems CurrentCulture as first culture. If there is no localization for that the Extension correctly uses the Invariant Localization. BUT if the language doesn't exist it still get added to the MergedAvailableCultures and is as a result also shown in the ComboBox to which i bound this list. How can I avoid this?
I wrote a small application that shall automatically start in either English or German. English is default and German would be used on a German Windows.
The problem:
The German strings aren't loaded on a German Windows, although the program recognizes the client as German.
Explicitly setting the current culture (in code) to German however will result in a German UI.
What I did:
I followed this guide: http://www.codeproject.com/Articles/299436/WPF-Localization-for-Dummies
I created copies of the Resources.resx in the Properties section
Now there are: Resources.resx, Resources.en-US.resx, Resources.de-DE.resx
I put all Strings in the three Resources files. Resources.resx and *.en-US.resx contain the exact same strings
The name of the strings are consistent, Access Modifier on all files set to Public
File Properties of the Resources: Build Action: Embedded Resource; Do not copy; Custom Tool: PublicResXFileCodeGenerator
Code:
private void InitLocalization() // Executed on startup
{
if (CultureInfo.CurrentCulture.Name != "de-DE") // only use german on german systems. Otherwise use english
{
CultureInfo.DefaultThreadCurrentCulture = CultureInfo.DefaultThreadCurrentUICulture = CultureInfo.CreateSpecificCulture("en-US");
}
else
{
CultureInfo.DefaultThreadCurrentCulture = CultureInfo.DefaultThreadCurrentUICulture = CultureInfo.CreateSpecificCulture("de-DE");
}
rm = new ResourceManager("SaveEye.Properties.Resources", Assembly.GetExecutingAssembly());
// Manually assign the correct text to XAML-elements
_SettingsTextBlock.Text = rm.GetString("Settings");
_StartWithWindowsCheckBox.Content = rm.GetString("Startup");
_SaveButton.Content = rm.GetString("SaveAndClose");
}
Basically, I just want to make sure that either the Resources.en-US.resx or Resources.de-DE.resx is loaded from the ResourceManager.
In the rest of the code I grab the Strings I need with rm.GetString("").
This works just fine with English. I can even manually set the CurrentCulture to de-DE at the beginning of the InitLocalization-Method and then all German strings are loaded. But as I said, on other systems that are de-DE by default, the German strings are not loaded.
What am I doing wrong?
Regards
It is the CurrentUICulture that will affect which resources are loaded, and the CurrentCulture that will affect date and number formatting. A lot of people get these two confused.
You should probably be testing CurrentUICulture if you're trying to either set, or determine what string resources to retrieve. There is a big difference between a machine running with German date and number formats (CurrentCulture) and a machine running with a full German Language Pack installed and activated (CurrentUICulture).
Your sample code is using CultureInfo.DefaultThread(UI)CurrentCulture which will control the behaviour of all new threads created but this will default to whatever the main thread is using anyway so if it was already in German, you shouldn't need to explictly set it as such.
You can test the resource loading behaviour by updating your InitLocalization() method and setting Thread.CurrentThread.CurrentUICulture explicitly to "de-DE" to see if the German resources start loading. Then verify that the CurrentUICulture is really set to "de-DE" and not just the CurrentCulture. It's possible the German machine has German date/number formatting (CurrentCulture) but isn't using a German language pack (CurrentUICulture).
EDIT: In response to your comment, if you're already using CurrentUICulture correctly and the machine really has a full German UI but the German resources still aren't appearing, you should check that the German satellite resource file is actually being deployed.
The German resources are contained within a separate assembly named de-DE\MyApp.resources.dll and must reside in the same folder as the executable and stay within the de-DE folder (so you have \Folder\MyApp.exe and \Folder\de-DE\MyApp.resources.dll). The default resources (the ones in Resources.resx stay in the main executable and are the ones the ResourceManager falls back to if no more appropriate resource is found).
You didn't specify how you were deploying the application, but if you run you can use the 'Open in Explorer' (or Dateipfad Öffnen on the German machine) feature of Task Manager to take you to deployed folder of the running application so you can check that the de-DE folder is there (I only mention doing it this way because if you ClickOnce deploy the application it can be hard to find the installation folder).
If you are using ClickOnce and you publish with Visual Studio, you can control the files included during publishing by right-clicking the project and selecting properties then navigating to the 'Publishing' tab. The 'Application Files' button will show you a list of all the files included when publishing. Your de-DE satellite resource file should be set to 'Include'.
In ASP.NET, an application can be localized using resource files. Resource files hold different translations. For example, one might have an English resource file and a Spanish resource file. When resource files are used, an attribute can be applied to controls on a web page to automatically populate that control with values from a resource file. Alternatively, the values can be programmatically loaded from a resource file and assigned to a control's property.
ASP.NET uses a fallback mechanism for loading translations. It tries to find the resource file that is most similar to the current user's culture. If the current user's culture is Spanish, ASP.NET tries to load the appropriate resource from the Spanish resource file. If the Spanish resource is not available, it falls back to a default resource file. Because of this behavior, text for a Spanish user may be shown in the default language for two reasons:
No Spanish translation is available. (The translators haven't provided a translation for this item yet.)
The text is not localized. (This may be the result of plain text appearing in the page or the message being hard-coded somewhere.)
If text appears in the default language, I want to know whether it was because of reason 1 or because of reason 2.
For every missing translation, I could insert some kind of placeholder text in a resource file. However, this means that I am throwing away the fallback mechanism. Even worse, if placeholder text accidentally makes it through to production, it looks much worse than showing the default text.
Does anyone have any suggestions (or solutions) for determining which of these two conditions is the reason for default text appearing during manual testing?
If I understood you correctly you want to verify that every localizable text is indeed in fact localizable and not burned in the code. To do this you should not be using a real culture (Spanish), instead you should create resources for a fake unsupported culture and provide an automatic translation for every localizable resource entry available in the default resources.
For example, if you have a default resource containing:
Entry1: This is a test!
you should create a resource in your fake culture containing:
Entry1: Th1s 1s # t€st!
You could even (and should) perform the creation of the fake resources automatically using a simple character mapping. This way, when you set the application to use your custom fake culture you know that every entry has a translation so you can find harcoded text. This strategy is used by Windows and is known as pseudo-locales. The use of pseudo translated strings makes it possible do development using the fake culture because the text is still readable and this improves your probability of finding hardcoded text.
Windows supports pseudo-locales since Windows Vista and Windows 2008 R2, so if your build and testing environment uses these operating systems you can associate your fake culture to one of these pseudo locales (for example qps-ploc). If you have unsupported operating systems just associate your fake resources to a real culture that you probably will never be supporting or just create your own culture.
Also note that even in a supported operating system, Visual Studio will not create satellite assemblies for these pseudo-locales unless you enable them on the registry.
I use a *.resx file for the localization purpose. The Name - it's a phrase or word in English. The Value - the translation to another language of that phrase. I choose this approach to have a one localization file for the whole application. And anyone who have this file can make translation by themselves.
But in the Visual Studio 2010 resx editor, each record with name which have spaces in it, have a warning: "The resource name is not a valid identifier."
Though it compiles and works, but please tell me if I am doing something wrong here.
First of all, the idea of the resx files is to have a separate resource file for each culture. You can provide the new translation by creating a new file with different values for the same keys.
For example, you can create Forms.en-GB.resx, Forms.pl-PL.resx, Forms.de-DE.resx and the appropriate file will be picked up based on the current UI culture without you having to do anything (except ensuring relevant culture is set).
Visual Studio will generate a resource class that contains all your key/value pairs from resource file as properties - that makes it easier to use in code. The warning you get means that the keys you've provided in resource file are not a valid identifiers (they contain spaces). You might want to use _ instead of space in the keys.
If you don't want to use the generated class you can ignore this warning - your resx files are fine and can be used directly. You can remove ResXFileCodeGenerator from 'Custom Tool' property of your resx file (properties windows) or set 'Access Modifier' to 'No code generation' in resx file editor if you do not need to generate a class, but you will still get the warning.
The strength of localization with resx files is that the culture on your computer decides what language your application should be in. If you keep to one resx file, according to me, you ignore it's power. Instead, try making a resx file for each language you want to integrate. for example: the default language is english, then you have a default page localization.resx where you only keep english sentences. Say you need a French translation, make another resx file called localization.fr-FR.resx. So users who have the fr-FR culture enabled on there computer will have that language on the program without any code specific work. If someone with a culture not integrated in your application starts the program, it will look for it, and if it doesn't find it, it chooses the default, ie english, one.
So to my opinion, don't use 1 resx file for different languages, but use the powers given in the framework.
I suppose it works, but it's not really the strategy you are supposed to follow.
Take a look here; the basic idea is that you take advantage of the controls in .NET to automatically get the correct localisation themselves, so you kind of don't need to worry about doing the translating.
Though, I don't use this all the time, and I do somewhat do as you do, but I tend to use an identifier, so I may have:
UserWelcome Hey, {name}, thanks for dropping by ...
And then I'll translate that. It's helpful because it allows generality in the languages (say, for example, some languages should be greeted formally, and others not, you don't want to be contrained by a direct translation of, "You", say).
Hope this is clear.
If what you've got works, then I suppose that's something, but it's not the "general" way of doing it.
I have localized localized a Form into two language by setting the Localizable property to True and setting the Language from (Default) to (Dutch(Netherlands)), and I changed the control texts.
Visual Studio generated the resource files and compiles them into the application.
I need to get a simple list of all the languages that my form has been localized into. Currently it would be just two English and Dutch, but more may come. I need to programatically get a list of "what languages my application is localized into". Do I look into the resource files or use ResourceManager or what?
Thanks!
For every language the form is localized to, you would get a satellite assembly within a folder. The folder name would be the specific culture. Ex: en-GB for English (United Kingdom).
These folders would be created in the Application's base directory.
Populate the folder names in the Listbox, when a user selects an item store it in the config.
And in the Main, before Form load set the current culture and current UI culture.