And also thank you Jennifer for the detailed feedback. Welcome to the list!
2017-10-10 23:59 GMT+02:00 Bert Frees <bertfrees@xxxxxxxxx>:
Thanks Bue.
2017-10-09 10:54 GMT+02:00 Bue Vester-Andersen <bue@xxxxxxxxxxxxxxxxxx>:
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.
