From: Erkki Kolehmainen (erkki.kolehmainen@kotus.fi)
Date: Mon May 29 2006 - 02:02:43 CDT
In response to the last point: Sorry, cldr@unicode.org is a restricted
list, even more so than unicode@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@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@unicode.org properly get
> distributed? I know that at least unicode@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@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