.NET Resources
.NET resource localization from .resx files.
Translate the .resx files in your source, with forms in the form editor, check them, and write Form1.de.resx next to each file. Your build compiles the translated files into satellite assemblies, as before.
- Input
.resxfiles from your source; also.reswand.resources- Output
Form1.de.resxnext to each source file- Runtime
- Your build makes satellites; .NET loads them by UI culture
- Preview
- Forms in the form editor (Safe); strings in the table
On this page
Tutorial
Localize .NET resource files, step by step.
The RESX workflow: translated .resx files go back to your source, and your build makes the satellites.
Lingobit translates the .resx files; your build makes the satellites.
Lingobit reads each .resx file of your project and writes a translated copy next to it: Strings.de.resx, Strings.fr.resx. Visual Studio or MSBuild compiles them into satellite assemblies in culture folders, and at startup .NET loads the resources of the current UI culture.
Lingobit does
- Translates strings and form properties in your
.resxfiles, and shows forms in the form editor. - Reuses earlier translations and the translation memory.
- Checks placeholders such as
{0}, hotkeys, empty and too long translations, and more. - Writes
Form1.de.resxand the other languages next to each source file.
Your project keeps
- The
.resxfiles in source control, with the translated ones. - The build that compiles satellite assemblies.
- Loading the resources and choosing the language.
- The final test in the running application.
RESX files or the compiled build: choose by what you keep.
Translate the .resx files when the translated files must live in source control. When you only ship the build, translating the compiled assemblies gives the full form preview and needs no rebuild.
| RESX files | Compiled build | |
|---|---|---|
| Input | .resx files from your source | .exe, .dll |
| Preview | Forms in the Safe editor; strings in the table | Forms in the Full editor, or Safe |
| Output | Translated .resx files; your build makes the satellites | .resources.dll satellites, ready to ship |
| Use when | Translated files stay in source control and go through your build | You ship the compiled application |
Reference
Culture decides which resources load.
.NET takes each resource from the best match it has for the current UI culture: de-AT, then de, then the neutral resources in the main assembly.
- A missing string shows the neutral text from
Strings.resx; it does not break the application. - Translate to the parent culture.
Strings.de.resxservesde-DE,de-AT, andde-CH. Lingobit names the file after the project language: German writesStrings.de.resx, German (Germany) writesStrings.de-DE.resx, which serves onlyde-DE.
// Strings.resx generates a class; the property reads the current UI culture
label.Text = Strings.ExportSummary;
// or through ResourceManager
var rm = new ResourceManager("MyApp.Strings", typeof(Program).Assembly);
string text = rm.GetString("ExportSummary");Choose the language in your app.
Set the culture before the first resource is read; otherwise .NET uses the Windows language:
var culture = CultureInfo.GetCultureInfo(LoadSavedLanguage() ?? "en-US");
CultureInfo.DefaultThreadCurrentCulture = culture;
CultureInfo.DefaultThreadCurrentUICulture = culture;Do and don't.
Do
- Keep UI text in
.resx; move hard-coded C# and VB strings with Lingobit Extractor. - Keep resource names stable: translations are matched to them.
- Set
Localizable = trueon forms, so their text is in the form's.resx. - Commit the translated
.resxfiles and let your build make the satellites.
Don't
- Edit
Form1.de.resxby hand: the next Create overwrites it. - Rename resources after translation has started without a reason.
- Build messages in code from translated pieces.
- Send
.resxfiles to translators: they work in Lingobit.
Troubleshooting.
| Symptom | Likely cause | What to do |
|---|---|---|
| The application stays in English | The translated .resx files are not in the project, so no satellite was built, or the UI culture has no match | Include the files in the project, rebuild, and check the culture folders next to the application |
| A form has no text to translate | Its Localizable property is false, so the text is in code | Set Localizable = true in the designer and run Scan for Changes |
| Translations are New again after an update | Resources were renamed | Keep names stable; import translations from your existing translated .resx files |
| The application crashes with one language | A translation breaks a placeholder such as {0} | Run Validation: it reports placeholders that do not match the source |
The ASP.NET ResX sample.
Localizer installs an ASP.NET Web Forms sample whose text is in .resx files.
- Pages, a master page, and a user control with their resources in
App_LocalResources. - Global resources in
Properties\Resources.resx, translated in the same project.
More about .NET resource localization.
Why teams keep the RESX source/build workflow
Input: Resources.resx ValidationMessages.resx SharedResources.resx
Output: Resources.de.resx ValidationMessages.de.resx SharedResources.de.resx- Translations stay in source control, and developers review resource changes as normal source changes.
- Visual Studio, MSBuild, or CI stays responsible for the final satellite assemblies.
- Several projects can share the same RESX resources.
- The trade-off: localization stays tied to development.
Compiled .resources files and satellite assemblies
During the build, RESX files are compiled into binary resources: the neutral resources go into the main assembly, the localized ones into .resources.dll satellite assemblies in culture folders such as de\, fr\, or ja\. At runtime, ResourceManager selects resources by CurrentUICulture.
Compiled .resources files are usually intermediate build artifacts. They appear in some workflows, but standard .NET deployment uses satellite assemblies.
Hardcoded C# strings to review with Extractor
Not every user-visible message starts in a RESX file. Lingobit Extractor finds hardcoded C# strings and moves them into RESX resources. Review in particular:
- validation and error messages shown to users;
- command output, status messages, and labels or captions created in code;
- emails, notifications, and reports.
ASP.NET Core and Blazor
Resources that IStringLocalizer reads in ASP.NET Core and Blazor are ordinary .resx files, such as Resources\Messages.resx: Lingobit writes Messages.de.resx next to the source, and the app shows the German text. The visual form editor is for Windows Forms forms only; these files are translated as strings in the table. Text written inside .cshtml and .razor markup is not translated: move it into .resx.
Reuse existing .NET translations
Add the current original files, choose the target languages, and import the translations that still match from existing .resources.dll satellite assemblies, localized .resx files, or previous localized builds.
Related paths
- WinForms — Translate the compiled build, with the Full form editor.
- WPF / BAML — Windows and resources from compiled assemblies.
- Lingobit Extractor — Move hard-coded strings into .resx.
- Migration — Import existing translated .resx files.