Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move user-facing strings to resource files #1109

Merged
merged 30 commits into from
Mar 23, 2022
Merged

Conversation

j0shuams
Copy link
Contributor

@j0shuams j0shuams commented Feb 16, 2022

This PR introduces resx and rc files for user-facing strings in the C#/WinRT toolchain. These are error messages from various tools we use - WinRT.Host, WinRT Authoring Diagnostics, and WinRT.Runtime. Included in these changes is logic in the respective projects to load resource strings from these resource files.

We will need to add a TDBuild task to our CI YML templates, and properly package the resulting localized files. Some of the code used for loading will need to be updated to find the language/region specific versions of the resource files.

TDBuild onboarding deliverable: https://globalcollaborationservice.visualstudio.com/Global%20Collaboration%20Service%20Project/_workitems/edit/106432

@j0shuams j0shuams requested a review from manodasanW February 16, 2022 18:45
@angelazhangmsft angelazhangmsft linked an issue Feb 16, 2022 that may be closed by this pull request
@j0shuams
Copy link
Contributor Author

j0shuams commented Feb 23, 2022

Per discussion with Ben, I'm looking into using .mui files instead of the satellite dll for winrt.host errors

@@ -22,6 +22,7 @@
<HostingAssets Include="$(MSBuildThisFileDirectory)..\build\native\WinRT.Host.runtimeconfig.json"/>
<!-- Get the proper WinRT.Host.dll -->
<HostingAssets Include="$(MSBuildThisFileDirectory)..\runtimes\win-$(_NormalizedPlatform)\native\WinRT.Host.dll" />
<HostingAssets Include="$(MSBuildThisFileDirectory)..\runtimes\win-$(_NormalizedPlatform)\native\en-us\WinRT.Host.dll.mui" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whats the story here for localized ones if en-us is the main one copied Is it up the component owners to pack the others based on which ones they want? Same for below where you use en-us.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I think automating minimally is better in this case so we don't always output many binaries in their project. The different culture/regions will be available in the nupkg, so they can distribute the whole lot if they want. But we will just handle en-us for them, for now. If we get feedback from folks that they prefer a different model we can adjust accordingly.

@j0shuams j0shuams merged commit 1acc2bc into master Mar 23, 2022
@j0shuams j0shuams deleted the jlarkin/localize-3 branch May 17, 2022 20:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Localization - move user facing strings into string table
3 participants