Localized file check-in by OneLocBuild Task: Build definition ID 9434: Build ID 13982412

[dotnet-bot]

This is the pull request automatically created by the OneLocBuild task in the build process to check-in localized files generated based upon translation source files (.lcl files) handed-back from the downstream localization pipeline. If there are issues in translations, visit https://aka.ms/icxLocBug and log bugs for fixes. The OneLocBuild wiki is https://aka.ms/onelocbuild and the localization process in general is documented at https://aka.ms/AllAboutLoc.

[github-actions]

Localization PR Review — OneLocBuild #13980159

✅ Structural Integrity

• All 91 changed files are .xlf localization files — no unexpected file types.
• No <source> elements or <note> elements were modified.
• No trans-units were added or removed.
• XML structure is well-formed across all files.

✅ Format Specifiers

All format specifiers ({0}, {1}, etc.) are preserved correctly in all translated strings. No mismatches between source and target placeholders.

✅ Positive Changes

4 French translations (MissingGetItemError, MissingGetPropertyError, MissingGetTargetResultError, SolutionBuildInvalidForCommandLineEvaluation) are correctly going from state="new" to state="translated" with proper French text. 👍

---

⚠️ Issue 1: Missing spaces after format specifiers in Czech (2 strings)

In src/Build/Resources/xlf/Strings.cs.xlf:

1. BuildCheck_BC0301_MessageFmt: Umístění {0}nemůže — missing space between {0} and nemůže. At runtime the substituted value will run directly into the next word.
2. UnknownLoggingType: není pro {1}srozumitelný — missing space between {1} and srozumitelný.

These will produce garbled output like C:\Downloadsnemůže být plně důvěryhodné.

⚠️ Issue 2: 416 translation state regressions (translated → new)

This is the most significant concern. 32 unique trans-unit IDs across all 13 languages are having their translations reverted to English source text with state="new". This means users will see English instead of their localized language for these strings.

Affected trans-unit IDs (32):
BuildEngineCallbacksInTaskHostUnsupported, CannotConvertStringToBool, CollectionIsReadOnly, ConflictingTaskAssembly, CouldNotGenerateReferenceAssemblyDirectory, DebugPathTooLong, DotnetHostPathNotSet, Exec.CommandExitedZeroWithErrors, ExpectedEventToBeSerializable, FailedCreatingTempFile, GenerateResource.STRPropertySkippedInvalidIdentifier, GenerateResource.STRPropertySkippedNameCollision, GenerateResource.STRPropertySkippedReservedName, GenerateResource.STRPropertySkippedVoidType, GlobExpansionFailed, InvalidAttributeMetadata, InvalidFilespecForTransform, InvalidGetPathOfFileAboveParameter, ModifyingTaskHostEnvironmentHeader, ModifyingTaskHostEnvironmentVariable, PathTooLong, Shared.CannotChangeItemSpecModifiers, Shared.InvalidFilespecForTransform, Shared.ParameterCannotBeNull, Shared.ParameterCannotHaveZeroLength, Shared.PathTooLong, TaskNotMarshalByRef, ToolTask.ToolCommandExitedZeroWithErrors, UnsupportedFrameworkVersion, UnsupportedFrameworkVersionForWindowsSdk, UnsupportedVisualStudioVersion, Xaml.CommandExitedZeroWithErrors

Affected file areas:

• src/Framework/Resources/xlf/SR.*.xlf — 13 files
• src/MSBuildTaskHost/Resources/xlf/SR.*.xlf — 13 files
• src/Tasks/Resources/xlf/Strings.*.xlf — 10 files
• src/Build/Resources/xlf/Strings.*.xlf — 13 files
• src/Utilities/Resources/xlf/Strings.*.xlf — 11 files
• src/Shared/Resources/xlf/Strings.shared.zh-Hant.xlf — 1 file

This is a known pattern with OneLocBuild when source strings are modified — the localization pipeline resets affected strings to state="new" until they are re-translated downstream. If that's the case here, this is expected and the strings will be translated in a subsequent localization PR. However, if these source strings have not actually changed, this would indicate a pipeline issue worth investigating.

Summary

The translation quality improvements in this PR are good, but the 2 Czech spacing bugs should be filed for correction, and the 416 state regressions should be confirmed as intentional (source string changes awaiting re-translation) rather than accidental translation loss.

Generated by Expert Code Review (on open) for issue #13656 · ● 4.7M

[github-actions]

Bug: Missing space after format specifier {0}

The translated string has {0}nemůže — the format placeholder {0} is directly followed by the word nemůže with no space. At runtime, when {0} is replaced (e.g. with a path like C:\Downloads), the output will be C:\Downloadsnemůže být plně důvěryhodné. — the path runs directly into the Czech word.

Previous translation correctly had a colon and quotes: Umístění: '{0}' nelze plně považovat za důvěryhodné

Should be: Umístění {0} nemůže být plně důvěryhodné. (with a space before nemůže).

[github-actions]

Bug: Missing space after format specifier {1}

The translated string has {1}srozumitelný — the format placeholder {1} runs directly into the word srozumitelný. At runtime, when {1} is replaced, the output will have no space between the substituted value and the following word.

Should be: ...není pro {1} srozumitelný. (with a space before srozumitelný).

[github-actions]

Translation regression: state="translated" → state="new"

This string (DotnetHostPathNotSet) was previously translated into Czech and is now being reverted to English with state="new". Users will see untranslated English text.

This same regression pattern affects 416 strings total across all 13 languages (32 unique trans-unit IDs). See the overall review summary for the full list.