219
There are a lot of improvements to be made on the 'translation' experience to be on par with the translation experience in C/AL. These suggestions are not about external XLIFF editing tooling, but about the process inside VSCode.
Here are some suggestions / feedback:
- Moving around Labels (e.g. cut-paste from table to codeunit), reusing labels (copy-paste) or renaming labels ('Text001' to VarMsg / fixing typos) often breaks the translations since it changes the trans-unit ids. In C/AL, copy-pasting a Text constant always kept all translations.
- As ISV, XLIFF files can be usefull to send to an external translation agent on a periodic basis. However, as VAR, the developer (team) is responsible to deliver per tenant extension in English AND native language on a daily basis. In C/AL, CaptionML ruled. In VSCode, we should have an as-easy alternative to immediately add the translation in VSCode (not using LCS / external extensions - tools / databases to maintain - import translations). Providing a VSCode extension (cfr. AL outline, AL object browser, ...) showing all translations of the current object in a Grid style, containing the aggregated contents of the various Xliff files in columns, allowing grid updates, auto-updating the xliff files.
- In general, hide the complexity of having to copy / overwrite / merge xliff files by language. Please keep the translation XLIFF files automatically in sync upon building an extension with any changes like newly added fields / labels, renamed / refactored labels, ...
- Maintain a 'global' dictionary of translations that can be referenced all over the extension. (Table) Fields / labels / variables (on pages or report datasets) which are copied on multiple objects should reference a single translation. This reduces the no. of translations and improves the uniformity.
- Allow adding 'tooltips' on 'table' fields instead of pages, with the option to reference the global dictionary.
- Discover / mark translations where the source has been changed. Changing a source translation requires possible target translations to be reviewed. E.g. when adding an option to an OptionCaption, all translations require review.
- Provide CodeCop(?) alternatives to the PowerShell commandlets to ease dealing with translations to detect missing Captions.
Here are some suggestions / feedback:
- Moving around Labels (e.g. cut-paste from table to codeunit), reusing labels (copy-paste) or renaming labels ('Text001' to VarMsg / fixing typos) often breaks the translations since it changes the trans-unit ids. In C/AL, copy-pasting a Text constant always kept all translations.
- As ISV, XLIFF files can be usefull to send to an external translation agent on a periodic basis. However, as VAR, the developer (team) is responsible to deliver per tenant extension in English AND native language on a daily basis. In C/AL, CaptionML ruled. In VSCode, we should have an as-easy alternative to immediately add the translation in VSCode (not using LCS / external extensions - tools / databases to maintain - import translations). Providing a VSCode extension (cfr. AL outline, AL object browser, ...) showing all translations of the current object in a Grid style, containing the aggregated contents of the various Xliff files in columns, allowing grid updates, auto-updating the xliff files.
- In general, hide the complexity of having to copy / overwrite / merge xliff files by language. Please keep the translation XLIFF files automatically in sync upon building an extension with any changes like newly added fields / labels, renamed / refactored labels, ...
- Maintain a 'global' dictionary of translations that can be referenced all over the extension. (Table) Fields / labels / variables (on pages or report datasets) which are copied on multiple objects should reference a single translation. This reduces the no. of translations and improves the uniformity.
- Allow adding 'tooltips' on 'table' fields instead of pages, with the option to reference the global dictionary.
- Discover / mark translations where the source has been changed. Changing a source translation requires possible target translations to be reviewed. E.g. when adding an option to an OptionCaption, all translations require review.
- Provide CodeCop(?) alternatives to the PowerShell commandlets to ease dealing with translations to detect missing Captions.
STATUS DETAILS
Under Review
Comments
- Duplicating objects is often done (copying files from one project to another, make a copy from unposted table to posted, from standard BC report to a custom report) but lacks the possibility to include / duplicate the related translations of the source object too
Category: Development
Business Central Team (administrator)
Thank you for your feedback. We are considering adding it to our longer term roadmap.