[liblouis-liblouisxml] Re: Suggestion to all table authors: note purpose and proper use inside table

  • From: Lars Bjørndal <lars@xxxxxxxxxxx>
  • To: liblouis-liblouisxml@xxxxxxxxxxxxx
  • Date: Thu, 13 Aug 2015 12:46:24 +0200

On to., aug. 13, 2015 at 11:44:21 +0200, Arend Arends wrote:

Hi Bert,

I think *.utb and *ctb files can be included, but must also work stand
alone. For instance in en-ueb-g2.ctb the file en-ueb-g1.ctb is included
(version 2.6.3).
*.uti and *.cti files are include files that can not be used stand alone.

[...]

I agree to that. In the Norwegian tables, no-no-g0.utb (uncontracted)
is included into no-no-g1.ctb (contracted level 1). no-no-g1.ctb is
included into no-no-g2.ctb (contracted level 2). At last we have
no-no-g3.ctb, which includes no-no-g2.ctb. As contracted braille in
e.g. level 1 is a subset of a higher levels, it makes sence to just
include that subset. I can't see why this should be changed.

Thanks and regards,
Lars

-----Oorspronkelijk bericht----- From: Bert Frees
Sent: Thursday, August 13, 2015 10:50 AM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: Suggestion to all table authors: note
purpose and proper use inside table

Thanks Davy, fully agree.

File extensions, and file names as well, must be seen as a complementary way
of
determining what a table is about, mainly for humans. Like you say, the file
name conventions that we are currently using must be respected and used
consistently, and could possibly be extended. *.cti tables should be
included in
at least one table, and I think you're right that *.utb table should never
be
included.

The main source of machine-readable table meta data however is in the file
itself.

/Bert



Davy Kager writes:

An additional point of concern (or maybe an alternate solution to the
problem) is the liberal use of file extensions. If I recall correctly, we
now have:
* .uti = uncontracted include table
* .cti = contracted include table
* .utb = uncontracted table^1
* .ctb = contracted table^1
1. 'table' can be for translating forward, backward, or both.

First, I think these extensions could be used more consistently. A *.utb
table shouldn't be included (like you also don't normally include a
*.cpp).
Second, we could maybe extend the list of extensions:
* .ftb = forward-translating table
* .btb = backward-translating table

On the other hand, if you also do this for the include tables you create a
forest of extensions that nobody will ever grasp. But I wanted to bring it
up anyway because of the first point (more consistent use). I am a huge
proponent of structured metadata in tables.

-----Oorspronkelijk bericht-----
Van: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] Namens Bert Frees
Verzonden: woensdag 12 augustus 2015 19:20
Aan: liblouis-liblouisxml@xxxxxxxxxxxxx
Onderwerp: [liblouis-liblouisxml] Re: Suggestion to all table authors:
note purpose and proper use inside table

Thanks Bue,

Yes, if we would tag tables suited for backward translation with e.g.
"#+backward", programs could use the "backward" tag as part of the table
search query in order to filter out the tables that don't have the tag.

Similarly the tag "#+forward" can be used for tables that are suited for
forward translation.

Tables that are suited only for inclusion in other tables can be
distinguished from the "top-level tables" based on whether the table
header has meta tags or not.

Also related: https://github.com/liblouis/liblouis/issues/43

/Bert


Bue Vester-Andersen writes:

Hi,

In view of the recent discussions on back-translation on the list, I
would like to encourage all table authors to note down the specific
purpose and proper use of their tables.

Some tables only implement forward translation. Some implement both
forward and backward translation, and in some languages you might have
different tables for forward and backward translation. The latter is
actually recommended in the manual if you use multi-pass opcodes.

Also, some tables might only be for inclusion together with other tables.
For instance, this is true with da-dk-nocaps.uti, which use the "correct"
opcode to remove the so-called "unnecesary" caps before translation.

If we could note down in the tables how they are supposed to be used,
developers who use liblouis wouldn't have to break their necks trying
to find out, for instance, if a given table could be used for
back-translation.

I also thought that we could make this info available as part of the
meta data, but would it be of much use in a programatically readable
form?

Best regards Bue
For a description of the software, to download it and links to project
pages go to http://liblouis.org
DISCLAIMER:
De informatie verzonden met dit e-mail bericht is uitsluitend bestemd voor
de geadresseerde. Indien u niet de beoogde geadresseerde bent, verzoeken
wij u vriendelijk dit aan de afzender te melden (of via:
info@xxxxxxxxxx<mailto:info@xxxxxxxxxx>) en het origineel en eventuele
kopieën te verwijderen.

The information sent in this e-mail is solely intended for the individual
or company to whom it is addressed. If you received this message in error,
please notify the sender immediately (or mail to
info@xxxxxxxxxx<mailto:info@xxxxxxxxxx>) and delete the original message
and possible copies.

For a description of the software, to download it and links to
project pages go to http://liblouis.org


For a description of the software, to download it and links to
project pages go to http://liblouis.org

For a description of the software, to download it and links to
project pages go to http://liblouis.org

Other related posts: