Hi listers,
I would like to comment specifically on two back-translation issues:
Jennifer writes:
Back translation: when alphabetic wordsigns or strong wordsigns are
brailled followed by the apostrophe with the letters d, ll, re, s, t, or ve,
they are unexpectedly back translating to print as the single letters rather
than the alphabetic words. For example, "you'd" is coming out as "y'd";
"this'll" is coming out "th'll". See UEB §10.1.2 and 10.2.2. These are
working correctly in Liblouis print-to-braille translation.
This seems to be a general issue, not specific to the UEB tables. I have
noticed a similar issue in Danish back-translation. Apparently, Liblouis has
difficulties deciding if a punctuation or sign constitutes a word
boundary and enables the use of a word contraction when back-translating.
The matter is a little complicated, because in many languages, punctuation
signs are used as midword contractions, e.g. dots 256 or dots 25. Perhaps,
the rules should be as follows:
1. If the sign in question constitutes a midword contraction, then that
contraction is used, and the word is continued.
2. If the sign does not constitute a midword contraction, then the
basic meaning of the sign is used, and a word boundary is enforced.
This may require some look-ahead.
Jenifer writes:
Back translation: When typing a number followed by a nonalphabetic symbol
(plus, minus [u+2212], multiplication, division, greater-than, less-than, or
equals sign), followed by any of the letters a-j, the letter is back
translating as a digit. For example, 2+c when typed correctly in braille is
unexpectedly back translating as 2+3. The problem is not limited to these
operation signs, but these are the cases in which the concern arises most
prominently. Most nonalphabetic symbols terminate numeric mode so that if a
numeric indicator is not used after them, the following characters should be
translating as letters (with no intervening grade 1 indicator needed). See
UEB §6.3.1. This is working correctly in translation from print to braille,
just not in braille-to-print.
Again, this seems to be a general issue. If a punctuation, math or sign does
not constitute a number boundary, it should probably be defined using the
midnum opcode. All other none-numerical signs should probably constitute a
number boundary during back-translation.
I will try to define tests for these two issues.
Bue
Fra: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] På vegne af Jennifer
Dunnam
Sendt: 9. oktober 2017 00:07
Til: liblouis-liblouisxml@xxxxxxxxxxxxx
Emne: [liblouis-liblouisxml] Some Translation/Back Translation Issues
Good afternoon,
It has been wonderful to see all of the improvements in the way UEB is
handled in Liblouis. Kudos to all who have worked on this so that braille
users can read and write with accuracy!
Following are some more issues I have encountered when using several
software packages that utilize Liblouis for braille translation. Please let
me know if anything needs clarification.
The Em-dash (U+2014) is displaying incorrectly. This is a
frequently-occurring character used in most cases where a "dash" is
intended. In the UEB symbols list (Appendix 3, page 314), this specific
Unicode character is called "dash" and is specifically defined in braille as
dots 6, 36. Liblouis is displaying it as dots 5, 6, 36. The three cell
symbol dots 5, 6, 36 is specifically linked in appendix 3 of the rulebook
(page 308) to the "long dash" (horizontal bar) U+2015. Liblouis is
displaying u+2015 correctly.
The "dis" groupsign is incorrectly being used in the words "disc" and
"dish". I believe this has already been reported, but let me know if more
info would be helpful.
The word "in" is incorrectly displaying using the "in" lower wordsign when
followed by a semicolon or colon. See the lower sign rule (§10.5.4).
Liblouis is handling this word correctly when it is followed by a period,
comma, exclamation point, or question mark or when surrounded by quotation
marks.
The word "Bethesda" is incorrectly displaying without use of the "be"
groupsign. The UEB rulebook (§10.6.1) states that the "be" groupsign is used
when the letters "be" form the first syllable of the word, as "be" does in
Bethesda according to dictionaries.
The word "Doubleday" is incorrectly displaying using and "ed" groupsign
instead of the "day" final-letter contraction. A contraction should not
bridge the words which make up an unhyphenated compound word (this includes
proper names as shown in the examples in the rulebook). See §10.11.1.
Back translation: when alphabetic wordsigns or strong wordsigns are
brailled followed by the apostrophe with the letters d, ll, re, s, t, or ve,
they are unexpectedly back translating to print as the single letters rather
than the alphabetic words. For example, "you'd" is coming out as "y'd";
"this'll" is coming out "th'll". See UEB §10.1.2 and 10.2.2. These are
working correctly in Liblouis print-to-braille translation.
Back translation: When brailling the shortforms for "first" and "quick",
an "apostrophe s" is unexpectedly being added to the back translated word.
The other shortforms seem to be working correctly.
Back translation: When typing a number followed by a nonalphabetic symbol
(plus, minus [u+2212], multiplication, division, greater-than, less-than, or
equals sign), followed by any of the letters a-j, the letter is back
translating as a digit. For example, 2+c when typed correctly in braille is
unexpectedly back translating as 2+3. The problem is not limited to these
operation signs, but these are the cases in which the concern arises most
prominently. Most nonalphabetic symbols terminate numeric mode so that if a
numeric indicator is not used after them, the following characters should be
translating as letters (with no intervening grade 1 indicator needed). See
UEB §6.3.1. This is working correctly in translation from print to braille,
just not in braille-to-print.
Thank you for considering these.
