On 25/07/2012 8:28 AM, Mesar Hameed wrote:
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.table en-us-g2.ctb, English-us, Grade 2Yes, one is provided by the first touple element, and the description as the second element, Or did I miss understand you?
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.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?
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