Re: [A12n-Collab] Re: [africa] 5 categories of African orthographies (Latin)

["Andrew Cunningham" <andrewc@xxxxxxxxxxxxx>]

Hi all

I agree wholeheartedly with John Hudson's comments.

Having precomposed characters for Yoruba will not fix anything. It
would probably make things worse.

Already  number of
keyboard layouts using different input frameworks create a range of
possible representations of Yoruba in Unicode.

An interesting
comparison is Vietnamese. There are 8 possible diacritics (if you treat
the horn as a combining character). Each vowel can have 0,1 or two
diacritics.

In theory all vietnamese characters exist as
precomposed characters. And some third party input systems create NFC
output. But if you look at the MacOS and Windows keyboard layouts and the
model they use, it is not possible to create a keyboard layout that would
create NFC output. Microosft's support, from the point of view of
keyboard, but also proofing tools in MS Office, etc are based on using
combining diacritics.

Assuming Yoruba had all precomposed
characters, and assuming Microsoft created a keyboard layout for Yoruba,
The Microsoft keyboard layout would still use combining diacritics. It
would not use precomposed characters. This is a limitaton of keyboard
layouts on Windows, and is unlikely to change.

Full support of
Yoruba on Windows by microsoft would use combining diacritcs. It doesn't
matter if there are or are not precomposed characters. This is the way the
Windows keyboards work.

The best approach for getting Yoruba
support working is too assume that combining diacritic support is
necessary. Also assume that Unicode normalization and case-folding are
important, then get both open source and commercial software developers to
support these aspects of Unicode.

Also fully developed locales
are also important.

Andrew

On Sun, December 23, 2007
1:49 pm, John Hudson wrote:
> Denis Jacquerye wrote:
> 
>> It's rather disappointing and discouraging to see companies
with i18n
>> teams doing great work but totally failing in that
aspect. Category 4
>> orthographies (with composed characters)
face numerous basic issues
>> Category 3 or 2 orthographies
don't, not only at input and display but
>> also at the data
handling level. There really needs to be a greater
>> awareness
for the need of normalization.
> 
> I agree completely. It
is a weak area of internationalisation: strangely,
> since
string
> comparison is such an everyday task for computer
programmers, so you would
> think that
> normalisation
would be something of which they would be quick to
> understand
the importance.
> 
> But as I noted -- and as people
calling for more precomposed characters
> need to understand
> -- normalisation is an issue whenever there is more than one way to
arrive
> at the same
> typeform, so precomposed characters
do not solve the problem and in some
> instances may
>
complicate it further.
> 
> John Hudson
> 
> _______________________________________________
>
A12n-collaboration mailing list
>
A12n-collaboration@xxxxxxxxxxxx
>
http://lists.kabissa.org/mailman/listinfo/a12n-collaboration
> 


-- 
Andrew Cunningham
Research and Development
Coordinator
Vicnet
State Library of Victoria
Australia

andrewc@xxxxxxxxxxxxx