Thanks Bue for your very thoughtful reply to my post. Please understand
that I am not trying to be negative. It's only that because my own
experience was that backtranslation turned out to be much harder than I
expected, I'd like to prevent someone else from becoming overly frustrated
if they have the same experience.
First let me respond to your comments about formatting. I agree that for
documents sourced in braille the available formatting choices are probably
sufficient. I also agree that in general we can't expect to recover print
formatting although it may be possible to identify the semantics of the
formatting, e.g. headers and paragraphs, in a braille file that follows
official formatting rules.
However, I should point out that there can sometimes be semantic
implications to formatting, especially planar formatting, that can't be
ignored.. For example, it can be necessary to examine the layout carefully
in order to accurately backtranslate arithmetic and other items in Nemeth
math.
You also pointed out that while it is necessary for back translation to be
consistent with the print source, that agreement in itself isn't sufficent
to guarantee that the forward translation has followed all of the braille
rules. An obvious example is braille that spells out words that should have
been contracted. The only way to use this approach to ensure correctness as
well as consistency would be to have independent well-tested back
translation software and retranslate the backtranslated document with the
latter.
Of course, as you mentioned, a lack of agreement could be due to errors in
the back translation. At least for the U.S. braille systems with which I am
familiar, it is possible to develop both print and braille documents which
can be used as "torture tests" to demonstrate that the software is correct.
In my experience the best way to develop these documents is to add to them
each time a previously undiscovered error is found and fixed. (By the way, I
do understand that when one fixes an error in a translation table for
contracted braille it is possible to introduce a new error. You can see
what I've written about that here:
http://www.dotlessbraille.org/bidissues2.htm#rulescon and also what was
written about this issue back in 1980.
http://www.dotlessbraille.org/bidissues2.htm#note1 )
I started my braille software experience writing a Java print-to-braille
translator for EBAE using the standard translation table approach used in
DBT and liblouis. I began by using the brltty tanslation table that John
Boyer kindly gave me. However, since my main interest was in
backtranslation, most especially backtranslation of math, I soon started
developing a backtranslator. (Meanwhile my collaborator, who unfortunately
died unexpectedly in 2009, was working on forward translation.) It took
several failures until my collaborator suggested that I use parsing
technology so I end up using grammars I wrote in ANTLR.
I thought I had pretty much finished my EBAE back translation software when
a braille reader challenged me to back translate the brf version of the EBAE
manual. (That can be downloaded here:
http://www.brailleauthority.org/literary/literary.html ) Boy was I in for a
big shock when I discovered all the ambiguities, rules I hadn't known about,
and other problems. One big issue is that that there are EBAE translation
rules that depend on semantics such as those for the different types of
hyphenated items. Another was determining the scope of indicators in
formatted braille documents where in some cases the scope continues to the
next line while in others it does not. It's been a number of years since I
worked on this but my memory is that I spent an extra year to address all
these new-to-me situations.
I agree with you that not using capital letters is definitely going too far;
I certainly wouldn't have invested so much time in braille if I didn't think
braille users are just as competent as we (non-users) are. (smile) I was
just
trying to give an example to illustrate that depending on its purpose a back
translator that can handle only a subset of rules might be useful in some
situations. A better example might be not always adhering to UEB phrase
capitalization in a text message.
The main reason I spent so much time trying to implement backtranslation is
because I believe that accurate automated backtranslation is very important
in educational settings. When sighted persons who know braille manually
backtranslate student work for a classroom teacher, it is hard for them to
avoid inadvertently correcting student errors which really ends up hurting
the student. On the other hand, if the student uses an automated process
that doesn't produce accurate print, a classroom teacher can get in the bad
habit of blaming the software instead of realizing when the student has made
a mistake. This is especially important for younger students who haven't
developed alternatives to direct entry of braille. Of course, when
backtranslating student work, it is important to be able to handle errors
that could cause the software to crash.
A related problem is that it appears to me that some braille users,
especially those studying science and math, spend more time trying to come
up with ways to produce print than they do learning subject matter. So I
certainly hope for success in developing accurate backtranslators.
Sincerely,
SusanJ
For a description of the software, to download it and links to
project pages go to http://liblouis.org
