I m trying to help with this task. here is a proposal
UI: mockup:

1. machine translation is optional with a tick box, must be actioned by user
2. if machine translation is selected, for each segments, propose a suggestion (API call)

3.user must intentionally accept translation before submitting

Code
For a technical perspective, going through the repo and the Mint service:

1. Add an MT suggestions backend endpoint in svgtranslate that accepts POST requests from the tool (source language, target language, an array of segments)
2. Authentication: Use the existing svgtranslate session (Toolforge or Wikimedia login) to gate the MT request; reject anonymous requests
3. Wait for an answer and parse into segments back into the UI

hope it makes sense
please comment. thanks!

Would be good to have it remember if "Suggestion machine translation" was selected between an individuals users sessions.

James

When checking the "Suggest machine translation" would the text fields then get filled with the suggestions? (As a side note, it'd be good to show some visible loading state at that point.) Once the suggestions are in the text fields, what is the difference between "Accept Suggestions" and "Submit"? Or does it mean that the suggestions will be shown e.g. below each field, and the accept button will move them into the fields?

Note also that some fields may already have values, in which case the suggestions should ignore those fields (i.e. not send them for translation, and not fill them with anything, as we assume any existing value has been checked and approved by a human).

The way Translatewiki.net does it is to show the machine translations near the text field, and they can be copied in by clicking them:

1. checking the "Suggest machine translation": Yes, text field will be filled with machine translation. Will add a spinner / visible loading state when this happens.
2. difference between "Accept Suggestions" and "Submit": i want to make sure the acceptance of machine translation is intentional to ensure the quality. I can remove the "accept suggestions" button and add a warning text box instead.
3. I am not sure i understand the use case when a manual translation would already be in the box: is it if a user starts translating manually then ticks the 'suggest machine translation' ?

in any case, i propose to
3.a add the machine translation only when the text box is empty (no previous manual addition)
3.b change the background of machine translated box to light green to clearly indicate the boxes which are suggestions from the service
attaching a new mockup

4. remember if "Suggestion machine translation" was selected between an individuals users sessions.

I am not sure it makes sense, because the case for machine translation will vary based on the language, and also the type of sentences translated (for instance, specific semantic such as medical language is harder to translate than plain conversational english)
in any case i can add this feature in a future version

5. i do not have my dev account yet, i ll submit a ticket to get it validated.

difference between "Accept Suggestions" and "Submit": i want to make sure the acceptance of machine translation is intentional to ensure the quality. I can remove the "accept suggestions" button and add a warning text box instead.

The warning message you have there sounds good. It does sound like a user would need to click first the 'Accept suggestions' button and then the 'Submit' one.

Also, note that there are currently no buttons at all at the bottom of the form! The warning should I think go up at the top. The button for uploading to Commons is the one at top right, labelled 'Upload to Commons'.

I am not sure i understand the use case when a manual translation would already be in the box: is it if a user starts translating manually then ticks the 'suggest machine translation' ?

Someone might've started translating an image, and done some of the labels, and then uploaded the file. This would leave some labels blank in that language, so the next time someone loads that file, there would be some already done and some left to do.

3.a add the machine translation only when the text box is empty (no previous manual addition)

Perfect.

3.b change the background of machine translated box to light green to clearly indicate the boxes which are suggestions from the service

Great idea. Do note however that we shouldn't rely solely on color to convey state, so perhaps a note under the input box could be good as well. Although that would make the whole form a lot taller so perhaps not! Bold the field's label maybe? And at the top have a message that says something about "Please check the highlighted labels" or something? I'm not sure.

remember if "Suggestion machine translation" was selected between an individuals users sessions.

That might be useful, but I agree that for the first iteration it's probably not worth worrying about. Rather than a checkbox, I think make it a button, and users then click it when they want to fetch the machine translations. This would also reduce spurious requests for machine translations and so make the it all feel a bit faster.

Here is what it could look like with all comments taken into account:

That sounds great!

merge request (draft)
Priority:
implementing api call to cxserver to get translated field

Secondary implementation:

• remember user preference on translation
• add loading state

[done]

• color code translated field
• display warning messages to confirm to translations

Linting errors cleared. now the test pipeline succeeded
i have changed the eslint config to allow for 'promise' to retrieve data from the api call asynchronously.
if another implementation is preferred let me know.

Working on the Source Language Widget:
the current setup implies a a logic issue: the source language is defaulted to the browser language.
For manual translation, it has no importance since the translator will identify both source and target language and translate accordingly.
however for machine translation, both need to be correct.

If the source language detected is not the same as the language of the file, the machine translation will not work.

source uses a dropdown+fallback helper while target uses a ULS button

Proposing to change the behavior to allow the source language widget to be changed to a selector in all cases for the users to rectify any detection which proved incorrect
i.e. make source and target the same (ULS button)

Please comment @Samwilson

99.9% of the time source language for out efforts will be English but it
would be good to be able to change it

J

Sent from Gmail Mobile

In T206436#11741644, @Doc_James wrote:

99.9% of the time source language for out efforts will be English but it
would be good to be able to change it

J

Sent from Gmail Mobile

is this comment related to OWID only are all SVGs? I am asking because the random SVG i have tested on are not in english.

1. if OWID only, then i need to continue because the SVG translator tool is general
2. if it is all SVG, then i can deprioritize this feature, the current developer version is ready for validation

Here is an example of SVG file in russian. The source language detected will be 'fallback' as my browser is set to English. English is the only other option in current state
{F73568767}

{F73568766}

Here is an example output in current state. Machine translation from EN to SP and EN to FR. As you can see, it requires manual correction from some fields, but 90%+ is accurate and returned with low latency (within 1 second)

I think adding a selector for the default language makes sense, but it's also a complication. We don't really have a means of storing what a SVG's default language is (I guess the lang attribute is the normal way to do that), and adding that is going to be a separate task and take some time.

As a first step, I think it would be simplest to use the the UI language (i.e. the browser's language, but users can change it via the selector at the top). Then, if it doesn't match an SVG's default langauge I assume people will be presented with weird translations (or perhaps nothing), when the MinT checkbox is enabled? Which is probably fine as a first iteration of this. The UI language is already readily available to send to MinT.

If not having the source lang selector turns out to be annoying, the above patch would still be a step in the right direction.

Most of the time peoples default language will be the one they are translating into, rather than the one they are translating from. For the OWID SVG effort the starting language is going to be generally EN. But for SVGs overall there could be various languages as the starting language.

Oh yes! Sorry, for some reason I've been thinking about this wrong! :(

So without a selector for the default language there's no way to know.

It would be good to have the starting language selector limited to just the
languages the SVG is currently in.

J

I think the default language would be anything other than the set of languages that a file has already been translated to, wouldn't it?

As a first iteration, perhaps it's best to only allow MinT translation if a source language has been selected (i.e. not enable it for the default language).

I have added these two functionalities to the the merge request:
[done]

• color code translated field
• display warning messages to confirm to translations

samwilson updated https://gitlab.wikimedia.org/toolforge-repos/svgtranslate/-/merge_requests/6

dev- machine translation

samwilson opened https://gitlab.wikimedia.org/toolforge-repos/svgtranslate/-/merge_requests/10

Fix up MINT_URL env config variable

samwilson merged https://gitlab.wikimedia.org/toolforge-repos/svgtranslate/-/merge_requests/10

Fix up MINT_URL env config variable

I've tagged version 2.1.0 and deployed it. Thanks for all your work on this @Booksmurf! It's great.

A few things I've noticed when using it:

• It shouldn't allow translating to the same language that's selected as the source language (including when source is 'default' and it defaults to en).
• I wonder if the checkbox should actually be a button. It's operating more like a button as it is, in that it's clicked in order to get the machine translations. Or is the idea that it is sticky, and stays selected if you change target langauges? That might be likely to trigger translation requests that aren't wanted (and I think we're meant to be being careful not to send excessive requests to that API).
• Should the checkbox and "Please check…" message be moved to be above the two translation columns? i.e. below the source and target select widgets. They're not really related to the download/upload button area.

Amazing work. Agree with Sam's few small suggestions. Overall this is great though and will help us get OWID content into other languages.

My wife tested the initial machine translation workflow into Japanese and she found it very useful.

Great to hear. Thank you both for your support.
Do i need to close this task or will it be done automatically after next status 'patch for review' is completed?
I opened a new one with the changes suggested by Sam: https://phabricator.wikimedia.org/T425082
For the button vs checkbox, the original discussion was about having a 'sticky' behavior.
Indeed frequency of translation is low and just one additional click.

We want it too keep machine translation on if the user goes to a new svg
but turn off if they change languages

J

Sent from Gmail Mobile

In T206436#11878947, @Doc_James wrote:

We want it too keep machine translation on if the user goes to a new svg
but turn off if they change languages

J

Sent from Gmail Mobile

In this case, the 'Button' suggestion is not a good option.
I will stick with the tickbox and implement conditional behavior

Sounds good

J

Sent from Gmail Mobile