Translate a .NET Application into English (.resx Files)

What an English .resx means for your project

In a .NET project, each interface string is a <data name="BtnSave"> entry holding a <value> and often a <comment>. The English version is a separate file sitting next to the neutral one: Strings.resx in your source language, then Strings.en.resx, or Strings.en-GB.resx and Strings.en-US.resx if you target both variants.

At runtime, .NET looks for the exact culture (en-GB), then the parent culture (en), then falls back to the neutral file. So a key missing or left untranslated in the English file quietly shows up in the source language, with no error. That is the first thing to look for once the file is back in the project.

English is usually more compact than Romance and Germanic source languages; from French it typically runs 10 to 15% shorter (« Enregistrer les modifications » becomes Save changes). Buttons and grid columns gain room. In WinForms forms, whose .resx also stores control sizes and positions, check controls where automatic sizing is turned off.

English-specific points in a .NET interface

• Variant. Decide up front: colour or color, organise or organize, cancelled or canceled. Mixing them in one interface is noticeable. If you serve both audiences, keep separate en-GB and en-US files.
• Plurals. English has two categories, one and other, and zero takes the plural: 0 files. Several source languages, French among them, treat zero as singular. If your code picks the key with count <= 1 ? FileCount_One : FileCount_Other, English will show 0 file. Use count == 1 for English. The .resx format has no plural mechanism: it is two keys and a decision in code.
• Punctuation. No space before colons or question marks: a French Nom : becomes Name:. Angle quotes and inverted Spanish marks give way to English quotation marks.
• Capitalisation. Buttons and headings use either sentence case (Save changes), common in British interfaces, or title case (Save Changes), frequent in American ones. Pick one rule and keep to it.
• Dates. British English reads 03/04/2025 as 3 April, American English as 4 March. A pattern like dd/MM/yyyy hard-coded in a value is not translated; prefer standard CultureInfo formats such as {0:d}.

What Manuce returns, and what it does not do

You upload your .resx file and get back the same file, in the same format, ready to drop into the project:

• data/value elements are translated; <comment> elements are used as context and left unchanged;
• non-text resources (images, icons, control sizes and positions) stay intact;
• indentation, key order, quotes, comments, line endings, encoding and BOM are preserved; only the values change;
• not translated: keys, empty values, URLs, email addresses, numbers, colours, date formats, identifiers and anything marked as non-translatable.

Every translated value is checked against its source: {0}, {1:N2} or a <b> tag must all be present. If a mismatch persists, the source value is kept and the report says so, so you know exactly which string will stay in the source language in your English build, and why.

Manuce does not change your code: it does not fix plural logic, regenerate .Designer.cs, or extract strings hard-coded in C# or XAML. Nor does it rename the file; saving it as Strings.en.resx or Strings.en-GB.resx is up to you. Pricing is based on the words in the values, with keys and tags excluded.

Preparing the .resx before upload

• Resolve ambiguity with comments. A source verb meaning validate can become Validate, Confirm or Submit; an adjective meaning open can be Open (state) or Opened (past action). A comment such as Form submit button, 12 characters max steers the translation.
• Remove concatenation. A sentence built as "Deleted by " + user + " on " + date in code cannot be translated cleanly, because word order and prepositions differ. Store it as one value with placeholders, for example Deleted by {0} on {1}.
• Split singular and plural. Create FileCount_One and FileCount_Other rather than a file(s) style value, which reads awkwardly in English.
• Flag what must not change. Product names, codes or technical labels to keep verbatim: mark them non-translatable.
• Check placeholders. An unclosed {0 in the source will fail the comparison; fix it before uploading.

Checking after you add the file back

1. Read the report: every string left in the source language is listed with its reason.
2. Save the file under the chosen culture name and build: an en or en-GB folder with the satellite assembly should appear in the output.
3. Force the culture to test, for instance CultureInfo.CurrentUICulture = new CultureInfo("en-GB"), and go through each screen: any remaining source-language text points to a missing key or a kept value.
4. Test counters at 0, 1 and 2, messages built with {0}, and labels followed by a colon.
5. Check the variant: a stray color in an en-GB interface is a one-line fix.

For an interface shipped to customers, the Professional or Premium level fits; Essential is enough for an internal test build.

In practice

1. Choose your English culture (en, en-GB or en-US) and add comments to ambiguous strings.
2. Upload the neutral .resx file: the quote appears at once, based on the words in the values.
3. Review the free extract at your chosen level, then start the translation.
4. Rename the returned file for the culture, add it to the project and build.
5. Read the report and test the app with the English culture forced.