Re: Emacs as a translator's tool

[Eric Abrahamsen]

Marcin Borkowski <mbork@mbork.pl> writes:

> On 2020-09-17, at 17:16, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
>
>> Okay, I've finally implemented this, and pushed a version 0 of a package
>> called org-translate to ELPA. You can see the code here:
>
> Hi Eric,
>
> so, after more than a year, I decided to finally take a look.  (Well,
> the main reason I started this thread was that I was translating
> a relatively short paper, which was done pretty quickly, so I didn't
> have much motivation to dive into this...  Sorry!)  I only read the
> readme for now, but it looks interesting.
>
> It turned out that I'm now in the middle (sort-of) of another
> translation project, much bigger this time.  (It started over a year ago
> and I estimate that it's going to take me at least half a year, maybe
> more if the scope increases, which is pretty likely.)  The trouble is,
> your package won't help me /at all/, since it is tied to Org-mode.  My
> project involves translating subtitles in .srt format.  (I blogged about
> it twice:
> http://mbork.pl/2020-10-26_Scrolling_all_windows_simultaneously
> http://mbork.pl/2021-05-30_Extending_subed-mode; I also blogged about my
> previous similar project:
> http://mbork.pl/2020-10-12_Editing_subtitles_in_Emacs_with_subed)
>
> Of course, when translating subtitles, segmentation is basically taken
> care of already (even if I sometimes need to change it a bit).  On the
> other hand, being able to view the relevant place in the source in
> a separate window, while not strictly necessary, could be helpful.
> Also, a glossary would be nice, too.  Is there any chance of separating
> org-translate from Org itself?  (It could be useful for other cases,
> too, like translating papers in LaTeX - which I also did a few times in
> the past.)

Thanks for continuing this thread, and for the feedback!

To be honest, I'm still very ambivalent about this package. Along with
some other code I've written (org-annotate and Gnorb) I feel like
there's potentially something useful in there, but I haven't quite got
it right. Mostly because I don't have a 100% clear concept of what
features are really needed.

I use org-translate, and find the glossary stuff useful, but there's
still something wrong about it. I'd always intended to decouple it from
Org, but I wouldn't want to do that coding work until I figured out
exactly what is wrong, and had a clearer sense of the features I want. A
"hard" glossary is important (where there's a rigid one-to-one
correspondence between language terms), and a "soft" glossary (where
there's a more general linkage), and I feel like org-translate does that
okay. But I also want to just leave certain phrases and words in the
original in my translation, and somehow mark them as "come back to this
later". And I want to put in multiple versions or drafts of a particular
word/phrase/sentence/paragraph, and be able to cycle through them. I
don't know how any of that stuff should look yet.

But yes, as it currently stands org-translate is far too rigid in its
requirement of Org, and its particular source/target setup. For my
current translation project I was given a PDF, not a text file (curse
them!!!), so I can't use org-translate at all. The whole thing needs to
be reconsidered.

Eric