Sorry,
I only wanted to recall the current practice. Consistency is good. I hoop it
will not lead to more complicated structures. Currently some files use many
nested include files. If that can be avoided, the tables will be easier to
oversee.
Arend Arends
-----Oorspronkelijk bericht-----
From: Bert Frees
Sent: Thursday, August 13, 2015 1:16 PM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: Suggestion to all table authors: note
purpose and proper use inside table
We were talking about using file extensions more consistently, and from that
point of view, I can see how adding such a rule could help with that. Tables
can
always be modularised in such a way that top-level tables are never
included.
(Although now that I come to think of it, in cases where you don't have
control
over the modularisation of the table that you want to include, this may not
work. But then again, you probably shouldn't include tables that you don't
have
control of anyway.)
So, while I can see the advantage of such a rule, it may have practical
issues.
Lars Bjørndal writes:
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 FreesFor a description of the software, to download it and links to
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
project pages go to http://liblouis.org
