[BRLTTY] Braille in CLDR

[Samuel Thibault]

Hi,

Erkki Kolehmainen, le Fri 26 May 2006 15:46:00 +0300, a écrit :
> In response to Steven's questions, I'd like to state as my opinion:
> 
> >Therefore, as regards braille, should CLDR (or, something in CLDR  format) 
> >attempt to provide a repository of transforms between Unicode  non-braille 
> >text and Unicode dot patterns,  or should CLDR attempt to  encode the 
> >actual braille dot patterns?
> 
> I'd envisage that as the first step we should provide a repository of 
> transforms between Unicode Braille dot patterns and Unicode non-Braille 
> text for each defined/definable cultural environment.
> 
> >In the case of encoding the dot-patterns, CLDR would be able to  provide a 
> >repository of information - including abbreviations - for  things such as 
> >language/region translations, dates, times, timezones,  calendars, 
> >measurement systems, etc etc.  
> This could well be an important future work item.

I'm wondering how all this should be organized.  The problem I see
is "how to have application produce fine braille output".  I can see
several approaches:

1. Just defining new locale categories for braillified dates/times/etc.
would mean that all applications have to be modified for using them when
they want to produce braille (but when would they want to?).

2. Defining new braillified locales, i.e. have exactly the same
categories, but with braille patterns in it instead of usual
alphabetical words, i.e. people would export LANG=en_US at brl instead
of LANG=en_US, and then all applications would automatically produce
braille patterns.  This would be quite neat for blind users... but not
for a sighted user that may want to follow what the blind user is doing,
since the screen would show dot patterns too!

3. Defining locale categories that describe how to _convert_ localized
strings into braillified strings.  This is an approach quite similar to
1., except that the target is not _applications_ (that just continue
to produce alphabetical localized strings), but _screen readers_,
which are provided the information on how to transform alphabetical
localized strings into braillified localized strings.  This is very
similar to approach 1 since it seems like the needed additionnal
categories are just the same with same content.  A screen reader would
for instance just always convert nl_langinfo(DAY_1) ("Sunday") into
nl_langinfo(BRL_DAY_1) (the contracted braille equivalent).  The problem
is then "when to apply this?" i.e., should a screen reader, when seeing
"Sunday", always convert it into the contracted braille equivalent?  A
maybe-problematic example is when some software wrote "Sunday" without
using locales: in such case the screen reader would contract the word.
But this looks like an already known problem: "should the screen reader
use contracted braille or plain braille", which I guess is already
handled by screen readers (via a shortcut for switching between both
modes, I guess).

It looks to me like approach 3 is the most pragmatic one: letting
applications continue to use usual CLDR categories, and share braille
tables between screen readers.

Note to Erkki: do mails that we send to cldr at unicode.org properly get
distributed?  I know that at least unicode at unicode.org mails are
silently ignored when you're not subcribed...

Regards,
Samuel