Hello Ikrami,
I would say that the most important thing is to have good yaml tests before
you start modifying the tables.
For each grade, you should have a yaml file containing the following tests:
1. All characters defined by the table, both directly and indirectly.
2. All the main features of the table, e.g. contractions, computer
Braille vs. literary Braille, the more the better.
3. Special features and issues that you have encountered during the
development, e.g. problematic combinations of characters etc., the more the
better.
Remember to test in both directions if your table supports both directions.
If some features are meant to only work in one direction, test them in this
direction.
Even if you know that something is currently failing, make the relevant
tests and mark them with xfail: true. The more things you test this way the
better.
Also, for each grade, especially grade 2, you should have a dictionary test,
the bigger the better.
The ideal thing would of course be to only have known to be good Braille
translations in the dictionary test, but it is really more important to have
a base line to work from, no matter if the test actually contains some wrong
translations to start with. When you make changes to your table, you can
then see what problems you have solved, and also see if you have introduced
new problems, which is very likely when one changes the details of a grade 2
table.
You need to get a good corpus of words for your dictionary tests, again, the
bigger the better. One possibility is the Aspell dictionary for your
language. You could use the full dictionary for internal testing and make an
excerpt to go with the Liblouis package, e.g. every 10th word in the
original corpus.
It can be a challenge to make a yaml file from a text file containing many
thousand words. You dont want to enter the tests manually. I dont know how
others have solved this, but for my own part, I made a quick and dirty
Python script to make a yaml file from a text file and its current
translation with Liblouis. Other suggestions for this problem would be
welcome.
Like you, I have used the NVDA Unicode Braille input plug-in for entering
Braille in my test files, but lately, I have started using a quicker method.
There is another plug-in called PC Keyboard Braille input, which is used to
enter Braille through the keys on the home row of the PC keyboard. Use this
plug-in and switch the input Braille table in NVDA to Unicode, and you are
good to go.
For experimenting and testing while you are working as well as debugging any
problems, the lou_trace program is your friend. It works like the
lou_translate program, but tells you what rules have been applied during the
translation or back-translation. Use it whenever you think your table is
doing something it shouldnt be doing.
HTH Bue
Fra: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
<liblouis-liblouisxml-bounce@xxxxxxxxxxxxx> På vegne af
ikrami.ahmad@xxxxxxxxx
Sendt: 20. marts 2020 19:15
Til: liblouis-liblouisxml@xxxxxxxxxxxxx
Emne: [liblouis-liblouisxml] testing my changes on table
Hi friends
So I am about to resume working on improving the Arabic Braille tables in
Liblouise. I need to learn an effective way to test the changes I made to
the table. A clear step by step instructions will be appreciated.
I used to test my changes through replacing the table I modify in NVDA
screen reader and see how it reacts to my changes. However, I find out that
this method is not really adequate enough, due to some limitations in NVDA
itself. For example, the Arabic grade2 table functions properly in JAWS, but
with nvda, it gives me an unknown input error message when I try to type
in any character from my braille display.
I may rely on NVDA Unicode braille input to create my yaml tests, but I need
to learn how to actually see the modifications I made to the table itself in
terms of forward and backward translation.
Your help will be greatly appreciated.
