1

The generation of the XLIFF source translate file should be handled in a separate step that can be executed via Shell/PowerShell. As it stands right now, the only way of generating a translation file of an AL project is by compiling the associated extension. Likewise, compiling a project with the feature "TranslationFiles" enabled will always generate the target translation file. This has multiple problems:

  • Generating the target file requires multiple dependencies, such as the AL compiler and AL packages.
  • Any compile errors will stop the translation pipeline.
  • Runtime for updating the target translation is made much longer.
  • Modifying code can easily result in merge conflicts when tracking the target file. The target file can remain untracked, but this makes translation services such as Weblate more complicated, as there is no target file available in the repository.

I don't know at what stage during the compilation the XLIFF file can be created, but in any case, a separate script or executable and the option to skip (though that might be accomplished by removing the "TranslationFiles" feature) would make it possible to delegate upkeep of the target translation file to a single source and make it easily accessible to translation services.

Category: Development
STATUS DETAILS
Needs Votes
Ideas Administrator

Thank you for this suggestion! Currently this is not on our roadmap. We are tracking this idea and if it gathers more votes and comments we will consider it in the future. Best regards, Business Central Team