You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If an AL project uses an external translation service such as Weblate, it would be very useful to expose the source translation file through some workflow. I've requested splitting the compiler and XLIFF generator into two separate scripts, but as long as this feature remains unimplemented, I think it's best to give AL Go an option to add the source translation file to the output of the CI/CD workflow, since this pipeline already generates the required file.
While it is possible to have the developers push changes to the translation files, this solution comes with many unnecessary merge conflicts, and this solution could avoid this by putting a dedicated source in charge of the translation files.
The solution would require a setting like addTranslationToArtifacts, which simply enforces the TranslationFiles feature flag for the compiler and adds the *.g.xlf files into their own zip file and adds them to the workflow artifacts.
Alternatively, the build pipeline could also push changes to the source translation file - that way, developers wouldn't have to generate the translation file on build, and it would still be in the repository.
The text was updated successfully, but these errors were encountered:
Translation is something we will be looking at to add to AL-Go for GitHub and I have been collecting ideas for this.
I will add this information to that pile.
If an AL project uses an external translation service such as Weblate, it would be very useful to expose the source translation file through some workflow. I've requested splitting the compiler and XLIFF generator into two separate scripts, but as long as this feature remains unimplemented, I think it's best to give AL Go an option to add the source translation file to the output of the CI/CD workflow, since this pipeline already generates the required file.
While it is possible to have the developers push changes to the translation files, this solution comes with many unnecessary merge conflicts, and this solution could avoid this by putting a dedicated source in charge of the translation files.
The solution would require a setting like
addTranslationToArtifacts
, which simply enforces theTranslationFiles
feature flag for the compiler and adds the*.g.xlf
files into their own zip file and adds them to the workflow artifacts.Alternatively, the build pipeline could also push changes to the source translation file - that way, developers wouldn't have to generate the translation file on build, and it would still be in the repository.
The text was updated successfully, but these errors were encountered: