Adds new German braille tables#11268
Conversation
|
@Futyn-Maker I changed the label for "uk.utb" from "Ukrainian" to "Ukrainian Grade 1". Is it OK for you? |
|
@Andre9642 Yes, I think it's OK, although in Russia and Ukraine we prefer "literary braille", but it's not important. |
|
I am adding the author of that tables here, @BueVest should these tables favorized? Should DE-G0.utb and DE-G1.ctb be excluded from screen reader in favor of DE-G0-Bidi.utb and DE-G1-Bidi.ctb? I still see a comment in the newer tables that this is still experimental and should not be included in the core files yet. |
LeonarddeR
left a comment
There was a problem hiding this comment.
from #11263 (comment)
I'm a bit confused about those new German tables. How experimental are they really?
note that we once choose to replace
en-us-comp8.ctbbyen-us-comp8-ext.utbbecause the latter was more complete and extended on the former, so it wouldn't do any harm when it was replaced.What are the intentions of these German tables? Are they meant to replace the old tables? Are their file names persistent, i.e. meant to stay even when the tables are no longer experimental?
|
Additional details in #11263 As we are very close to 2020.2, I think I prefer the german tables to be left out of this. |
|
@LeonarddeR What about the added Ukrainian table, would it be safe to add for 2020.2? |
|
@feerrenrut There isn't any oficial standards of Ukrainian computer braille, so, we've based in on Russian computer braille set with some changings of punctuations. I believe that it's better than nothing... |
|
I"m ok with the Ukrainian ones. There's still some debate going on about the German tables, see liblouis/liblouis#911. @BueVest owns them. |
6085aff to
772f61c
Compare
|
There's still some debate going on about the German tables, see liblouis/liblouis#911. @BueVest owns them.
The bidirectional German tables are being made for two purposes:
1. To be used in note-takers for translation and back-translation.
2. To be used with screen readers for entering Braille.
The original German tables can’t and shouldn’t be used for back-translation. They are marked as “forward” in the metadata section. So, apart from the computer Braille tables, I think NVDA should not try to use them as input tables. There is already an NVDA issue about them not working as input tables (something like “lots of back-translation errors”.
The current status of the bidirectional tables is that grade 0 and 1 are in working order. Grade 2 is waiting for some features to be implemented in Liblouis.
The only differences in forward translation from the original tables are:
1. All capital letters are marked. (also good for proof-reading)
2. The so-called detailed variant of accented letters is used. So, many accented letters have their own Braille pattern in stead of a dot before the regular letter.
Both changes are in accordance with the German rules and are necessary for an improved back-translation.
|
|
@BueVest so do you see the bidirectional G0 and G1 tables as stable enough to be included in NVDA? Or would you advice to wait until the work on G0 and G1 tables is finished? To me they looked prety stable but you might have tested them already also in comparison with the forward translation G0 and G1 tables. |
|
Given the amount of discussion here about the German braille tables, I think it is best to open a new PR just for the Ukrainian tables, and allow the discussion to continue here. The new PR (for the Ukrainian tables) should target the beta branch please. |
|
@feerrenrut What problems have You found about Ukrainian tables? The new Ukrainian computer braille table based on Russian computer braille code and now works absolutely correct. Personally I don't see any sense to continue discussions about Ukrainian tables... Andrey |
|
Not discussion, but if they are to be included in 2020.2 then a new PR must be created. This PR is mostly talking about the German tables, it might as well stay that way. Currently the changes in this PR are for the Ukrainian tables, but the description and discussion is about Germain tables. |
|
Yes, the current bidirectional German tables should be stable. They include specification/rules tests as well as dictionary harness tests.
The next work will be in two areas:
1. Integrating the bidirectional tables more with the forward-only tables. This should have no effect on the features of the tables, but is more about restructuring and refactoring to re-use as much as possible.
2. Implement back-translation for grade 2. This is actually quite difficult with German and other advanced grade 2 systems, because one contraction may mean two or three different things depending on the context. We are currently discussing various ways to go about it without making a very complicated system of rules and exceptions, and exceptions to exceptions etc. I am very open to suggestions.
Hope that answers your question.
|
feerrenrut
left a comment
There was a problem hiding this comment.
This PR doesn't include the German tables, @Andre9642 could you please re-introduce those?
772f61c to
18839ed
Compare
|
Perhaps, you should also disable the old german tables as input tables. If you check the metadata of those tables, it says "direction: forward", meaning that the tables should only be used for forward translation and not back-translation, i.e. Braille input. |
|
Sorry, of course, this only applies to the grade 0, 1 and 2 tables (de-g0.utb, de-g1.ctb and de-g2.ctb), not the 6 and 8 dots computer Braille tables. |
feerrenrut
left a comment
There was a problem hiding this comment.
I think that this looks ok (thanks @Andre9642!) but I would like to get the opinion of @LeonarddeR since he is much more familiar with braille and libluis.
LeonarddeR
left a comment
There was a problem hiding this comment.
I agree with @BueVest that it makes sense to disable input for the old German tables if it's really that broken as he describes. See below.
I see why we want these tables integrated and that there's real demand for it, but I'm still a bit worried about the naming, (improved back-translation, experimental). Looking at it from a user perspective:
- Does a user understand what's meant with back-translation? May be input fits better here, as they are already familiar with that.
- If only back translation was improved, I'd say let's kick out the old German tables and replace those by these. However, it seems that forward translation is also changed with regard to accented letters, according to liblouis/liblouis#911 (comment). I really dig the idea to call these tables detailed as introduced by @bertfrees in liblouis/liblouis#911 (comment)
Altogether, the discussion in liblouis/liblouis#911 really makes me believe that many things about these tables are not set in stone. If we had custom braille tables, I'd probably be against having them in core like this.
I am aware of the fact that my review isn't at all helpful in deciding what to do with this pr. May be @michaelDCurran can also spread his light on this?
|
I believe in the past we were adding new braille tables into the GUI only if someone has requested them to be added - as far as I see there was no such request in this case. |
|
@LeonarddeR the changes in forward translation are related to tilde, dash and some other symbols which in the old german table cause some interpolations with other characters. It seems this tables are improving it and even though it is experimental, I would say there is nothing in there which would break the current user experience. Imo the only way to make a braille table really robust is extensive user testing, different braille displays etc. Thus, I vote for these tables to be included into NVDA, at least in the alpha version for a while. If it's not working well for users, then they could be replaced back by the old tables. But since @BueVest is the creator of these tables, I think he tested them of course and his statement here should have enough weight. Regarding NVDA's Gui, I would vote for introducing a new combo box in the braille settings called "bidirectional tables" and include there all stable braille tables which allow both input and output. If the meaning of bidirectional tables is documented properly in the user guide, I don't see any significant confusion caused by this. |
How would this fit in the UX? I'm afraid this would add even more confusion.
I think this applies to most cases, yes. |
|
I think if the userguide explains in short that forward translation is for output, backward translation is for input and bidirectional is for both, then I don’t see any confusion there. I mean there are many other things outthere which are more confusing for users and they are still documented properly, i.e. set focus to focusable elements or cancelable speech. Just an example.
|
Co-authored-by: Leonard de Ruijter <leonardder@users.noreply.github.com>
Co-authored-by: Leonard de Ruijter <leonardder@users.noreply.github.com>
Co-authored-by: Leonard de Ruijter <leonardder@users.noreply.github.com>
|
@BueVest to which extent does solve your tables the following issues? |
|
Currently, I have only made bidirectional tables for grade 0 and 1, not for grade 2. So,
<liblouis/liblouis#363> liblouis/liblouis#363
has been solved for grade 0 and 1.
<liblouis/liblouis#597> liblouis/liblouis#597
was originally raised for grade 2, but it also applies to grade 0 and grade 1. Like the other issue, it has been solved for grade 0 and 1, but not yet for grade 2.
Solving #597 for grade 2 is somewhat hard, since reliable back-translation of German grade 2 is quite advanced and may take some time to implement. If there is a need for it, I could make an intermediary solution for grade 2 with capital letters, but without proper back-translation. That would fully solve #363.
|
|
* I agree with <https://github.com/BueVest> @BueVest that it makes sense to disable input for the old German tables if it's really that broken as he describes. See below.
* I see why we want these tables integrated and that there's real demand for it, but I'm still a bit worried about the naming, (improved back-translation,
The naming is a big issue with all liblouis tables. There is no proper naming convention. Half the grade 1 tables have the extension .utb (presumably for uncontracted table), while the other half have .ctb regardless of grade.
The Danish tables, which I am maintaining, are split up the same way as the German tables. The 6 dots tables have a literary (-lit) variant, which correspond to the original German tables and a variant without any special naming, which corresponds to the bidirectional German tables.
So basically, forget “bidirectional” and call the tables whatever you like in the user interface. The term “back-translation” is more of a technical Liblouis term, and probably not something the NVDA user should be bothered with. Also, the naming may change anyway if and when a naming convention arises for the Liblouis tables.
Bue
|
|
Chiming in... Bue, I don't think Leonard was talking about file names. Files names are clearly also an issue, but a unrelated one. For the user interface, I recommend using as much as possible what is in the "display-name" (and/or "index-name") metadata of the Liblouis tables. This field was created specifically to be used in applications like NVDA, and to create some consistency across applications. I can't stress enough how much I would appreciate it if you would use our metadata instead of your own names. But anyway, I'm digressing... The naming of the German tables in question, and the corresponding Danish tables that Bue mentioned, is indeed an issue that we are aware of. Their names should indeed be harmonized, and the concerns that Leonard has about the "back-translatable" are right. I think the most likely scenario at this point is that they'll be labelled "detailed" in the next version of Liblouis. |
I see why that's preferred. Doing this automatically is a bit difficult though, as we want the table descriptions to be translatable. |
LeonarddeR
left a comment
There was a problem hiding this comment.
Alright, let's crack the nut. I'm ok with this if the following two changes could be applied with regard to naming, if @BueVest also agrees.
Yes, I suspected that was the case. It doesn't need to be automatic though. |
|
@BueVest as regarding your thoughts about grade 2 tables, they are out of scope for this PR. So you could intermediarily edit the current grade 2 table to solve it, but I would say it's not a high priority. If the bidirectional grade 2 table is created, they this might be considered. |
|
One further thing that I think it is important to discuss, if this table is bidirectional but it is displayed under output tables in braille settings, this could create confusions. |
See review actions nvaccess#11268 (review) Co-authored-by: Leonard de Ruijter <leonardder@users.noreply.github.com>
See review actions nvaccess#11268 (review) Co-authored-by: Leonard de Ruijter <leonardder@users.noreply.github.com>
|
I haven't seen any opposition to the suggestions made by @LeonarddeR, so I will accept them and merge this PR. |
|
@BueVest does it make sense to keep the older german output tables for Basisschrift (g0I and Vollschrift (g1)? Or should these be also removed? I am asking because the coresponding input tables are also replaced now by your bidirectional tables but the old output tables are still in place. |
Link to issue number:
Fixes #11263
Summary of the issue:
New German braille tables are missing in the GUI.
Description of how this pull request fixes the issue:
Adds entries for "de-g0-bidi.utb" and "de-g1-bidi.ctb".
Testing performed:
Ran from sources. Loaded all these tables.
Known issues with pull request:
None
Change log entry: