Unique suggestion tag for translations from Copilot

[cegekaJG]

Is your feature request related to a problem? Please describe.
I am working on a Copilot prompt that makes managing translations as seamless as possible. I do like the workflow of having suggested translations be marked for review, and I've been using the MCP server to have Copilot translate novel text. However, when using the nab-al-tools-saveTranslatedTexts tool, the trans units of the updated translations will be immediately marked as reviewed. This can make it difficult to tell which fields were machine-translated, especially when reviewing using the editor.

Describe the solution you'd like
Ideally, I want the nab-al-tools-saveTranslatedTexts tool to allow for an additional tag property per translations element. It would let me specify that new translations should be saved with the tag [NAB: AI-SUG] or something similar, which would be an indicator for the editor that the unit needs to be reviewed.
Alternatively, all units updated by the tool could receive a label that indicates it has been altered by a chatbot.

Use case / User story
When using a chatbot to add new or update existing translations, I want the modified trans-units to be given a unique tag so I can find translations from AI easier.

[jwikman]

Hi @cegekaJG,

I think you should switch to use target states. XLIFF supports several different target states, and the saveTranslatedTexts (just removed the nab-al-tools- prefix in latest release) tool do currently support these target states:

• "needs-review-translation"
• "translated"
• "final"
• "signed-off"

These states can also be used to create a translation review workflow with Copilot. :)

Set "NAB.UseExternalTranslationTool": true and refresh your XLF file to get the target state in your XLF files.

What do you think about that approach? I rather not introduce any more custom NAB tags, if not really needed.

[jwikman]

We usually use the target state "translated" for AI translated texts.
Then we use "final" (or "signed-off", depending on language and different scenarios.) when a human has reviewed them.

[someC0d3r]

As someone who has already done a lot of translations using Copilot, I think it would be very helpful if translation units had a property indicating they were generated by AI. That way, it’s easier to identify them and review those translations more carefully - at least that’s how I see it.. :)

(this doesn’t mean that human-written translations shouldn’t also be reviewed just as thoroughly, but in my experience, AI translations do have a slightly higher chance of being incorrect or misleading - which makes a clear indicator especially useful :/)

[jwikman]

@someC0d3r, have you tried to work with target states as mentioned above?

[cegekaJG]

We usually use the target state "translated" for AI translated texts. Then we use "final" (or "signed-off", depending on language and different scenarios.) when a human has reviewed them.

Is there a way to change the settings so ticking the checkbox in the XLF editor changes the state to "final", and "translated" would leave it unchecked? Otherwise, I couldn't use the editor to confirm the translations.

[someC0d3r]

@someC0d3r, have you tried to work with target states as mentioned above?

Not yet tbh, I'm gonna give that a try! :)

[jwikman]

Is there a way to change the settings so ticking the checkbox in the XLF editor changes the state to "final", and "translated" would leave it unchecked? Otherwise, I couldn't use the editor to confirm the translations.

Currently no.
But if your Copilot saves the translations as needs-review-translation, you will get the translated state when ticking the box.
Could that be a way forward for you?

[cegekaJG]

We usually use the target state "translated" for AI translated texts.
Then we use "final" (or "signed-off", depending on language and different scenarios.) when a human has reviewed them.

If I wanted to follow your suggestion, the states of the trans-units would have to be different depending on where the target text comes from, and marking a unit as reviewed would have to set the state to "final".

To avoid talking around the use case, I'll redefine it.
For our purposes are five distinct sources a translation can come from:

1. Typed manually into the XLF file/editor
2. Retrieved from a comment using a locale tag (like ENU=)
3. Suggested from the glossary/dictionary or the base app translation
4. Copied from an identical caption
5. Translated by AI

For the sake of simplification, I can group 1 and 2 as well as 3 and 4 together, but I'd like to be able to identify where each target text comes from when reviewing translation. That way, I know how reliable it is. I don't care how this information is saved to each trans-unit, as long as I can check the box to indicate the translation has been reviewed and accepted.

[jwikman]

Maybe we could use state-qualifier for this in some way?
Today we only use the state-quailifier attribute in two cases (of course, only when you are working with target states):

1. exact-match - when the source matches a previous translation and the target value is copied. This could be from BaseApp, or the current xlf file (your 3 - 4)
2. rejected-inaccurate - when using the Xliff-editor and unticking the Complete checkbox

We might set it to leveraged-mt when translated by AI? 🤔 (Glossary is used by AI to help AI make better translations - the output will still be AI translations.)

I.e. you instruct Copilot to always set target state to needs-review-translation and we auto set the state-quailifier to leveraged-mt when saved through the LLM Tools (this might be enabled with a new setting). Both target state and state-qualifier is already written in the editor, if target state is something else than translated, signed-off and final (if I recall).

What do you think about that approach?

With Dictionary, you are referring to the old <language-code>.dts.json dictionary? I was planning to remove that, as well as all other DTS related functionality, since the DTS is retired...

[cegekaJG]

I think that would be a good start, yes. Is it possible to have Copilot save a translation with target state needs-review-translation already? From looking at the parameters in my previous logs, it only seems to provide a new translation text.

By the dictionary, I am referring any translations outside of the app's XLF files used to suggest new translations. The base application, for example. How does the extension retrieve the localization files of the base application, exactly?

[jwikman]

I think that would be a good start, yes. Is it possible to have Copilot save a translation with target state needs-review-translation already? From looking at the parameters in my previous logs, it only seems to provide a new translation text.

Yes, that is possible. You can find more info on each tool in https://github.com/jwikman/nab-al-tools/blob/main/extension/README.md

By the dictionary, I am referring any translations outside of the app's XLF files used to suggest new translations. The base application, for example. How does the extension retrieve the localization files of the base application, exactly?

We've generated json files from BaseApp xlf files and stores them in the cloud. Then we download them when needed and use that to find target by it's source. The files are updated yearly or so.

The json files contains one item per source, but can have multiple target if translated differently. When using [NAB] tags you can see that with multiple suggestions. But if you use target states, we just pick the first target (old reasons, and don't have a better approach yet).

We might want to rethink how this matching works, now when we got this LLM story... 🤔