Translations must be provided for the following language codes: en-US

[salgiza]

Since the latest AL extension update we are required to specify supported countries in the AppSourceCop.json, and this seems to check that language translations exist for the target countries.

However, is this warning correct?

  warning AS0057: Translations must be provided for the following language codes: en-US

The source language, in the autogenerated Translations\AppName.g.xlf file, is en-US. Do we really have to create a translation of en-US into en-US?

[atoader]

Hi @salgiza! That rule is meant for applications that are submitted to AppSource. You should consider it disabling it if it does not make sense for you. I don't think the rule makes sense when doing active development, but it does make sense in a CI/CD pipeline.

[salgiza]

Why does it make sense in a CI/CD pipeline?

I mean, I'm fine if we have to copy the file every time, we were actually doing it up until not so long ago, when we were told that the en-US file was actually not required to submit the app to the AppSource and stoped including it. But other than the hassle of having to create a copy of the *.g.xlf file when we compile the app, I don't understand why is it needed :S

[atoader]

Fair enough! I will have to take a look at it. The .g.xlf is generated after the compilation is complete so it might be that the rule analyzing this does not see it because it runs before it is generated.

[atoader]

I was not able to reproduce the problem when starting out with an empty project. Is there anything else I should take into account?

[salgiza]

I've created a new project, added TranslationFile to the app.json (here is the full test app.json I created, with some dummy data so that the analyzer doesn't complain too much):

{
  "id": "57dc2781-6fa4-43c5-9fad-b59b465d268a",
  "name": "ALProject1",
  "publisher": "Default publisher",
  "version": "1.0.0.0",
  "brief": "Test",
  "description": "Test",
  "privacyStatement": "https://Test",
  "EULA": "https://Test",
  "help": "https://Test",
  "url": "https://Test",
  "logo": "Logo216x216.png",
  "dependencies": [
    {
      "appId": "63ca2fa4-4f03-4f2b-a480-172fef340d3f",
      "publisher": "Microsoft",
      "name": "System Application",
      "version": "1.0.0.0"
    },
    {
      "appId": "437dbf0e-84ff-417a-965d-ed2bb9650972",
      "publisher": "Microsoft",
      "name": "Base Application",
      "version": "15.0.0.0"
    }
  ],
  "screenshots": [],
  "platform": "15.0.0.0",
  "idRanges": [
    {
      "from": 50100,
      "to": 50149
    }
  ],
  "contextSensitiveHelpUrl": "https://ALProject1.com/help/",
  "showMyCode": true,
  "runtime": "4.0",
  "features": [
    "TranslationFile"
  ]
}

This is the .vscode\settings.json file:

{
    "al.enableCodeAnalysis": true,
    "al.codeAnalyzers": [
        "${AppSourceCop}",
        "${CodeCop}"
    ]
}

And this is the AppSourceCop.json file:

{
    "mandatoryPrefix": "TEST",
    "supportedCountries": ["ES","US"]
}

Funny things I've noticed:

• Just as I created the project, set it up, and compiled, it complained all the time, no matter how many times I compiled.
• I closed and reopened VS Code and it stopped complaining.
• I deleted the Translations\ALProject1.g.xlf file, and it started complaining again, every time I compiled (not just the first time before it was generated).
• I closed and reopened VS Code and it stopped complaining.
• I edited the AppSourceCop.json (I swapped the order of the languages, the *.g.xlf file was left untouched) and it started raising the warning again.
• I closed and reopened VS Code and it stopped complaining.

So it seems that it effectively works most of the time, but it complains when the .g.xlf is missing, even though it is going to be generated... and keeps complaining until you restart VS Code*, regardless of the fact that it exists. The fact that it failed when I edited the AppSourceCop.json totally puzzles me, though.

[ALGitHubBot]

The fix for this issue has been checked in to the master branch. It will be available in the bcinsider.azurecr.io/bcsandbox-master Docker image starting from platform build number 38574.

If you don’t have access to these images you need to become part of the Ready2Go program: aka.ms/readytogo

For more details on code branches and docker images please read: https://blogs.msdn.microsoft.com/nav/2018/05/03/al-developer-previews-multiple-releases-and-github/ https://blogs.msdn.microsoft.com/freddyk/2018/04/16/which-docker-image-is-the-right-for-you/

[ALGitHubBot]

The fix for this issue has been checked in to the master branch. It will be available in the bcinsider.azurecr.io/bcsandbox-master Docker image starting from platform build number 38574.

If you don’t have access to these images you need to become part of the Ready2Go program: aka.ms/readytogo

For more details on code branches and docker images please read: https://blogs.msdn.microsoft.com/nav/2018/05/03/al-developer-previews-multiple-releases-and-github/ https://blogs.msdn.microsoft.com/freddyk/2018/04/16/which-docker-image-is-the-right-for-you/