-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tests for Norwegian translation #6
Conversation
For now I've used the provided XML and PEF files for testing emphasis indicators but I see a possible problem with this kind of test data. The test case contains not only text with emphasized passages, but also various other features such as text indentation, borders, page numbers. This means we have to do more fidgeting to make the test succeed (see for example the style.css file) and more features of course also make the test brittle, so that it's more likely that we'll have to modify the test data or the test later, which means more work. In general it's better to test more specific features. For example, just a list of input XML snippets vs. expected braille like in http://snaekobbi.github.io/requirements/test/43.1/test.xspec.xhtml#43.1 (no PEFs) would already suffice. Is more test data coming? Currently we have only one example of strong and one example of em. If you think these examples are representative for all your books (or if you have complete confidence in what liblouis will give us 😄), that's okay, otherwise I would like to see some more data. |
I agree, the test data should be as granular as possible. I think we do have a lot of confidence in liblouis though so if you're ok with this for now then we're ok with this for now. We haven't got any more data planned at the moment, but I'll look through some old braille documentation and see if there's anything that can be used as test data there. Maybe it will be easier to create tests after we try out the first test version of the script. |
Sure, creating tests only when something is wrong with the translation is another approach and I'm okay with that. But I also see these tests as some sort of guarantee that things won't break in the future. Especially for liblouis I think we have to keep in mind things can break because we don't have full control of it but still we want to get table enhancements done by the community (I assume). |
<xsl:template match="pef:page"> | ||
<xsl:variable name="rows" select="xs:integer(number(ancestor::*[@rows][1]/@rows))"/> | ||
<xsl:variable name="cols" select="xs:integer(number(ancestor::*[@cols][1]/@cols))"/> | ||
<!-- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By the way which Unicode braille <-> ASCII mapping should I use to display Norwegian braille? I believe NLB also uses the Easy Embosser Utility? There should be a similar option in the user interface of EEU.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know. I'll check with Kari. What are the alternatives?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it should be one of these: EmbosserTableProvider.java. But I couldn't find Norwegian in there. We can also create a new mapping of course, and I could even use the liblouis display table no-no.dis.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to @Indy78 we use Unicode Braille.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, thanks. But can you really read that??
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no idea. Is this easy to change in the future?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Of course, whenever you want.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool :)
There is currently no definition of 8-dot braille. Need to find out whether defining and/or implementing are in scope. If yes, what is the priority. |
New test data for uncontracted and contracted are available at no_harness.txt, no_harness_g1.txt and no_harness_g1.txt. |
@usama49 While you are looking at snaekobbi/pipeline-mod-braille#41 you can maybe also have a look at requirement 4.3:39 and check if any tests need to be added for this requirement (could be added to test_translator.xprocspec) |
0171463
to
f07c827
Compare
Includes:
Addresses requirements: