[Feature suggestion] Auto-translate window: single file support with Google translate

[cyzs233]

Currently google translate api is limited for free users (~1000 lines per day?). It would be nicer if subtitleedit adds some support around Google Translate's documents translation option to bypass its api limitations.

• Export as a single document file.
• Import&parse translated file returned by google.

It's doable manually but takes a lot of steps. Hopefully, we could support it directly in this translate window.🤞

Documentation : Translate documents

[niksedk]

OK, tried to add some support for this - via Auto-translate via copy-paste - https://github.com/SubtitleEdit/subtitleedit/releases/download/3.6.6/SubtitleEditBeta.zip

How does this work?

[darnn]

For the record, at least when I tried this a few months ago, the translation of the uploaded document was different (and worse) than the one you would get just pasting the text into the website version a few lines at a time. Some lines were left in English altogether, for instance.

[cyzs233]

OK, tried to add some support for this - via Auto-translate via copy-paste - https://github.com/SubtitleEdit/subtitleedit/releases/download/3.6.6/SubtitleEditBeta.zip

How does this work?

Yeah, it works. But to be honest, it's kinda cumbersome to use this copy-paste translation window, it's generally not recommended to copy-paste translation back & forth between browsers. Thus we need to export the original subtitle to a single file. First, you have to max the "block size" to the maximum to reduce the process into a single copy-paste. Second, you have to remove any "line separator" since it will mess up the formatting of the translation result returned by google. (Period get translated into other punctuation)

Maybe we could add pdf support directly in the translate window I have mentioned? Cause that's all we wanted in the end and has been supported by all translation services. You will get instant translation results on google, which is significantly faster than API requests. IMO, the currently workflow (edit parameter ---> export to .txt ---> convert to .pdf/.docx ---> copy translation & paste into subtitleedit) needs a refactor. I don't think most users will get the feel of how to use this copy-paste feature.

@darnn Yes indeed, but it seems more like an "unknown word" (or names) related problem.

[niksedk]

OK, how should lines be separated?

Is ".rtf" supported? C# cannot write pdf/docx unless using some third party libraries... I just tested a pdf lib which added about 150 MB to SE... I found a docx library that was smaller.

It's harder to maintain code that uses external libs.

[cyzs233]

OK, how should lines be separated?

A simple new line will do in this case.

Is ".rtf" supported? C# cannot write pdf/docx unless using some third party libraries... I just tested a pdf lib which added about 150 MB to SE... I found a docx library that was smaller.

It's harder to maintain code that uses external libs.

.rtf is not supported by Google translate as far as I can tell.

Adding .docx support to SubtitleEdit would be great. Maybe half of the current text editing issues can be closed if you offer them an option to edit in Word instead. Some other cool things you can do with .docx are :

• More language support. Spelling check support on non-English subtitles. Even grammar check! Grammarly for Microsoft Word
• More text editing support

  6001, custom word list, coloring, etc.

• More happy translator You can now use SubtitleEdit to handle the transcription part(and rough timestamp), then maybe merge&export those transcription texts into logically separated segments(instead of translating line by line in subtitleedit). Hopefully, the translation result will be more context-aware & easier to compile into a working subtitle.
• More encouraging for plugin writer There are generally more cool things you can do with Word (compare to plain text or heavily structured subtitle formats).

Of course, developing difficulty is the first concern. Someone has to actually implement it😉

[niksedk]

It would only be .docx file reading/writing.

[cyzs233]

It would only be .docx file reading/writing.

Hmm, that doesn't sound motivating to implement .docx support at all. Guess we'll stick with plain text then.

Now that we have discussed the restriction of this copy-paste feature, maybe we could deprecate this feature and move its save&load functionality to the Auto translate window (if there is no other use than simply copy-paste)? Web browsers tend to add formating to the translation result in their web UI, in such cases, users shouldn't just assume the copy-pasted translation just magically works in Subtitleedit and have to paste & review the result locally first. (Line separator get translated into other punctuation for example)

[niksedk]

The "Translate via Copy paste" is extremely useful... and the line separator is customizable.

I've tried to add docx import/export in the "Translate menu"... let me know if it's useful or not: https://github.com/SubtitleEdit/subtitleedit/releases/download/3.6.6/SubtitleEditBeta.zip

[niksedk]

@cyzs233 : did you have a change to try the above beta?

[cyzs233]

@niksedk I'm having trouble upload this .docx on Google translate. it says "file corrupted". (maybe .docx version compatability problem?🤔 )

Demo


It works on Baidu online translate(upload), but the table structure got reformated. Currently, You can use Word's built-in translator instead, it will maintain the original table structure.

Reformated result


And then when I tried to open it using "Step 2 - import", an error was prompted.

import error


translation (returned by baidu).docx Actually, this import error will also occur even if the .docx is the file previously produced by "step 1 - Export" exported docx.docx

source .srt attached below: It Is Good to Live.1956.srt.zip

Update: why is this "Max block size feature" useful and some other experiments. #4910