Re: [BRLTTY] Braille in CLDR

From: Erkki Kolehmainen (
Date: Mon May 29 2006 - 02:02:43 CDT

  • Next message: Richard Wordingham: "Re: Unicode, SMS, PDA/cellphones"

    In response to the last point: Sorry, is a restricted
    list, even more so than

    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 properly get
    > distributed? I know that at least 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:
    > For general information, go to:

    This archive was generated by hypermail 2.1.5 : Mon May 29 2006 - 02:12:50 CDT