.NET Resources · Translators

Translate .resx files without handing out .resx files.

Translators should not edit XML, and a spreadsheet you convert with a script loses keys, comments, and the strings that changed since last time. Lingobit Localizer reads your .resx files, gives translators a task in the format they work in, takes the work back by resource key, and writes Strings.de.resx next to the source.

ProjectDEFRJAMyApp.locStrings.resxNew OrderMessages.resx PrepareTranslationTaskImportTranslationResults TranslatorDENew OrderNeue BestellungCustomer:Kunde:CreateErstellenSourceGermanNew OrderNeue BestellungCustomer:Kunde:Quantity:Menge:Validation on save Or their CAT toolXLIFF 1.2for the tool the translatoralready uses ProjectDEFRJAMyApp.locStrings.resxNew OrderMessages.resx PrepareTranslation Task TranslatorDENew OrderNeue BestellungCustomer:Kunde:CreateErstellenSourceGermanNew OrderNeue BestellungCustomer:Kunde:Quantity:Menge:Validation on save Or their CAT toolXLIFF 1.2for the tool the translatoralready uses ImportResults
Input
.resx, .resw from your source
For translators
Translator Edition, XLIFF 1.2, or CSV
Matched by
Resource key
Output
Strings.de.resx next to the source
On this page

Why a .resx file is a poor thing to send a translator.

A .resx file is a build input, not a translation document. What goes wrong when it travels:

  • XML breaks. An unescaped & or <, or a deleted tag, and the build fails, often after the file is back in the project.
  • Forms carry more than text. The .resx of a localizable form also holds sizes, positions, and images that a translator should not touch.
  • Placeholders get lost. {0} translated or removed shows up only when the message appears at runtime.
  • Every release starts over. Nobody can see which of the 2,000 strings are new or changed since the last delivery.

Pick the format your translators work in.

Prepare Translation Task writes the task; Import Translation Results reads it back. Every edition sends and receives all three.

Delivery formats for translators and what each keeps
FormatForWhat travels
Translator project (.ltp) or Delivery BundleTranslators in Translator Edition, which is included with every Localizer licenseThe strings with their statuses, forms in the Safe editor, validation; the bundle adds the setup and your instructions
XLIFF 1.2Agencies and translators with a CAT toolThe strings with states that become statuses on import. XLIFF details
CSVA spreadsheet or a text editorOne file per language; statuses are not kept

Step by step.

  1. Add the .resx files to a Lingobit project and choose the languages. The neutral files stay as they are.
  2. Bring in what is translated with Import Translations from Localized Files: it reads your existing Strings.de.resx and the other languages.
  3. Optionally pre-translate with DeepL, Google Translate, or Azure Translator on your own account (Professional and higher). These translations get the Auto status, so they go to review.
  4. Prepare Translation Task in the format from the table. The Translation Task filter takes only strings that are not Complete or Locked, plus what Scan for Changes marked new or changed.
  5. Import Translation Results when the work comes back. Strings are matched by key; Output lists what changed.
  6. Validate and create Validation reports placeholders such as {0} that do not match the source; Create Localized Files writes Strings.de.resx next to each source file.
  7. Build as before Your build compiles the translated files into satellite assemblies. Next release: Scan for Changes, and a new task with only the new and changed strings.

Lingobit names the file after the project language: German writes Strings.de.resx, German (Germany) writes Strings.de-DE.resx. The same works for .resx files of ASP.NET Core and Blazor and for .resw files; see the .NET Resources guide.

Translations already in a spreadsheet?

Many teams keep a sheet with English in one column and each language in the next. You do not need a conversion script.

A sheet of source and translation pairs

Save it as CSV and import it into translation memory. Import Matching Translations then fills each string whose source text matches an entry; strings with other text stay for the translator.

A CSV task that comes back

A CSV file you sent with Prepare Translation Task goes back in with Import Translation Results, into the current target language. Advanced sets the encoding, the delimiters, and which column is the ID, the original text, and the translation.

Questions about translating .resx files

Can translators edit .resx files in Excel?

Excel can open the XML, but saving it back as a valid .resx with every key, comment, and form property intact is fragile. Send them a CSV task instead: it opens in a spreadsheet, and Import Translation Results puts the translations back by key.

Does Lingobit change Strings.resx or Designer.cs?

No. It reads the neutral .resx files and writes translated copies such as Strings.de.resx next to them. The generated Strings class reads the translated resources when the UI culture matches.

Can I translate .resx files automatically?

Yes, with DeepL, Google Translate, or Azure Translator and your own account, in Professional and higher. Text goes to the provider only when you use machine translation. The results get the Auto status, and the Needs Review filter gives them to a reviewer.

Do translators see the forms?

In Translator Edition, a localizable form in a .resx opens in the Safe editor, so the translator sees where the text goes. With XLIFF or CSV they see the strings only.

Should I translate the .resx files or the compiled build?

Translate the .resx files when the translated files must live in source control and go through your build. When you only ship the build, translating the compiled assemblies gives the full form preview and needs no rebuild; see WinForms and WPF.