[BRLTTY] Braille in CLDR

[Erkki Kolehmainen]

In response to the last point: Sorry, cldr at unicode.org is a restricted 
list, even more so than unicode at unicode.org.

Regards, Erkki

Samuel Thibault wrote:

> 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
> _______________________________________________
> This message was sent via the BRLTTY mailing list.
> To post a message, send an e-mail to: BRLTTY at mielke.cc
> For general information, go to: http://mielke.cc/mailman/listinfo/brltty
>