From: Mari Voipio <mari.voipio@iki.fi>
To: mailing list for ConTeXt users <ntg-context@ntg.nl>
Subject: Re: Design for Translation
Date: Thu, 12 Mar 2009 12:18:03 +0200 [thread overview]
Message-ID: <49B8E15B.4010609@iki.fi> (raw)
In-Reply-To: <873adjf6cm.fsf@cordelia.devereux.me.uk>
John Devereux wrote:
>> First thing to remember is that I started the ConTeXt project many
>> years (5???) ago and the program *and* its documentation have evolved
>> a lot since then.
>
> Is there anything in particular new that you think might help?
Compared with the situation a few years back, WinConTeXt MkIV is a
breeze to install and update. And it works without fiddling, no font
installation, no funny coding in the format file, nothing. Even the
Cyrillic version worked when I just got the file encoding correct.
Even if they'll never compile the file, installing WinConTeXt is
probably the easiest way to get SciTe with correct syntax highlighting.
Except that you need to set UTF8 as default by yourself and not all
users can get that far; the more patient ones will, though, if
instructions are clear (go to menu x, click on y, write or copy to the
file exactly the following line, save, close SciTe, reopen.)
Daydreaming towards off-topic direction:
This would actually be really handy for people who need to edit .tex but
never compile: a download-and-click-to-install SciTecumConTeXt package
that had .tex defaulted to ConTeXt and had appropriate highlighting, but
nothing else. Encoding could probably also be defaulted to UTF8 at this
point or the installation could ask whether encoding is Windows standard
or UTF and then put the default in as needed.
If such a package existed, I could just dump the installation package
and the files to be edited on a USB stick or CD and (snail)mail the
whole thing to the person doing the translation. Most Windows users can
handle the installation bit, if it is like installing for example Adobe
Acrobat Reader.
I.e. I'm looking for something like the Notepad related free/shareware
html editors that highlight but don't have much brain otherwise - while
I use SciTe for my html work, my colleague has been happy with
Notepad-something-or-other (and that finally rescued me and our code
from the clutches of FrontPage).
> 2 out of 7 is not what I was hoping for... I assume these were your
> agents or similar (rather than "professional" translators)? If so that
> is how we were hoping to do it too.
Correct. One of those two has some background in programming, so he even
managed the first chapter with Notepad (or something similar), also he
whined that it was difficult without highlighting. The other one was an
elderly consultant who may have dealt with computers in the time when
text editing/layouting still involved similar coding. Or then he was
just used to taking on any job that falls his way, at least he managed
beautifully.
All or most of the others are marketing people who take one look at the
editing instructions and give up. This happened even in-house where I
would have been easy to reach for any help and even offered to install
the system on his computer. No hope (I was reasonably annoyed with this
one, cutting-and-pasting that language took me like three weeks...).
The funniest (but sad) thing is that after they give up on .tex, I also
offer to convert the graphics into formats that will be easy to insert
into Word if they want to do a translation of their own, but they've
*never* taken me up on that offer yet. Instead they apparently just cut
and paste the graphics from our official pdf and the result is usually
not as good quality as it would have been with the stuff I send. The one
I'm now working on is pretty .... sad. Although not as sad as the 20 meg
version I received a year earlier that had tracking on, too (thankfully
Word2007 now has an easy cleaning function with which I got rid of the
10 megs of revisions).
> I was going to try saving the
> tex original as .doc - word seems to open it OK - and then saving
> *their* end product as "encoded text/UTF8". Has anyone tried this?
I think I tried this with the Russian test file and it worked, but I can
retry (I've got Word 2003). The very important bit is to choose "encoded
text" as save format - it allows you to do plain text + UTF8, but the
file just isn't saved as UTF8 (confusing or what????). Been there, done
that....
Also, the tip I got here for a character converter, charsc, was pretty
good. Can't quite figure out the command line version, but I can get it
to work if I know the original encoding (it couldn't guess at
Windows-Cyrillic, IsoLatin1 went better). It is downloadable at
<http://www.kalytta.com/tools.php>.
Also, a caveat about Word. As my editing instructions say, you really
have to have all AutoXxx features turned off or your tex code can get
pretty fishy. In the worst case the autocorrect features do things to
your parentheses and even in the best case you get to fight with things
like ... turning into real ellipsis and possibly getting mussed up later
in conversion. If you can talk your translators into using WordPad
instead (if they are not up to trying SciTe), it will make your life
easier in the long run. *you* can still open the resulting .rtf file in
Word and convert it into UTF8 as long as your Word has been tamed.
Also, when you try to compile the translated file, expect to get stuck
at any % or & that are in the running text. They never remember to put
that backslash in front of these...
> I was going to have a single environment file, which the translators
> never see, then a *single* document file. But perhaps separate
> chapters would be better... My document is not so big, maybe 30 pages
> of text (plenty of screen captures too). So perhaps my document is
> like one of your chapters. But there could be several other documents
> in the pipeline, so am trying to come up with a workable approach.
We have another, 30 page manual, that was done after the big one (which
wasn't quite so big then, we started with three models...), but it has
the same type of division. I just find it much easier to find the stuff
to be fixed when the file lenght is limited. And the graphics take space
in the code, too, sometimes almost as much as on the page in reality (if
they are smallish).
Besides, when I check the files in before leaving work, the names of the
files jog my memory about what changes I made and thus the version
control log becomes more accurate. (Instead of just changing manual.tex
I change intro.tex and sensorspecs.tex and ethernet.tex and all of these
get flagged when checking files back in.) And in case of gigantic messup
I can just revert the file for that chapter and lose those changes, but
everything else I did the same day is safe. Been there, done that
too.... The longer the individual file is, the more you have to lose if
things go wrong.
> I think I can do everything with one environment file and some
> modes. I also have a similarly functioning layout in mind to avoid
> duplication of common images, with fallbacks and so forth.
If I started now, I'd use modes, too. I once tried, but didn't
understand enough to really get it to work and then the manual was
already pretty big. I'll probably try again with the newer and much
smaller manual at some point (when I have a bit of time to study, but
before somebody wants to translate it into any other language).
Sharing the misery,
Mari
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : https://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___________________________________________________________________________________
prev parent reply other threads:[~2009-03-12 10:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-11 19:44 John Devereux
2009-03-11 21:39 ` Mari Voipio
2009-03-12 5:04 ` Marcin Borkowski
2009-03-12 8:22 ` Mari Voipio
2009-03-12 9:17 ` John Devereux
2009-03-12 10:18 ` Mari Voipio [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49B8E15B.4010609@iki.fi \
--to=mari.voipio@iki.fi \
--cc=ntg-context@ntg.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).