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.
Comments
Tanslation tools (like the before mentioned XLIFFSync and Poedit) also change the developer note node from
(removed brackets to bypass malicious input check)
note from="Developer" annotates="general" priority="2" /note
to
note from="Developer" annotates="general" priority="2"/
Consistency here would also be nice
Category: Development
"- 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."
This is very badly needed, it would solve so many issues, such as breaking trans units when moving labels around. Some translations are duplicated over 20 times in the code.
Category: Development
There are a lot of good ideas in here but the most important is to make the tooltip property inherit from the table just like captions do. I can't believe we have to create ideas and upvote them for something so obvious to be added.
Category: Development
Came here to request ToolTips on fields in tables. Especially needed now due to CodeCop/Marketplace requirements.
Category: Development
XLIFF Transaltions BC system are a real pain!
What happens if you rename a field or page for example?
All references you have in all your XLIFF files must be reviewed and updated manually...
Why we must translate the same field caption we create in T36, T110, T112, T114 and so?
If the "origin" string is the same, the "translated" string must be the same and declared only once, not per object.
Why XLIFF use Language codes like "en-us" or "es-es" instead of "en" or "es"?
They are related to currency and date formats, not to string translations... in Spanish strings like "Cliente" (Customer) are exactly the same for Spain, Mexico, Argentina, Colombia, Ecuador and all South America countries... with 1 only XLIFF you should cover all these string translations for your customizations...
We are a Spanish end-customer with development license...
Why we can't use spanish like "original" Language for AL strings and decide to translate to others like english or german if we need some years later?
All strings in AL code asume the original Language is "en-us"!!!
Original Language for App strings should be declared in App json.
VSCode should alert developers when a string is not translated to any of the target Languages you declare in you App json of if XLIFF files are out of sync...
Category: Development
That could really help !
Category: Development
Update : I've found a pretty good way in managing the XLF files using the 'Xliff Sync' extension (https://marketplace.visualstudio.com/items?itemName=rvanbekkum.xliff-sync) in combination with POEdit.
If MS could at least prioritize the CodeCop rule part to detect missing caption, that would already help improving translation quality.
Category: Development
This is a really pain please look into this as suggested Frédéric Vercaemst
Category: Development
The xliff process works great for us, we have created tooling for the sync/tracking/reuse, so we don't have the need - except one point:
Tooltips on table fields with possible override on pages, exactly like captions. THAT would be a big help for developers and to ensure consistency.
Category: Development
You mentioned some important issues. Upvote from me :)
Category: Development
Business Central Team (administrator)
Thank you for your feedback. We are considering adding it to our longer term roadmap.