[Txt2Al] addafter on Pages

[LFlamme]

Hi,

When i convert pages with german and english caption, txt2al uses the german captions in addafter. That of course doesnt work.

To Reproduce Extend a standard page, give Caption ML for german and english. Convert using txt2al.

Expected behavior english caption is used, or addafter works with german captions

Versions:

• AL Langauge: 2.1.69331
• Business Central: CU2 (Build 26556)

[thpeder]

Hi @LFlamme,

I'm not able to reproduce your problem. I took a standard page, Filled in the CaptionML for ENU and DEU. exported, created the delta file, converted to AL but I didn't see the problem. Could you please provide some more information on how to reproduce the issue, best of all if you could provide some C/AL files, like it is done in #1618

[LFlamme]

Hi,

Here´s a delta file, that produces the problem: PAG5050.zip the action will be added with addafter("Be&merkungen").

might there be a difference between tx2al.exe if u install DE or W1?

[ralf-escher]

Hi,

I have the same problem, the DELTA file uses the german CaptionML for the AddAfter command

  PROPERTIES
  {
    Target="Posted Sales Shipment"(Page 130);
    TargetPageType=Document;
  }
  CHANGES
  {
    { Insertion         ;InsertAfter=AddAfter:"&Paketverfolgung"(Action 79);
                         ChangedElements=ActionCollection

which leads to an unknown control in the AL file:

    actions
    {
        addafter("&Paketverfolgung")
        {
            action("Als transportiert markieren")
            {

Business Central Spring Release CU2 (Application Build 34444, Platfrom Build 34251)

[ralf-escher]

After some investigation:

If you use the "Export-NAVApplicationObject" PowerShell command with the "-ExportToNewSyntax" option, then the name of a control/action/... is filled by the CaptionML value, which leads to the problem with the generated AL file.

I tried the "Set-Culture" command with "en-US" with the same (negative) result. Seems like the "Export-NAVApplicationObject" command is responsible.

[ralf-escher]

By using the docker container: mcr.microsoft.com/businesscentral/onprem:1904-cu2-de-ltsc2019 and using the New-NavContainer PowerShell command, I got correct objects within C:\ProgramData\NavContainerHelper\Extensions\Original-14.3.34444.0-de-newsyntax

[ralf-escher]

New discovery: seems to be some kind of setting or registry entry since my collegue can generate correct controls

[qutreson]

@ralf-escher is your colleague also running the same docker image (on the same version)? Is this issue still blocking you (and your colleagues) as it seems that you were able to have it working in your container?

[ralf-escher]

@qutreson: we completly switched to work with docker, therefore the problem is solved that way for us. Nevertheless the problem still occurs if I export the object from our sql server (just tested with BC14-CU5).

[dannoe]

The PowerShell command is using the user language from the fin.zup Change your finsql.exe to english and close it. Then run the Export-NAVApplicationObject again.

[github-actions[bot]]

Hi,

Many thanks for raising this issue. Unfortunately we have not been able to get to this issue as soon as we'd have liked. Since it has been a long time since this issue was last updated, it is possible that this has been fixed by a newer release of Business Central and the AL extension for Visual Studio Code. We have thus decided to close it.

If the issue still affects you on the latest insider build of Business Central, please help us and open a new issue for us with the latest steps to reproduce the issue, and link back to this closed issue to track any comments or discussions.

Thanks,
Thaddeus

[lv-janpieter]

We had this issue as well, suddenly appeared because I opened al old 2009 database changed the language in the ZUP file. In our case it was definitely the finsql language being set to Dutch. Setting this back resolved the problem. Just remember ZUP is only saved when closing finsql.