[liblouis-liblouisxml] Re: Liblouis table header
- From: Keith Creasy <kcreasy@xxxxxxx>
- To: "liblouis-liblouisxml@xxxxxxxxxxxxx" <liblouis-liblouisxml@xxxxxxxxxxxxx>
- Date: Tue, 21 Oct 2014 14:15:52 +0000
Ken.
As an XML fan I like the idea but really since LibLouis doesn't use XML
anywhere else it makes more sense to me to keep it as a simple key/value table.
Why add XML dependencies to something that has no compelling need to use it?
-----Original Message-----
From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of Ken Perry
Sent: Tuesday, October 21, 2014 9:55 AM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: Liblouis table header
I wonder though if this would not be better done as an extra xml file like an
index card sort of like how a daisy book is done. For example the xml file
could have all the info for a certain set of tables. It could also list all
the tables that are included in the grouping for example for ueb it could have
all the latten files and the braille pattern file listed as files to include if
you want contracted ueb. Thus the xml tool could be used not only as a pretty
way to show the name of the tables but also a way to group sets of tables
together so you know what tables are affected when you make changes. An index
card could also show relationships between different tables. And you wouldn't
have to have info at the top of every table just a card for each language or
braille type.
Ken
-----Original Message-----
From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of Bert Frees
Sent: Monday, October 20, 2014 2:52 PM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: Liblouis table header
Hammer Attila writes:
> Bert, this is good ydea my openion.
> Now, for example in Orca Screen Reader some Liblouis table names
> marked for translation in Orca side, but more tables not.
> If when Orca future requesting table list from the louis Python3
> binding and the table list function returning the localized table
> name, Joanie have possibility to fill Contraction table combo box with
> translated table name.
> If I understanding right your examples, of course, only presents the
> localized table name when the equals system locale is used.
> For example, when I future using hungarian locale and your example the
> afrikaans table pretty-name is "Afrikaans ongekontrakteerde", possible
> translating future hungarian locale the afrikaans table name with
> "afrikai" table name, or simple presents the english table name future
> when I selecting a table from the Orca preferences dialog contraction
> table combo box?
> Possible extending the pretty_name tag to pretty-name[locale] variant?
> So, the header have possibility to add following style translations:
> pretty-name[af]="Afrikaans ongekontrakteerde"
> pretty-name[hu]="afrikai (irodalmi)"
> This is examples only.
`pretty-name` could be treated as a special metadata field with a special API
call associated, named something like "get_localized_pretty_name(char* table,
char* locale)". For mapping locales to strings in the table header, I had
proposed to use keywords of the form "#+pretty-name-hu", but your idea
"#+pretty-name[hu]" would work equaly fine and looks a bit better.
I come to realize now that we're trying to cover two completely different use
cases here, namely "table discovery" vs. "table name localization". Although
they are both related to metadata, I wonder if it's such a good idea to mix the
two.
Michael Whapples writes:
> Hello,
> Much of that sounds quite good.
>
> I have some questions.
> 1. What if one is doing a partial search of a value (eg. If asking for
> (locale:en) which I might take to mean return any English table
> regardless of country). The reverse may also be desired, where a less
> specific match would be acceptable (eg. (locale:fr_FR) but if that
> specific one cannot be matched then (locale:fr) will also be checked).
> Locales come to mind because this comes up in other things (eg. Java
> applications choosing locale resource bundles), but other criteria may
> need this partial matching on values.
Good point. I would say we treat `locale` as a special keyword and implement
some kind of fallback mechanism. E.g. when the query is "(locale:fr_FR)",
tables with locale "fr_FR" will get the most points, then "fr_FR_*" (a variant,
e.g. "fr_FR_1694acad"), then "fr", and then possibly "fr_*"
(e.g. "fr_CA"). Applications can still check the actual locale of a matching
table and decide to not consider it a match after all.
An alternative is for applications to make several query calls and implement
the fallback mechanism theirselves. (To illustrate, in CSS, several media
queries can be combined in a comma separated list. If one or more of the
queries match, the whole list matches, otherwise not.)
We could also allow applications to override the "matching function" for a
particular keyword, although that's pretty advanced usage already and I would
rather keep it as simple as possible.
Yet another approach is to allow multiple locales in a table header. For
example, a translation table for Spanish braille could possibly also be used
for Catalan. There's no way an automatic fallback mechanism would cover this
case.
> 2. Where you mention doing matches with single keywords, why not just
> be like XPath's attribute matching, just check for a key regardless of
> its value instead of a separate tags field?
The single keywords were meant for things that can't really have a value (apart
maybe for values that evaluate to true or false). For this reason I wanted to
also treat them different from key-value pairs. I wanted to avoid things like
"(locale)" matching all tables that have a locale value. (In CSS media queries,
features, as they are called there, without a value actually kind of behave
like this. E.g. "(color)" means "(min-color: 1)". But this only really makes
sense if the required value type is an integer.)
But I also see where you're coming from. It might simplify things if we could
eliminate the special-purpose keyword "#+tags".
What if we make "(some-tag)" match tables with the field "#+some-tag" but not
tables with the field "#+some-tag: some-value"?
> 3. I imagine the API would have a query for tables function (IE. I
> give it a set of key, value pairs and it gives me a table which matches).
> There may be queries which could give multiple tables (eg. (grade:2))
> so the function may return multiple tables. I think this would be
> better than just a single table (eg. the first matching table) as then
> the application could present the options to the user.
OK, makes perfect sense.
> 4. Thinking back to question 1, I think the indicator value may be
> useful, even with the query for tables function (IE. one could list
> the tables in order of best match). Also a function to check a named
> table against criteria may also be useful (IE. if the application
> wants to take more control over table handling, eg. caching query results).
OK.
> On 20/10/2014 15:49, Bert Frees wrote:
>> Hi all,
>>
>> I want to bring this subject up again because we've been discussing
>> it so many times and I think it's about time we finally do something.
>> To recap, we need to develop a header format that can contain
>> metadata about the table, and an API for extracting metadata and querying
>> tables.
>>
>> Greg's proposal with the single-line comment on the first line was a
>> good start. But I'd like to have something a bit more
>> flexible/extensible. I have worked out something and I'd like to have you
>> guy's opinions and suggestions.
>>
>> For my DAISY Pipeline 2 work I have been nurturing the idea of
>> selecting translators based on some kind of "translator query". The
>> use case is quite the same as we have here for liblouis. The syntax I
>> am proposing for DAISY Pipeline is inspired by CSS media queries. A
>> query is basically a list of key-value pairs or keywords. I'm not
>> proposing to use exactly the same syntax for liblouis, but I believe we need
>> something similar/mappable.
>>
>> Let's take Greg's example:
>>
>> #afr#1#Afrikaans Uncontracted#za#Afrikaans ongekontrakteerde
>>
>> It consists of 5 metadata fields. 3 of them can be used for automatic
>> table selection. The two other are for pretty printing in graphical
>> user interfaces. Combining the two locale fields (language and
>> country) into a single tag, the corresponding CSS query would look like this:
>>
>> (locale:af-ZA) (grade:1)
>>
>> The same key-value pairs could be put in liblouis table headers. I
>> like the idea of having the metadata in special comments, in order to
>> assure backwards compatibility of new tables with old library
>> versions, and so that implementations of the liblouis table format
>> can choose whether or not they support metadata.
>>
>> A possible syntax could be `#+<KEY>: <value>`
>>
>> #+LOCALE: af-ZA
>> #+GRADE: 1
>> #+PRETTY_NAME: Afrikaans ongekontrakteerde
>> #+PRETTY_NAME_EN: Afrikaans Uncontracted
>>
>> (This is org-mode's syntax by the way.) The keywords would be
>> case-insensitive. Some keywords will be standard, such as LOCALE,
>> GRADE and PRETTY_NAME, but I wouldn't restrict the allowed keywords
>> in any way, in order to keep the system flexible.
>>
>> The CSS query syntax also allows single keywords, without a value. For
>> example:
>>
>> (ueb) (grade:2)
>>
>> This could be reflected in a `#+TAGS` field with a list of
>> space-separated
>> "tags":
>>
>> #+LOCALE: en-US
>> #+GRADE: 2
>> #+TAGS: ueb
>>
>> I haven't really thought about the API yet. It would be nice if one
>> could provide a list of key-value pairs and/or single keywords,
>> together with a table path, and get a table name back. The keys could
>> possibly be sorted by importance, and the API could possibly return some
>> kind of "matching quotient"
>> that indicates whether the table is a good match for the query or not.
>>
>>
>> Thoughts?
>> Bert
For a description of the software, to download it and links to project pages go
to http://www.abilitiessoft.com For a description of the software, to download
it and links to project pages go to http://www.abilitiessoft.com
For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com
Other related posts:
