From: Erkki Kolehmainen (email@example.com)
Date: Mon May 29 2006 - 02:02:43 CDT
In response to the last point: Sorry, firstname.lastname@example.org is a restricted
list, even more so than email@example.com.
Samuel Thibault wrote:
> 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@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 firstname.lastname@example.org properly get
> distributed? I know that at least email@example.com mails are
> silently ignored when you're not subcribed...
> This message was sent via the BRLTTY mailing list.
> To post a message, send an e-mail to: BRLTTY@mielke.cc
> For general information, go to: http://mielke.cc/mailman/listinfo/brltty
This archive was generated by hypermail 2.1.5 : Mon May 29 2006 - 02:12:50 CDT