Skip to content

Localization test failures 1#24407

Merged
sharwell merged 15 commits intodotnet:dev15.7.xfrom
MaStr11:FixLocalizationTestFailures1
Feb 14, 2018
Merged

Localization test failures 1#24407
sharwell merged 15 commits intodotnet:dev15.7.xfrom
MaStr11:FixLocalizationTestFailures1

Conversation

@MaStr11
Copy link
Copy Markdown
Contributor

@MaStr11 MaStr11 commented Jan 23, 2018

Fix for #23837.

This is the first of a series of PRs meant to resolve the unit test failures caused by missing localizations.

This PR includes test related to csi.exe and interactive scripting:

Microsoft.CodeAnalysis.CSharp.Scripting.UnitTests

Done. Tested local (de-DE) and CI (en-US).

Microsoft.CodeAnalysis.CSharp.Scripting.Desktop.UnitTests

Done. Tested local (de-DE) and CI (en-US).

Microsoft.CodeAnalysis.VisualBasic.Scripting.UnitTests

Done. Tested local (de-DE) and CI (en-US).

Roslyn.InteractiveHost.UnitTests

Done. Tested local (de-DE) and CI (en-US).

@MaStr11 MaStr11 requested a review from a team as a code owner January 23, 2018 21:55
>
", result.Output);
";
expected = expected.Replace((char)0x2013, (char)0x002d); // EN DASH -> HYPHEN-MINUS
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

csi.exe outputs the en dash in Microsoft (R) Visual C# - interaktive Compilerversion 42.42.42.42424 as hyphen-minus. There might be a more reliable way to fix this.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

💭 Seems weird to have an en dash in a resource string.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

@MaStr11 Please add a more detailed comment explaining why the replacement is necessary. Something like:

The German translation (and possibly others) contains an en dash (0x2013), but csi.exe outputs it as a hyphen-minus (0x002d). We need to fix up the expected string before we can compare it to the actual output.

@MaStr11 MaStr11 requested a review from a team as a code owner January 24, 2018 10:08
…g for VB but I corrected the corresponding test in C#. Changes in C# are partially reverted (test is sipped again) and VB is fixed.
@MaStr11 MaStr11 changed the title Localization test failures 1 [WIP] Localization test failures 1 Jan 24, 2018
>
", result.Output);
";
expected = expected.Replace((char)0x2013, (char)0x002d); // EN DASH -> HYPHEN-MINUS
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

💭 Seems weird to have an en dash in a resource string.

Microsoft (R) Visual C# Interactive Compiler version {s_compilerVersion}
Copyright (C) Microsoft Corporation. All rights reserved.
var expected = $@"
{ string.Format(CSharpScriptingResources.LogoLine1, s_compilerVersion) }
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

💡 No spaces inside the braces for interpolated strings.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

@MaStr11 I should be able to clean this up in the future for all of this repository using automated tools. This feedback is more for future work.

@sharwell
Copy link
Copy Markdown
Contributor

TODO: Uncomment //[UseCulture("en-US")] once #24398 is merged

#24398 is now merged.

@sharwell
Copy link
Copy Markdown
Contributor

@MaStr11 Can you update the original comment to replace the TODO text with the current status?

@MaStr11
Copy link
Copy Markdown
Contributor Author

MaStr11 commented Jan 24, 2018

#24398 is now merged.

I gave it a try and I can confirm that it indeed works as intended. Ironically it didn't help in this particular case because the test did a process.Start and captured the output from the running csi.exe. So the culture of the test itself changes nothing as this is always tied to the culture of the machine. I fixed it by using the string resource (as it should anyway).

@sharwell
Copy link
Copy Markdown
Contributor

Requesting reviews from @dotnet/roslyn-compiler and @dotnet/roslyn-interactive

Copy link
Copy Markdown
Member

@jaredpar jaredpar left a comment

Choose a reason for hiding this comment

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

Compiler changes look good.

@sharwell sharwell self-assigned this Jan 25, 2018
@sharwell sharwell added this to the 15.6 milestone Jan 25, 2018
var logoOutput = $@"{ string.Format(CSharpScriptingResources.LogoLine1, s_compilerVersion) }
{ CSharpScriptingResources.LogoLine2}

{ ScriptingResources.HelpPrompt}";
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Could you extract to a static field (similar to s_compilerVersion) and then use the field in all test cases?

@MaStr11
Copy link
Copy Markdown
Contributor Author

MaStr11 commented Jan 25, 2018

Sure I could. But there are cases where you want your tests to run in a particular culture using the [UseCulture] attribute. So there is a benefit in keeping the tests self contained.

VBScriptingResources.LogoLine2 + "

Type ""#help"" for more information.
" + ScriptingResources.HelpPrompt + "
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Extract to a static field

@tmat
Copy link
Copy Markdown
Member

tmat commented Jan 25, 2018

🕐

@tmat
Copy link
Copy Markdown
Member

tmat commented Jan 25, 2018

There are perhaps a few of such tests that use a different culture. They would not use this field then. Majority tests do not care about the "logo" lines and it would make them more readable. Also authoring a new test would be easier.

@sharwell
Copy link
Copy Markdown
Contributor

sharwell commented Jan 25, 2018

💭 I tend to prefer self-contained tests, and don't see the issue with having the string inlined in multiple tests. However, /src/Scripting/ is not one of the paths where I'm in the code owner group so we tend to defer to the preference of the code owner in these cases.

@tmat
Copy link
Copy Markdown
Member

tmat commented Jan 25, 2018

@sharwell The tests are already not self-contained anyways -- they use s_compilerVersion and other helpers.

@MaStr11
Copy link
Copy Markdown
Contributor Author

MaStr11 commented Jan 25, 2018

@tmat I'm currently changing the tests. I also facing a problem with the tests that change the Culture during the test (It seems the culture is persisted. So half of the tests run in de-DE while the other run in en-GB). I will need some more time to fix this.

@MaStr11
Copy link
Copy Markdown
Contributor Author

MaStr11 commented Jan 25, 2018

I'm done with the changes now (Sorry for the messy commit history).


" + ScriptingResources.HelpPrompt
Dim runner = CreateRunner(args:={}, input:="Imports System.Globalization
' Save the current thread culture as it is changed in the test.
Copy link
Copy Markdown
Contributor

@sharwell sharwell Jan 25, 2018

Choose a reason for hiding this comment

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

❓ The UseCulture attribute should restore the culture at the end of the test. Is it possible to use it here?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

There are two differences.

  1. UseCulture sets Current thread.Culture while this test sets CultureInfo.DefaultThreadCulture.
  2. UseCulture also sets the culture at the beginning of the test

I think it is better the way it is but haven't tried UseCulture.

…e1 to use three different cultures. Test shows unexpected results.
…UICulture1 to use three different cultures. Test shows unexpected results."

This reverts commit 8e05074.
@MaStr11
Copy link
Copy Markdown
Contributor Author

MaStr11 commented Jan 26, 2018

The UseCulture attribute should restore the culture at the end of the test. Is it possible to use it here?

@sharwell I gave it a try in commit 8e05074. I changed UseCultureAttribute to also set DefaultThreadCurrentUICulture. But doing so caused all kinds of unpredictable side-effects (It seemed to me that the UseCultureAttribute.After method is not able to revert to the previous system state by setting DefaultThreadCurrentUICulture. I just gave up after a while. The version of UseCulture pushed in 8e05074 had some bugs, but even the corrected version showed the same results.) and so I reverted the change.

@tmat I found two problems with vbi.exe during my tests:

  1. Inputing >and pressing enter gives a NRE in SyntaxFactory.IsPartOfLinqQueryNotFollowedByNewLine (This error is re-produceable in other circumstances too, but that is the easiest one). Is this a known bug or should I file an issue?
  2. Is it expected that ? New System.DateTime always outputs #1/1/0001 12:00:00 AM# no matter what DefaultThreadCurrentUICulture is set?

@sharwell sharwell modified the milestones: 15.6, 15.7 Jan 26, 2018
@sharwell sharwell changed the base branch from dev15.6.x to dev15.7.x January 26, 2018 15:56
<InternalsVisibleToTest Include="Microsoft.CodeAnalysis.Scripting.Destkop.UnitTests" />
<InternalsVisibleToTest Include="Microsoft.CodeAnalysis.CSharp.Scripting.UnitTests" />
<InternalsVisibleToTest Include="Microsoft.CodeAnalysis.CSharp.Scripting.Desktop.UnitTests" />
<InternalsVisibleToTest Include="Roslyn.InteractiveHost.UnitTests" />
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

@sharwell Since you asked for approval for InternalsVisibleToTest in #24460 you may also want approval for this one.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

👍 This one should be covered under the umbrella of the review from @jaredpar.

@sharwell
Copy link
Copy Markdown
Contributor

@tmat Can you answer the two final questions from @MaStr11 in the last comment above?

@sharwell sharwell changed the base branch from dev15.7.x to dev15.7.x-vs-deps February 14, 2018 16:09
@sharwell sharwell changed the base branch from dev15.7.x-vs-deps to dev15.7.x February 14, 2018 16:09
@sharwell sharwell merged commit 6bfea1a into dotnet:dev15.7.x Feb 14, 2018
@MaStr11 MaStr11 deleted the FixLocalizationTestFailures1 branch March 2, 2018 15:17
@AlekseyTs
Copy link
Copy Markdown
Contributor

@sharwell This PR was merged without getting required sign-offs from the compiler team and it doesn't deal with localization issues in the manner that other compiler tests do. I think it should be reverted and different fixes should be made.

@AlekseyTs AlekseyTs self-assigned this Mar 6, 2018
@sharwell
Copy link
Copy Markdown
Contributor

sharwell commented Mar 7, 2018

@AlekseyTs This pull request did not touch compiler code.

@AlekseyTs
Copy link
Copy Markdown
Contributor

This PR made changes to CSharpCodeAnalysis.csproj, it also touched Scripting and Csi tests, even though they are not under Compilers folder, they used to be owned by Compiler team at some point. @jaredpar To clarify the current ownership for the tests.

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.

6 participants