[liblouis-liblouisxml] Re: Grouping tables according to language and Braille code
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: liblouis-liblouisxml@xxxxxxxxxxxxx
- Date: Thu, 26 Jul 2012 22:11:10 -0500
The locle opcode currently does nothing. Years ago it did contain locale
information, but this seemed superfluous, since it is implied in the
table.
John
On Fri, Jul 27, 2012 at 03:39:48AM +0100, Mesar Hameed wrote:
> John, on a related note, what was the "locale" opcode previously used for,
> and why was it deprecated?
> Maybe its something that we can reuse.
>
> -- Mesar
> On Wed 25/07/12,16:23, James Teh wrote:
> > On 25/07/2012 8:28 AM, Mesar Hameed wrote:
> > >>table en-us-g2.ctb, English-us, Grade 2
> > >Yes, one is provided by the first touple element, and the description as
> > >the second element, Or did I miss understand you?
> > Correct me if I'm wrong, but I think John wants the language to be
> > separate from the table description; e.g. grade 2 separate from US
> > English.
> >
> > >the first element of the touple needs to always be the same so that orca
> > >or nvda do not get confused when i reset their respective interfaces,
> > >also good for saving user preferences.
> > >@Jamie, have I overlooked anything?
> > There still needs to be computer readable metadata about the
> > language of the table and what type of table it is; e.g. whether
> > it's computer, uncontracted or contracted braille. There was again
> > recent discussion about encoding this in the file name, so perhaps
> > code can just parse the table/file name to get this info. A related
> > question is whether the idea of grade 1 being uncontracted and grade
> > 2 and above being contracted is common to all languages. (Some
> > languages seem to have a grade 0 and some grade 3 or more.) If not,
> > we need a separate table type specification.
> >
> > To make things even more confusing, some tables are the native table
> > for certain countries, but aren't named as such. For example, UEBC
> > is used in Australia. It might be good to be able to specify that
> > these tables can be used for locale en-AU, perhaps via a language
> > opcode which can take multiple arguments.
> >
> > How are we going to generate the gettext .po files from these
> > tables? I assume we'll need to write our own tool to do this. This
> > isn't especially problematic, but just curious.
> >
> > Jamie
> >
> > --
> > James Teh
> > Director, NV Access Limited
> > Email: jamie@xxxxxxxxxxxx
> > Web site: http://www.nvaccess.org/
> > Phone: +61 7 5667 8372
> > 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
--
John J. Boyer; President, Chief Software Developer
Abilitiessoft, Inc.
http://www.abilitiessoft.com
Madison, Wisconsin USA
Developing software for people with disabilities
For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com
Other related posts:
