Problems with Smart Beetle display and NVDA when back translating

[munawarb]

I'm having an issue with translation from UEB when I type a colon (dots 2-5) and then a letter. I go into detail on the NVAccess issues page here: nvaccess/nvda#7678

[egli]

HI @munawarb, thanks for your report. Can you just summarize what the problem is, i.e. which liblouis table are you using, what is the input, expected output and actual output. From looking at nvaccess/nvda#7678 it appears that

• table: maybe en-ueb-g2.ctb
• input: dots 2-5, dot 5, dots 3-4-5
• output: "con)"
• expected output: "con"

Can you confirm?

[egli]

@munawarb also can you check if there is already a test for your problem in the YAML test

[munawarb]

Hi,

I don't know the programmatic name of the table...but in NVDA settings I have it set to UEB input.

I input as you described: dots 2-5 (colon), dot 5 (indicator), dots 3-4-5 (right parenthesis).

NVDA should output :) but it's outputting con) instead. As in, it's turning the dots 2-5 into "con".

I've also tried putting the dots 5-6 before the dots 2-5, but still I get con) and not :). I haven't tried using the colon anywhere else except for this one instance.

I hope this helps!

[egli]

I added a YAML test that confirms this problem. @munawarb can you look at the relevant table and provide a fix or contact the table authors and work with them?

Thanks

[munawarb]

Hi @egli , Thanks for the follow-up. I'll get in touch with NVAccess and let them know about it.

[egli]

@munawarb is there any news on this?

[munawarb]

I never heard anything back from NVAccess sadly.

[egli]

@munawarb thanks for the feedback, however I didn't mean you should contact NVAccess. I think they are waiting for us to do something :-). I was talking about working with the authors of the en-ueb-g2 table about this problem. Maybe a mail to the mailing list would help. I think you're not the first one to hit this problem.

[munawarb]

Hi @egli, Ok, thanks for the clarification and sorry for the misunderstanding. I'll get in touch as soon as I can.

[egli]

@munawarb Cool, thanks

[tibbsa]

I happened to stumble across this while looking for something else, and am adding these notes to the discussion for future reference. Perhaps the issue is with the UEB table, but perhaps there is something else going on.

:) will forward translate as 3"> (25-5-345), which is correct

The table specifies:

nofor begword con 25

The string "3">" in my estimation ought not to trigger this begword rule, because the character following the "3" is a punctuation character and not part of the word.

It would appear that the call to isEndWord() in lou_backTranslateString.c:back_SelectRule() for the CTO_BegWord opcode might not be correctly identifying the subsequent character as punctuation?

[munawarb]

I got a response recently from one of the authors of this table. It sounds like the fixes are in but need to be merged. His response is below:

Sorry for the long delay.

You can see my most up-todate work on UEB backward translation here: https://github.com/MikeGray-APH/LibLouisAPH

I don't know how long it will take for the changes here to be incorporated into LibLouis.

[bertfrees]

OK. We currently don't have any pending PR's from Mike for the UEB table, so I guess we can expect one sometime in the future.

[jrbowden]

@tibbsa is correct: the begword rule should not fire here. This seems very similar to the backtranslation problems in #892 for strings such as ⠏⠙⠐⠜ Expected: paid) actual: pd)

@bertfrees discovered the rule always ar 345 causes the problem, but the rule is correct.

Suspect there is a problem in the engine.

I do not really want to put a rule in the UEB table specifically for :) as there are lots of variations which also need fixing: :( :] :} ... etc.

[jrbowden]

I have made new issue #1606 which covers this issue.