`al runtests` produces German errors when `GlobalLanguage()` reports 1033

The reproduction uses an AL test codeunit and al runtests against Business Central; no repository source file or test location is identified. Start by checking how the CLI initializes test sessions and whether it sets a language, then trace the reported mismatch between System.GlobalLanguage() and the validation error language. Done means the language behavior is explained and the issue's expected behavior is addressed or documented.

Please include the following with each issue:

1. Describe the bug

When running AL tests through al runtests, a standard Business Central validation error is returned in German even though System.GlobalLanguage() reports 1033 (English, United States) immediately before the validation.

Explicitly calling System.GlobalLanguage(1033) before the same validation makes the error English and the test passes.

The cause of the language selection is unknown. Is this expected behavior, and is there a way to control the test language centrally when using al runtests?

2. To Reproduce

1. Use a Business Central on-premises environment with German translations available.

2. Add the following codeunit to a test app with a dependency on the Microsoft Library Assert app.

3. Publish and install the test app.

4. Configure authentication for the development endpoint. For UserPassword, set BC_SERVER_USERNAME and BC_SERVER_PASSWORD as environment variables; do not include credentials in the command.

5. Run the tests, replacing the server, instance and port with your environment's values:

   al runtests 50100 `
       --server 'http://<server>' `
       --serverinstance '<instance>' `
       --port 7049 `
       --tenant default `
       --authentication UserPassword `
       --testmethods ReproDefaultTestLanguage `
       --testmethods ReproExplicitEnglishLanguage
   

codeunit 50100 "Test Error Language Repro"
{
    Subtype = Test;
    TestPermissions = Disabled;

    [Test]
    procedure ReproDefaultTestLanguage()
    var
        Customer: Record Customer;
        Assert: Codeunit Assert;
    begin
        Customer.Init();

        // This assertion passes in the affected environment.
        Assert.AreEqual(1033, System.GlobalLanguage(), 'Session language');

        asserterror Customer.TestField("No.");

        Assert.ExpectedError('must have a value');
    end;

    [Test]
    procedure ReproExplicitEnglishLanguage()
    var
        Customer: Record Customer;
        Assert: Codeunit Assert;
    begin
        Customer.Init();
        System.GlobalLanguage(1033);

        asserterror Customer.TestField("No.");

        Assert.ExpectedError('must have a value');
    end;
}

The test methods were verified within an existing test codeunit. The standalone codeunit above is an adaptation for reproduction.

Additional observations from the affected environment:

• The server's ServicesLanguage was en-US; DefaultLanguage was empty.
• Setting the test user's Language ID to 1033 and restarting the service tier did not resolve the original failures. The user's Locale ID remained 2055.
• Deleting the user personalization record and restarting also did not resolve them.
• The captured developer-endpoint request did not send an Accept-Language header. Injecting Accept-Language: en-US through a local proxy did not change the result.
• The observed TestRunnerHub initialization and test-run messages did not contain a language parameter. The CLI help does not expose a language option.

3. Expected behavior

When System.GlobalLanguage() reports 1033, the validation error should be in English, or the behavior and the way to configure the test language should be documented.

Both test methods should produce the same result when the reported language is already 1033.

4. Actual behavior

ReproDefaultTestLanguage passes the language assertion but fails the error assertion:

Assert.ExpectedError failed. Expected: must have a value.
Actual: 'No.' muss in 'Customer' einen Wert enthalten: 'No.='.
Der Wert darf nicht null oder leer sein.

ReproExplicitEnglishLanguage passes after explicitly setting System.GlobalLanguage(1033).

Result: 1 passed, 1 failed, 0 skipped.

5. Versions:

• AL CLI: 30.0.44.47290+3c92cdc4ab04cab72c5db0204d4d91609bd6dc04 (microsoft.dynamics.businesscentral.development.tools 30.0.44.47290-beta)
• Business Central: server 29.0.56990.0; Application, Base Application and System Application 29.0.54011.57023
• Operating System:
  • Windows - Windows 11 Enterprise, build 26200
  • Linux
  • MacOS

Final Checklist

• Search the issue repository to ensure you are reporting a new issue
• Simplify your code around the issue to better isolate the problem