Skip to content

Commit

Permalink
Enable XLF-based localization
Browse files Browse the repository at this point in the history
1. Add the XliffTasks package for all projects.
2. Automatically update XLF files during build on dev machines.
3. Opt-in to the .NET Core satellite assembly generation task.
4. Turn off localization for non-shipping projects by default.
5. Work around an issue in locale-neutral CTO generation.
  • Loading branch information
tmeschter committed Dec 5, 2017
1 parent 55e1a6d commit 3669d04
Show file tree
Hide file tree
Showing 3 changed files with 48 additions and 0 deletions.
33 changes: 33 additions & 0 deletions build/Targets/Imports.targets
Original file line number Diff line number Diff line change
Expand Up @@ -121,6 +121,12 @@
</When>
</Choose>

<!-- Settings for localization -->
<PropertyGroup>
<!-- Only turn on localization for shipping binaries. -->
<EnableXlfLocalization Condition="'$(NonShipping)' == 'true'">false</EnableXlfLocalization>
</PropertyGroup>

<Choose>
<When Condition="'$(SignAssembly)' == 'true'">
<Choose>
Expand Down Expand Up @@ -300,6 +306,33 @@
</VSIXSourceItem>
</ItemDefinitionGroup>

<!--
This is a workaround for allowing neutral CTO resource produced from *.vsct to go in the main assembly.
We move the neutral *.cto file to be categorized as WithCulture=true,Culture=en to prevent the tools from falsely reporting:
error VSSDK1006: Two CTO files have the same Menus.ctmenu resource name.
Note that this categorization does not apply to the items that actually produce the .resources.dll and so it will
not cause an English satellite to be generated.
The documented way around this is to put all resources (including neutral/en) in satellites:
https://msdn.microsoft.com/en-us/library/ee943168.aspx
However, that has consequences we do not want:
- It breaks resx code-gen to *.designer.cs
- It causes extra dll loads in en case
- If we ever split satellites in to language packs, the english fallback satellites would become a special case.
-->
<Target Name="AssignEnCultureToNeutralCto" BeforeTargets="MergeCtoResource">
<ItemGroup>
<_GeneratedCTOFilesWithCulture Include="@(_GeneratedCTOFilesWithNoCulture)">
<Culture>en</Culture>
<WithCulture>true</WithCulture>
</_GeneratedCTOFilesWithCulture>
<_GeneratedCTOFilesWithNoCulture Remove="@(_GeneratedCTOFilesWithNoCulture)" />
<_ResourcesToMergeWithCTOWithCultureMetadata Condition="'%(WithCulture)' != 'true'">
<Culture>en</Culture>
<WithCulture>true</WithCulture>
</_ResourcesToMergeWithCTOWithCultureMetadata>
</ItemGroup>
</Target>

<ImportGroup Condition="'$(ImportVSSDKTargets)' == 'true'">
<Import Project="$(NuGetPackageRoot)\Microsoft.VSSDK.BuildTools\$(VisualStudioBuildToolsVersion)\build\Microsoft.VsSDK.BuildTools.targets" />
<Import Project="$(VSToolsPath)\VSSDK\Microsoft.VsSDK.targets" />
Expand Down
1 change: 1 addition & 0 deletions build/Targets/Packages.props
Original file line number Diff line number Diff line change
Expand Up @@ -230,6 +230,7 @@
<VSSDKComponentModelHostVersion>12.0.4</VSSDKComponentModelHostVersion>
<VsWebsiteInteropVersion>8.0.0.0-alpha</VsWebsiteInteropVersion>
<vswhereVersion>1.0.71</vswhereVersion>
<XliffTasksVersion>0.2.0-beta-000080</XliffTasksVersion>
<xunitVersion>2.2.0</xunitVersion>
<xunitanalyzersVersion>0.5.0</xunitanalyzersVersion>
<xunitassertVersion>2.2.0</xunitassertVersion>
Expand Down
14 changes: 14 additions & 0 deletions build/Targets/Settings.props
Original file line number Diff line number Diff line change
Expand Up @@ -140,6 +140,16 @@
<DeterministicSourceRoot Condition="'$(DeveloperBuild)' != 'true'">/_/</DeterministicSourceRoot>

<EnableSourceLink Condition="'$(DeveloperBuild)' != 'true'">true</EnableSourceLink>

<!-- It is only intended to automatically run update during dev cycle. However, It will fail the build on CI if the XLF file is not updated.
XLF file should be checked in and loc team will update the XLF it with translated version.
-->
<UpdateXlfOnBuild Condition="'$(DeveloperBuild)' == 'true'">true</UpdateXlfOnBuild>

<!-- Even when we're using the "desktop" version of MSBuild we always want to use the "Core" approach for generating satellite assemblies.
This avoids a couple of issues in al.exe (see https://github.com/dotnet/roslyn/issues/23190 and https://github.com/dotnet/roslyn/issues/23191
for details on those issues). -->
<GenerateSatelliteAssembliesForCore>true</GenerateSatelliteAssembliesForCore>
</PropertyGroup>

<!-- Windows specific settings -->
Expand Down Expand Up @@ -223,6 +233,10 @@
-->
<Import Project="$(ToolsetCompilerPropsFilePath)" Condition="Exists('$(ToolsetCompilerPropsFilePath)') AND '$(BootstrapBuildPath)' == '' AND '$(OS)' == 'Windows_NT'" />

<ItemGroup>
<PackageReference Include="XliffTasks" Version="$(XliffTasksVersion)" PrivateAssets="All" />
</ItemGroup>

<!--
Language specifc settings
Expand Down

0 comments on commit 3669d04

Please sign in to comment.