[bksvol-discuss] Re: BRF
- From: talmage@xxxxxxxxxx
- To: bksvol-discuss@xxxxxxxxxxxxx
- Date: Thu, 16 Dec 2004 13:26:13 -0500
Hi Tony,
As a non, or at least a very reluctant, braille user, I find the concept of
a dysfunctional back translator interesting. Given the examples that you
and Shelley have set forth, I can't understand why a back translator
wouldn't, or couldn't, be as efficient as the original translator. Is
there some sort of contextual issue involved?
Dave
At 11:58 AM 12/16/2004, you wrote:
Hi Shelley. Sorry, but I have to disagree with your reasoning behind why
Braille does not back-translate well. The way we get around the limited
number of symbols is with computer Braille. Even in litrary novels, .brf
files are really formatted computer Braille files. That's why the number
4 is used in place of period, for example. In the case of dots 4-6
followed by T, this would be represented in computer Braille as _T. Look
at any NLS .brf file for a good example of this. If you have a
translation program, try writing random text and translating it.
The reason why back-translating doesn't work well is laziness of
programmers or sloppy translation tables. If you look at a demo of
Duxbury, you will get almost perfect translation. I tried it and was very
impressed with the results. It inserts the letter "d" randomly though
because it is a demo. If you look at NFBTrans and the version history,
you will see that the last several versions have specifically been to fix
errors in the back-translation tables. I am not faulting the author of
NFBTrans since it is a volunteer effort. I use it myself
frequently. Duxbury costs a fortune while NFBTrans is free. I am saying
that that's the reason why computers make translation mistakes. The other
problem, as I said previously, is that so much formatting is thrown
away. It is impossible to put back page and line breaks once they have
been removed. A reasonable guess can be made but it isn't reliable.
Other related posts:
