Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
#8,367 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
powershell
Área
testing

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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
Lenguaje dominante
PowerShell
Estrellas
889
Forks
285
Merge medio
4 h 7 min
PR fusionados (30 d)
1

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de microsoft/AL

Todos los issues de microsoft/AL

Issues similares

Más issues de Testing & QA

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.