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
New table for Greek braille #243
Conversation
gr-forward.ctb is for forward translation. gr-backward.ctb is for back translation. gr-common.cti is included by both. Back translation of English letters isn't supported yet.
Great. Looks good. There are a couple of things we ask for every new table or table change:
Also:
|
gr-bb isn't proper Greek braille. It uses the English braille way of
representing Greek letters. It'd be rather difficult for one used to real Greek
braille to read it. One examle is that it uses dot 6 for the capital sign
whereas actual Greek braille uses dot 6 as the Peripsomeni (circumflex) accent.
Antehr example is that it uses dots 2456 for Omega wehreas actual Greek braille
uses that for an Eta with a Ypogegrammeni (subscript Iota) accent. A quick look
at gr-gr-g1 shows that it doesn't deal with accents very well and has lots of
wrong signs.
|
@egli What should we do with gr-gr-g1.utb? Regarding table metadata: this is the metadata we currently have for gr-gr-g1.utb: https://github.com/liblouis/liblouis/blob/4bf05ebe25c3d28d99e988ef84dd133595b99aa1/tables/el.tbl. |
Regarding the test: especially the mixed Greek/English deserves some attention. |
@bertfrees I don't know what to do with the old greek table. I see the following options
Option 3 is what we have traditionally been doing, basically just avoiding the issue. Not a great solution. Option 2 will likely not yield any more trustworthy results than what we have now. So I tend to go with option 1. I think we should try option 2 and wait a week then just do option 1. |
- [ ] Update AUTHORS file. Dave is currently only listed under "BRLTTY".
Do you do that, or should I? If I should do it, in which section? Patches
provided by?
By the way: I'm also listed under table contributors, probably due to brltty.
|
@DaveMielke I see. I didn't check it, just assumed. But you should be listed under "patches" too when your pull request #244 is merged. But don't worry about the AUTHORS file we take care of that. @egli Yes option 3 is definitely to be avoided. We'll ask on the mailing list with the ViewPlus people in CC. |
[quoted lines by Bert Frees on 2017/01/11 at 02:50 -0800]
this is the metadata we currently have for Greek:
https://github.com/liblouis/liblouis/blob/4bf05ebe25c3d28d99e988ef84dd133595b99aa1/tables/el.tbl.
What should be specified for a language that doesn't have grades of braille?
Greek braille, for example, does have eight single-cell braille symbols for the
common diphthongs, but there's no concept of a less contracted form that
doesn't use them.
|
Hmm, I'm not sure. The only categories of contraction I've used so far is "contraction:no" (the default) and "contraction:full". The idea is to add more values such as "partial". We could add a value for your case too, but I don't know if it's common enough for a new category. I would say this belongs to "contraction:no", but a comment saying what you just said would be useful I think. |
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.
Thanks! Good that you included the "direction" tag. I have thought of that before, but can't seem to find it in my documentation. Note that I'm going to remove the tags from gr-common.cti because it's a table meant to be included in other tables, and only top-level tables should have metadata.
…ers in the Greek table in order to make lou_checkyaml work better. (dm)
…evel directory. (dm)
…ll leaving it there).
There's no more need to remove the metadata from the Greek common rules
subtable (el-common.cti) as I've changed #+ to #- in order to achieve that goal
without removing the data.
|
Thanks. I wanted to do the exactly same (remove the plus signs but leave the metadata in). Until we have figured out what the tool for printing the metadata is gonna look like, it doesn't matter, so I just wanted to keep things like they are. But I'm taking your arguments for having metadata in all files into consideration! |
Maybe add metadata to subtables using #- as a common convention so that it can
be easily reactivated when all those decisions have been made. Maybe leave it
as #-, even then, so that a special option can be used to also look for that
prefix.
|
Hi @DaveMielke would it be possible to add license headers to these tables the same way the others specify the license? We've been burned in the past and now we want to be extra-safe. Something like https://github.com/liblouis/liblouis/blob/master/tables/Cz-Cz-g1.utb#L3-L21 for example? That way it would be the same as all the other tables and we can use an automated tool to scan for licenses. Thanks |
@DaveMielke Regarding the (temporary) convention: sure. But making it permanent would exactly come down to what I had in mind initially, and what you were against! Right? |
I'll add whatever kind of license header you'd like. I guess the #+license:LPGL
metadata isn't good enough.
|
I don't think I was against anything other than not having subtable metadata or
having it but not eventually being able to look it up. I just make suggestions.
I'm not even sure what the best thing to do is, but that doesn't stop me from
putting ideas on the table (pardon the pun).
|
OK fine. I was just a bit surprised because from the previous discussions I had the impression that you didn't like the idea of having two different formats for metadata... By the way I know it's only suggestions but it really helps me and I appreciate your input. |
Doing it with #+ and #- isn't really two separate formats. It's more like the
same format with a flag.
|
OK, yes, but anyway, this is what I've had in mind from the beginning. I should have been more clear about it. |
You were probably still getting used to me. I tend to speak very directly, and
that often catches new people a little by surprise.
|
OK, license is perfect now. Thanks |
All that is left to do now is to ask ViewPlus whether we can replace their table. @DaveMielke Have you thought about that reference to the specification of the implemented braille code? Is there something we can point to? |
@DaveMielke Have you thought about that reference to the specification of the implemented braille code? Is there something we can point to?
It's right up at the top in all three files (lines 2 and 3).
# ελληνικό σύστημα μπράιγ [Greek Braille System]
# κέντρο εκπαίδευσης και αποκατάστασης τυφλών [Center for Education and Rehabilitation for the Blind]
|
OK, I see. Is there some document we can put online? It can be in Greek. If there's nothing available it's fine. I can find some documents, but I'm not sure which corresponds to what you implemented:
I can also find the website of the organisation (http://keat.gr), but no documents there. |
It seems that Greece is being a little more informal about the whole thing.
There are documents online, but, at least the ones I've looked at, contain
errors. I was working with a very well-informed Greek lady in the US who's
well-connected to people in Greece. While chatting with her, she expressed to
me how unhappy Greek people were to have had such poor support in the past and
was clearly totally thrilled when she finally got to give this table a try.
|
Merged manually from the https://github.com/liblouis/liblouis/compare/dm/integration branch |
OK, I've asked on the ml what to do with the old table |
Thanks. Maybe forward the email directly to someone of ViewPlus? We've had complaints before because we changed file names. Of course sometimes that is unavoidable, but I think if it is possible to keep a file name that is preferable. So if the old Greek table can be removed it would be better to do it now as opposed to some time later because then we can use the old name. WDYT? |
No description provided.