Localize strings in OutputWindowHelper #6059

lauren-ciha · 2025-12-04T22:03:07Z

Resolves #6030

Validation (VS 2026, x64):

Added custom strings in the {Language}\Common\es-ES\VSPackage.es-ES.resx files
Switched VS into Spanish
Set breakpoints where the strings are initialized
At each breakpoint, verified that the localized version was used

This pull request adds new localized resource strings and updates how output window messages are handled for both the C# and C++ Visual Studio extensions. The changes ensure that the output window uses localized titles and messages, improving consistency and maintainability across both extensions.

Localization and Output Window Improvements:

Added new resource strings 1053 ("General") and 1054 ("No output information available.") to both VSPackage.resx files for C# and C++ extensions, and updated the corresponding designer files to expose these as properties. [1] [2] [3] [4]
Updated OutputWindowHelper.cs to use the localized "General" string for the output window pane title and the new "No output information available." string as the default message when output is missing. [1] [2] [3]

Code Generation and Versioning:

Changed the GeneratedCodeAttribute version in both C# and C++ VSPackage.Designer.cs files from "18.0.0.0" to "17.0.0.0" to match the tool version used for code generation. [1] [2]. Although VS 2022 was used to generate the Designer files, the VSIXes are still compatible with VS 2026.

A microsoft employee must use /azp run to validate using the pipelines below.

WARNING:
Comments made by azure-pipelines bot maybe inaccurate.
Please see pipeline link to verify that the build is being ran.

For status checks on the main branch, please use TransportPackage-Foundation-PR
(https://microsoft.visualstudio.com/ProjectReunion/_build?definitionId=81063&_a=summary)
and run the build against your PR branch with the default parameters.

…ion.cs

Copilot

Pull request overview

This PR localizes output window messages in the Visual Studio extensions for both C# and C++ by replacing hardcoded strings with resource-based localized strings. The changes improve maintainability and enable proper localization support for the output window functionality.

Key changes:

Added two new localized resource strings: "General" (1053) and "No output information available." (1054)
Updated OutputWindowHelper.cs to consume localized strings from the appropriate VSPackage resources
Modified GeneratedCodeAttribute version from "18.0.0.0" to "17.0.0.0" in designer files

Reviewed changes

Copilot reviewed 3 out of 5 changed files in this pull request and generated 2 comments.

File	Description
dev/VSIX/Shared/OutputWindowHelper.cs	Added resource imports and updated code to use localized strings for output window pane title and default message
dev/VSIX/Extension/Cs/Common/VSPackage.resx	Added localized resource entries 1053 and 1054 for C# extension
dev/VSIX/Extension/Cpp/Common/VSPackage.resx	Added localized resource entries 1053 and 1054 for C++ extension

Files not reviewed (2)

dev/VSIX/Extension/Cpp/Common/VSPackage.Designer.cs: Language not supported
dev/VSIX/Extension/Cs/Common/VSPackage.Designer.cs: Language not supported

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2025-12-04T22:08:55Z

dev/VSIX/Shared/OutputWindowHelper.cs


+// Although the strings are the same in the wizard for both extensions,
+// they are included with both their respective VSPackages.
+// Strings for both extensions can be found in {PathToWindowsAppSDK}\dev\VSIX\Extension\Cs\Common\VSPackage.resx


The comment only references the C# VSPackage.resx path but should also mention the C++ path since both extensions have their own resource files. Consider updating to: 'Strings for both extensions can be found in {PathToWindowsAppSDK}\dev\VSIX\Extension\Cs\Common\VSPackage.resx and {PathToWindowsAppSDK}\dev\VSIX\Extension\Cpp\Common\VSPackage.resx'

Suggested change

// Strings for both extensions can be found in {PathToWindowsAppSDK}\dev\VSIX\Extension\Cs\Common\VSPackage.resx

// Strings for both extensions can be found in {PathToWindowsAppSDK}\dev\VSIX\Extension\Cs\Common\VSPackage.resx and {PathToWindowsAppSDK}\dev\VSIX\Extension\Cpp\Common\VSPackage.resx

Copilot · 2025-12-04T22:08:55Z

dev/VSIX/Shared/OutputWindowHelper.cs

+                    var noOutputString = Resources._1054;
+                    pane.OutputStringThreadSafe(message ?? noOutputString);


The resource string is being retrieved inside a conditional block that only executes when pane is not null. However, if message is not null, the noOutputString variable is unnecessarily retrieved but never used. Consider moving the resource retrieval inside the null-coalescing operation or checking if message is null before retrieving the resource to avoid unnecessary resource lookups.

Suggested change

var noOutputString = Resources._1054;

pane.OutputStringThreadSafe(message ?? noOutputString);

pane.OutputStringThreadSafe(message ?? Resources._1054);

I agree with that. It is a small fix but a performance improvement.

guimafelipe

Overall, I agree with Copilot's comments on this one, but not blocking.

guimafelipe · 2025-12-05T17:51:23Z

dev/VSIX/Shared/OutputWindowHelper.cs

                // Create pane if it doesn't exist
                if (pane == null)
                {
-                    hr = outputWindow.CreatePane(ref guidGeneral, "General", 1, 1);


I am again realizing how I don't like the fact that the Resources class uses numbers as the name of the properties that return the strings we want. This makes it a bit hard to read. I would love if this was something like Resources.GeneralTitleString.

I agree. I've created this issue to capture this improvement so we can work on it in another PR.

lauren-ciha · 2025-12-05T19:23:55Z

/azp run

azure-pipelines · 2025-12-05T19:24:10Z

Azure Pipelines successfully started running 1 pipeline(s).

* Setting strict mode and error action preference to stop on remaining PS scripts (#5950) * Setting strict mode and error action preference to stop on remaining powershell scripts * Fixing install VCLibs script * Shorten VSIX DisplayName to fit 50 char limit when Experimental prefix is added (#5953) * [main] Update dependencies from microsoft/LiftedIXP/DCPP (#5955) * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20251029.6 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.0.0-experimental-27200.1830.251013-1313.4 -> To Version 2.0.0-experimental-27200.1822.251028-1938.4 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.0.1-experimental -> To Version 2.0.2-experimental * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20251030.2 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.0.0-experimental-27200.1830.251013-1313.4 -> To Version 2.0.0-experimental-27200.1835.251029-1735.1 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.0.1-experimental -> To Version 2.0.3-experimental --------- Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> * Disabling flaky push notification test (#5980) * Update bug-report.yaml (#5983) * API Spec: PackageValidator API in PackageManagement.md (#5863) Added documentation for new proposed API for PackageValidation * update issue template for 1.8.3 and 2.0-exp3 (#5993) * [WinAppSDK]: Update resourceManagement.yml (#5988) * Update resourceManagement.yml close issue only if bot comment is posted * fix yml * minor improvements * Fix: getting activity context by reference (#6000) * Fix FileTypeChoices in Storage Pickers to preserve insertion order (#5948) **Description** This is a fix for issue: - #5827 The existing FileTypeChoices property was built on an unordered map, which does not preserve the user-defined order. However, in the FileOpenPicker and FileSavePicker, the FileTypeChoices need to be displayed in the order they were inserted, rather than in a random order. This is important for developers' and end-users' experience because: - Developers expect to see their file type options in the logical order they added them - The first added option is usually the default selection - Maintaining consistent ordering helps end users quickly locate the desired file type Additionaly, the insertion order is respected in the legacy UWP FileSavePicker. **Fix** This is a backward-compatible fix. The goal of this fix is to maintain the existing Map type API contract and its good performance while ensuring that the display order of FileTypeChoices meets expectations. This pull request refactors the implementation of the `FileTypeChoicesMap` to ensure that the insertion order of keys is preserved and provides efficient key lookups. It replaces the previous unordered map-based implementation with the implementation backed by a vector. The update also introduces custom iterator and view classes to support this ordered behavior and modifies related tests to verify the new insertion order. * Revert "Fix: getting activity context by reference (#6000)" (#6004) This reverts commit 2b9dff7. * Migrate net6 to net8 for the Test Sample app (#6003) * Migrate net6 to net8 for the Test Sample app * Rollback change for local test first * Fix also the runtime identifier path * Increasing timeout to try to avoid flakiness (#6010) * Reapply "Fix: getting activity context by reference (#6000)" (#6004) (#6009) This reverts commit 60ea859. * Bugfix: the filter name for FileOpenPicker.FileTypeFilters #6005 * Add localization for NuGet Install Wizard for the VS templates (#5989) * Initial localization commit * Realign and add missing package messages to resources * Update s_resourceManager to _resourceManager * Lazy initialize ResourceManager to make it thread safe * Make Resources not static * Dev in progress, adding error messaging * Resources load without error * Capture localization dev/test state * Undo dev/test configuration and remove wait dialog error check * Resolve conflicting Designer file * Move VSPackage.Designer files back to Common (where resources are) * Update Cpp error message string to include where to find details * Include satellite assemblies * Reset source.extension.vsixmanifests * Remove WizardStringHelper * Clean up null check and spacing * Add copyright headers to VSPackage.Designer.cs files * Passing activity context as argument for deployment methods (#6011) * Passing context as argument for deployment methods * Fixing call for add package methods * Fix: DeploymentManager failing with error package downgrade (#6021) * Dont break on first failure * Adding tests * Movint package removal to cleanup method * Changing GUID to a random one * Changing name from Singleton2 to SingletonHigherVersion * Adding check for registered packages * Fix on verify packages method * Test enhancements suggestion * Fix on verify packages method 2 * Revert "Fix on verify packages method 2" This reverts commit 10060a6. * Revert "Fix on verify packages method" This reverts commit 1c5eb9b. * Bugfix: FileSavePicker.PickSaveFileAsync() should not truncate file when the picked file exists. **Description** This PR is part of the solution of issue - #5976 In `PickSaveFileAsync`, if the picked file exists, user will see a warning prompt re-confirming if the picked file can be overwrite. <img width="1100" height="574" alt="image" src="https://github.com/user-attachments/assets/d956dd69-d4e0-4b11-85e6-b6a79e732418" /> **Then, if user selected "Yes", the FileSavePicker directly truncate the picked file to be empty.** This is not an expected behavior, and it can block some scenarios, such as: - Developers may need to read original content after the file is picked. - Developers may want to add some extra confirmation step before fully overwriting the file (as described in the issue). Additionally, the UWP FileSavePicker won't directly truncate the picked save file in method PickSaveFileAsync(). **Fix** Updating the file creation method to be: - If the picked file doesn't exist, create an empty file. - if the picked file already exist, do nothing, do not truncate it. * add missing samples ref (#5935) * Update dependencies from https://dev.azure.com/microsoft/ProjectReunion/_git/WindowsAppSDKAggregator build 2.0.251120.1-experimental (#6025) [main] Update dependencies from microsoft/ProjectReunion/WindowsAppSDKAggregator * Add ManualValidation step for RuntimeCompatibilityChange in servicing builds (#6028) * add a manual validation stage * variable to allow bypassing for experimental/preview * Update dependencies from https://dev.azure.com/microsoft/ProjectReunion/_git/WindowsAppSDKAggregator build 2.0.251125.1-experimental (#6038) [main] Update dependencies from microsoft/ProjectReunion/WindowsAppSDKAggregator * [Build] Replace LTSC2019 with LTSC2022 on Foundation repo (#6042) * Update WindowsContainerImage to use ltsc2022 * Update WindowsAppSDK-BuildDevCheck.yml * Add WindowsHostVersion parameter to YAML configuration * Add WindowsHostVersion parameter to YAML file * Add WindowsHostVersion parameter to YAML file * Add WindowsHostVersion parameter to YAML config * Update dependencies from https://dev.azure.com/microsoft/ProjectReunion/_git/WindowsAppSDKAggregator build 2.0.251128.1-experimental (#6046) [main] Update dependencies from microsoft/ProjectReunion/WindowsAppSDKAggregator * Update VS Template (#5994) * Localize strings in OutputWindowHelper (#6059) * Localize strings for OutputWindowHelper * Name strings with variables * Add back copyright for VSPackage.Designer.cs files * Keep OutputWindowHelper.cs newlines consistent with WizardImplementation.cs * Remove extra string variables for performance * Making verify package method default to the highest version found (#6026) * Fix on verify packages method * Initializing highest version found to the version being search * Removing match boolean * Using variable instead of winrt call * Using versions to comparisons * Adding singleton lower version package and test * Adding verification for package registering in test * Adding test with multiple singleton versions * Getting Started Documentation: Improving common errors session readability (#6041) * Improving common errors session of getting started doc * Removing extra empty line * Update VSIX resource files to include NuGet wizard strings (#6067) * Update README.md (#6073) * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20251216.1 (#6079) On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.0.0-experimental-27200.1835.251029-1735.1 -> To Version 2.0.0-experimental-27200.1845.251215-1020.3 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.0.3-experimental -> To Version 2.0.4-experimental Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> * Test-VisualStudioComponent now detects missing components (#6092) --------- Co-authored-by: Felipe G <guima.felipec@gmail.com> Co-authored-by: Lauren Ciha <laurenciha@microsoft.com> Co-authored-by: dotnet-maestro[bot] <42748379+dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: Roy <59626501+RDMacLachlan@users.noreply.github.com> Co-authored-by: letao-msft <72979394+letao-msft@users.noreply.github.com> Co-authored-by: ssparach <128866445+ssparach@users.noreply.github.com> Co-authored-by: Dinah Xiaoman G <116714259+DinahK-2SO@users.noreply.github.com> Co-authored-by: Gordon Lam <73506701+yeelam-gordon@users.noreply.github.com> Co-authored-by: alexlamtest <68841560+alexlamtest@users.noreply.github.com> Co-authored-by: Niels Laute <niels.laute@live.nl> Co-authored-by: Ryan Shepherd <ryansh@microsoft.com>

lauren-ciha added 2 commits December 4, 2025 11:12

Localize strings for OutputWindowHelper

d983811

Name strings with variables

c718383

microsoft-github-policy-service bot added the needs-triage label Dec 4, 2025

lauren-ciha added 2 commits December 4, 2025 14:05

Add back copyright for VSPackage.Designer.cs files

556ce96

Keep OutputWindowHelper.cs newlines consistent with WizardImplementat…

41a296f

…ion.cs

lauren-ciha marked this pull request as ready for review December 4, 2025 22:08

lauren-ciha requested a review from Copilot December 4, 2025 22:08

Copilot AI reviewed Dec 4, 2025

View reviewed changes

lauren-ciha requested review from guimafelipe and ssparach December 4, 2025 22:09

MSLukeWest approved these changes Dec 5, 2025

View reviewed changes

guimafelipe approved these changes Dec 5, 2025

View reviewed changes

Remove extra string variables for performance

b8a60fc

guimafelipe approved these changes Dec 5, 2025

View reviewed changes

lauren-ciha merged commit 142b6e7 into main Dec 5, 2025
36 checks passed

lauren-ciha deleted the user/laurenciha/localize-outputwindowhelper branch December 5, 2025 21:03

lauren-ciha mentioned this pull request Dec 9, 2025

Update VSIX resource files to include NuGet wizard strings #6067

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Localize strings in OutputWindowHelper #6059

Localize strings in OutputWindowHelper #6059

Uh oh!

lauren-ciha commented Dec 4, 2025 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Dec 4, 2025

Uh oh!

Copilot AI Dec 4, 2025

Uh oh!

guimafelipe Dec 5, 2025

Uh oh!

guimafelipe left a comment

Uh oh!

guimafelipe Dec 5, 2025

Uh oh!

lauren-ciha Dec 5, 2025 •

edited

Loading

Uh oh!

lauren-ciha commented Dec 5, 2025

Uh oh!

azure-pipelines bot commented Dec 5, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

	// Strings for both extensions can be found in {PathToWindowsAppSDK}\dev\VSIX\Extension\Cs\Common\VSPackage.resx
	// Strings for both extensions can be found in {PathToWindowsAppSDK}\dev\VSIX\Extension\Cs\Common\VSPackage.resx and {PathToWindowsAppSDK}\dev\VSIX\Extension\Cpp\Common\VSPackage.resx

		var noOutputString = Resources._1054;
		pane.OutputStringThreadSafe(message ?? noOutputString);

	var noOutputString = Resources._1054;
	pane.OutputStringThreadSafe(message ?? noOutputString);
	pane.OutputStringThreadSafe(message ?? Resources._1054);

Localize strings in OutputWindowHelper #6059

Localize strings in OutputWindowHelper #6059

Uh oh!

Conversation

lauren-ciha commented Dec 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Dec 4, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 4, 2025

Choose a reason for hiding this comment

Uh oh!

guimafelipe Dec 5, 2025

Choose a reason for hiding this comment

Uh oh!

guimafelipe left a comment

Choose a reason for hiding this comment

Uh oh!

guimafelipe Dec 5, 2025

Choose a reason for hiding this comment

Uh oh!

lauren-ciha Dec 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lauren-ciha commented Dec 5, 2025

Uh oh!

azure-pipelines bot commented Dec 5, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

lauren-ciha commented Dec 4, 2025 •

edited

Loading

lauren-ciha Dec 5, 2025 •

edited

Loading