Apparently, the Travis build fails with the following message.
No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
163
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#build-times-out-because-no-output-was-received

What could be going wrong?
Nothing seems to fail locally.

@BueVest I just restarted that particular test and now all is green. Might have been a fluke

I think we should merge this PR now. It contains fully working back-translatable grade 0 and 1. Grade 2 will require some substantial development and a lot of work. So, I think it would be better to do that in another PR. Then we can start using g0 and g1 and gain some experience.

@BueVest OK, we'll see what we can do. It is a bit late that you tell this and there are a lot of changes to review. Tomorrow is release day.

Had a quick look. Here are some comments:

• What's with the temporary test file?
• Why do we need separate "bd" tables? Couldn't both forward and backward translations be defined in the same tables?
• You have created quite a lot of duplication with the "bd" tables. Even if there is a need to have two sets of tables, could something be done about the duplication?
• Why do we need the "bd" tests?
• Changes were made to de-chardefs6.cti, but this was not reflected in the tests.
• I saw a TODO ("modify copyright message...")

Some aspects of the Braille created by the original (non-BD) tables are less suited for back-translation, e.g. the lack of capital letters, the unconditional removal of some spaces, the use of the not so detailed accented letters etc.

Yes, I assumed it was like the Danish tables, but still: couldn't they be combined in the same table? Or would that be too confusing?

We could move the lines that can be shared into new files, which are then shared between the forward/literary tables and the bidirectional ones. However, if this change was to be made, I would rather make it in collaboration with the original table author, and not by myself. Currently, the chardefs file is shared, because I could make the necessary changes without affecting forward translation in the original tables.

OK. I think it would be good to do this refactoring right from the start. This also gives us the opportunity to get some feedback from the original table author.

The BD tests test the bidirectional tables in both directions. The other tests test the original tables, and only in the forward direction. The files could in theory be merged, but since they test two separate sets of tables, I think they should be separate yaml files.

I think it might be easier to follow if the tests were grouped into the things that work the same in both versions of the tables and the things were the tables differ.

The changes [to de-chardefs6.cti] are primarily to the order of character definitions to ensure correct back-translation. They should not affect forward translation.

Hmm, are you sure? I thought I saw some actual differences?

If there are any big problems with merging now, we can do it later. I just thought it would be a good idea to gain some broader user experience with the tables now.

Yes, it sure is nice to get user feedback as soon as possible, however we shouldn't use time pressure as an excuse to do things in a sloppy way. If you would have done the PR a week ago I'm sure we would have been able to fix all the issues. I do trust you that you would fix the issues afterwards if we would merge the PR now, but still...

Perhaps we should flag it as an error to use a forward table for back-translation? Just thinking…

This is something that needs to be handled on the NVDA side ideally. Adding these kind of metadata based limitations into the library itself only works if you can select tables only through metadata, but this is not the case at the moment.

What needs to be done here?

Concerning Bert's suggestions above:

1. We could refactor, so that the "core" files contain all the common stuff, and the main tables contain the stuff specific to the individual tables. However, that would be some change to the original file structure, and I would rather not do that without the approval of the owner of the original tables. Is that you, @egli ?

2. Refactoring the yaml tests: @bertfrees , you apparently wanted to have the tests in fewer files and grouped to show the same things for the different tables. What is that supposed to look like? As far as I remember, we can run the same tests for multiple tables, but not with different flags for each table, e.g. forward for one table and both directions for another table, unless that has been changed in the code.

Any suggestions are welcome.

@BueVest What happened in Git? There are two seemingly identical branches that got merged. Now the diff in Github has become unreadable. I cleaned it up locally and also rebased onto master. If you want I can push it.

You apparently wanted to have the tests in fewer files and grouped to show the same things for the different tables.

Yes. Well, it was just a suggestion. I think it might help in understanding how the tables differ. But I don't know how feasible it actually is. It depends on how much and what kind of differences there are. And you will indeed have to run the common tests in both directions for both tables.

Which brings us to one my others questions: Do you really need the two tables? Couldn't the backward behavior of your "bidi" table be combined with the forward behavior of the original table? Is the forward part of the "bidi" table really important to have? It's just a naive question. Maybe the tables are so different that they are not compatible at all? I don't know. I need to understand better how exactly the tables differ.

Let's assume for a moment the answer to the above question is yes (we do really need both directions of the new table). Couldn't the backward behaviors of the main and "bidi" tables be aligned? Some back-translation is always better than a back-translation that is not working at all, right?

I think first and foremost we need a summary of things where the two tables differ.

So what about the second part of my question: Could the backward behavior of the main table be the same as that from the bidi table?

Maybe I just don't know enough details, but from my vague understanding of it it sounds like both variants of the braille are not incompatible. One just contains more information than the other (like information of capitals) that make the back-translation better.

If you want to do a Skype call to discuss this PR, that is fine for me. However I think we need some written explanation of the table anyway. It's interesting for me, but I'm not the only person who needs to know. It's also and primarily the original author of the table (Christian's colleague), and other German braille people, that need to understand.

Regarding the tests, I gave it another thought: for dictionary tests it doesn't matter that there are a lot of files with possibly duplication. They are not meant as documentation. But it would be nice to have a YAML file that explains the differences between the main German braille code and the variant optimized for back-translation.

I could describe the differences in forward translation between the two table sets within the bd tables themselves, provided that back-translation is simply not defined for the original tables.

Yes! That's exactly what I'm after.

[...] describing the whole philosophy of why you would want two sets of tables? [...] If I am to describe it, I need to understand what it is that is so difficult to understand about it, so to speak.

It is not so difficult to understand at all. I'm just asking a lot of questions (sometimes deliberately naive) to make sure that we are doing it the best possible way. For example I think whether we should try to handle both variants of the braille code within the main table (or both tables) when back-translating is a valid question. If it is indeed doable it would be a major improvement. You wouldn't need to figure out which table to select, you can just pick one and it would work.

Anyway, I'm not asking you to describe the whole philosophy of the two sets of table. I think it would indeed be a valuable addition, and useful for developing other tables, but for now all I'm asking for is a proper description of the behavior.

By the way can I push the cleaned up branch that I have locally or not? I want to be able to look at the combined diff on Github, that is currently not possible.