Still on development:
www.okwuigbo.org
Chinedu...




>From: QT - BisharatNet <qtopic+17-tCcDxVXHgQxN@quicktopic.com>
>Reply-To: QT topic 17-tCcDxVXHgQxN <qtopic+17-tCcDxVXHgQxN@quicktopic.com>
>To: QT topic subscribers <qtopic+subs@quicktopic.com>
>Subject: Igbo language & ICT (fonts, keyboards & applications)
>Date: 14 Oct 2006 07:33:07 -0700
>
< replied-to message removed by QT >

Edited by author 10-14-2006 10:45 AM
Just came across a list about the Igbo language in German: http://www.igbodeutsch.de/ (it's actually a Yahoogroup).

Two thoughts:

1. It would be great to have a list of lists about and in African languages. The links at http://www.bisharat.net/links2.htm#11b are an attempt at that (these need updating). Re Igbo language, we have heard on this forum previously about Ụwandịigbo* for instance.
2. Are there any lists in Igbo?

Don Osborn
Bisharat.net

* /m86, /m92, /m115, /m124, /m129, /m131, /m136, /m164

A short online Igbo dictionary is available at http://www.umes.edu/alp/lexicon1/public/default.asp

Issue: Now I can type words from Nigerian native languages on my PC, but I cannot save these words into my custom dictionary. Every time I tried to save words with Hausa, Ěgbo or Yorůbá characters, I get a message that: “The custom dictionary is full. The word was not added.”

Solution: The custom dictionary is a notepad that is defaulted to ANSI encoding, to save non ANSI characters, like Hausa, Ěgbo or Yorůbá words that includes Ẹẹ, Ịị, Ọọ, Ụụ or tonal marks, you will need to change the custom dictionary encoding from ANSI to Unicode.

How to change Custom Dictionary encoding in Windows XP:

1. Click - .START button on the left bottom of you screen;
2. Click - My Computer from the menu;
3. Open – Local Disk (C:) from the menu;
4. Open – Documents and Settings folder;
5. Open – [Your User Profile] folder;
6. Open – Application Data folder;
7. Open – Microsoft folder;
8. Open – Proof folder;
9. Open - CUSTOM file;
10. Click – File at the top left corner;
11. Click – Save As from the menu;
12. On the line for Encoding – click the dropdown and select Unicode;
13. Click – Save button;
14. Click – Yes button;
15. Click –CLOSE ALL FOLDERS

KỌNYIN Nigeria Multilingual Keyboards
http://www.konyin.com

NITDA to promote Nigerian keyboard

Everest Amaefule, Abuja

The National Information Technology Development Agency has pledged to promote the study of Nigerian languages through the use of information technology.

Director-General, NITDA Prof. Cleopas Angaye, made the commitment on Friday in Abuja when a team from Lancor Management Limited, presented a special computer keyboard and software known as Konyin, that can write most Nigerian languages to the agency.

Angaye said the promotion of Nigerian languages through IT has become imperative at a time when several languages are becoming extinct because of generations that have been alienated by their mother tongue.

He congratulated the Lancor team for integrating both software and hardware to achieve the feat of the special Nigerian keyboard and pledged to promote the keyboard especially in the public sector.

Full Story... http://www.punchng.com/computer/article05

The PUNCH, Monday, January 16, 2006

Dear Adé,

re /m187

You asked: "My question is will most of these scripting issues go away if we have websites and contents developed using default fonts, especially OpenType fonts, with complete features for GSUB and/or GPOS layout tables?"

With correct OpenType fonts, rendering issues will disappear, i.e. with a well developed font NFC, NFD or hybrid data will display fine (in the visual sense) and will be visually indistinguishable.

It will not directly address the issue of how web services handle data and how they processes data. There will be no way to escape the need for normalization and proper internationalization of services. There is an educative process that needs to occur.

With respect to your house keeping message. Thank you for the information. I'm familiar with these details from looking at your website.

I had thought of writing such a book, although it will have to wait until I finish one on electronic multicultural library services that is underway. If I did write one, i'd be inclined to release it under a creative commons licence, making it available for free and allowing it to be used in fairly liberal ways that traditional copyright wouldn't allow.

Either way ... a key source of information on web internationalization are the W3C Internationalization techniques documents that are being developed by the W3C I18N GEO working group combined with Richard Ishida's turtorials. All are available at http://www.w3.org/International/geo/

Although it might be worth writing a companion document to these tutorials on issues like the need for normalization, and font selection issues, etc that impact on African languages. I'll have a chat with some of the other GEO folk and see if an FAQ on web development with African languages would be worthwhile.

Andrew

Edited by author 11-06-2005 01:22 PM
Hi Andrew,

Your passion about correct internationalization practices for website and web-content developers show through in your latest write-up and like I said before I or my company are no experts in these arena. Your scripting suggestions are very informative and I hope that web developers reading your posting will use it effectively.

Our single focus is that if the input device hardware (keyboard) allows you to easily type the character, then the character can be used anywhere in general programming.

My question is will most of these scripting issues go away if we have websites and contents developed using default fonts, especially OpenType fonts, with complete features for GSUB and/or GPOS layout tables?

Some house cleaning issues I will like to address: KỌNYIN Multilingual keyboard is not a Nigerian keyboard layout project. The technology behind the 63 alphanumeric keycaps with 4 shift keys was created by LANCOR Technologies of Boston, MA United States. (http://www.lancorltd.com/Konyin.html) The hardware created by the company can be used for any combination of character-sets regardless of the scripting, from Cyrillic, to Syllabic, to Latin alphabets. Like I said in explaining the input/output as using Unicode standard for handling fonts, if the character has a code point in the Unicode charset we can create a layout mapping in our driver for it. The keyboard driver compilation is language neutral.

We have used the LANCOR Multilingual Keyboard Technology (LMKT) to create a multilingual keyboard for United States, which included all Latin characters and tonal marks for English, Espańol, Deutsch, Français, Gaelic, Italino, 'Ōlelo Hawai'i, Polski, Portuguęs, etc... The keyboard is currently on sale and is expected to be available in some major retail stores in the US in January. (http://www.konyin.com) We are also in the final stages of releasing the KỌNYIN South American Multilingual Keyboard that will represent all the Latin characters and tonal marks for Spanish (Espańol), Portuguese (Portuguęs), English, Italian (Italiano), German (Deutsch), Quechna (Runasimi), Aymará, French (Français), Guaraní, Dutch and other Latin alphabetic languages.

Just thought it is very important to make the distinction. LANCOR Technologies is a division of Lagos Analysis Corporation (LANCOR) and the privately held company is owned by two US based Nigerians, which should explain why the LMKT was first used to create a multilingual keyboard for all Nigerian languages combined and why the product carries a Nigerian name. KỌNYIN in Yorůbá means “a drop of honey.”

So much for my rambling about our company, the issues of correct representation of extended and combining Latin characters in website and web content development, which is better understood by people like you, should be disseminated through information exchange. Have you thought about writing a book on this, something like “Proper techniques for developing internationalized website and contents for dummies?” I will buy it.

Adé G Oyegbọla

Thanks Adé.

I believe that your reply has answered my initial query, thankyou. I now have a much better sense of how your product compares with others wrt to character sequences generated. Considering the limitations Microsft related technologies place on keyboard layouts, the output scenario you describe for KỌNYIN is a practical approach that has avoided some of the problems other Nigerian keyboard layout projects sometimes have.

As you noted this forum, much like a lot of other projects including web based email, discussion boards, blogs and wikis do hold traps for Nigerian languages. The in-house script you describe for converting to precomposed characets is useful. Within our projects we have similar scrips allowing us to convert to NFC or NFD and also NCRs for HTML. Sometimes they prove to be useful.

WRT QuickTopic ... the server is identifying the character encoding as ISO-8859-1, so the only effective way of adding text in African languages is to add the text (with a codepoint above U+0255) as NCRs. Mozilla, Firefox and Opera handle fonts somwwhat differently than IE. If a character is missing in IE, it will show the "missing glyph" glyph from the font being used. Current typographic convention is to display a square box or rectangle. Mozilla, Firefox and Opera on the other hand will instead change the font for that one characer.

Either approach results in problems with combining daicritics.

And if the website is using a font that has copepoints for the diacritics, but isn't an appropriate OpenType font, then the display will be sub-optimal.

The only successful way to render such text is with an appropraite OpenType font and an appropriate version of usp10.dll (ie use winXPSP2) or alternatively use a graphite font and a graphite enabled version of Firefox (on any Windows or Linux), or appropariate solutions on the MacOS.

With Firefox and the URIid extension (https://addons.mozilla.org/extensions/moreinfo.php?id=563) its possible to write website specific CSS rules in the userContent.css file to override QuickTopics default fonts.

In my userContent.css file I have the following rule:

body#www-quicktopic-com div.messagecell {font-size: 1.1em !important; font-family: Doulos SIL !important;}

This is a quick hack. The ideal situation would be to use web services that are well internationalized and meet the needs of African languages. Instead we have to work around implemetations.

The chromEdit extension (http://cdn.mozdev.org/chromedit/) is a useful tool for editing the userContent.css file.

Likewise in Firefox and Mozilla it is possible to add a CSS language psuedo selectors to match a language and override the font of the website. This approach is useful, BUT only when web developers markup the primary language of a website or markup any change of language. Some do, some don't.

For example, you could add the rules:

*[lang|="ig"] {font-family: "Charis SIL",serif !important;}
:lang(ig) {font-family: "Charis SIL",serif !important;}

These CSS rules would kick in if the web developer had language tags in the web page that identified the page or part of the page as Igbo.

I started working with the issues arising from multilingual web development, multilingual public access services, electronic multicultural library services and resource discoverability of multilingual government documents since late 1994. Things have got a lot easier over time. Unfortunately there are still issues that need resolving as African langauge web content increases.

Re the issue of getting KỌNYIN Africa Multilingual
keyboard. I tend to use multiple operating systems. Win98SE, Win2000, WinXPSP2 and we're also using Ubuntu Linux. When working with languages that use combining diacritics I predominately use WinXPSP2. I've had minxed results on Ubuntu. I need to test on other Linux distros, but to date I've found that I get the best results in Linux if I use graphite enabled software (I haven't had a chance to apply Graphite patches to Pango/Gnome yet). Ubuntu doesn't seem to handle OpenType support for combining diacritics.

Andrew

Edited by author 11-04-2005 12:09 PM
Hello Andrew, /m184

Another good description and recap of issues relating to multilingual computing outside the “AmeriEuro” languages circle, I totally agree with all your observations, however, it is important to always distinguish between the input device itself, the translation functionality of the OS and font text rendering that is application dependent.

The question I answered arose because of the way you framed the issue in /m178
“In the case of KONYIN, KONYIN's approach is interesting, but like most Igbo/Nigerian input projects, KONYIN doesn't give any idea of what output their keyboard layout generates.”

I think you differentiated it better in your reply /m184 item4 “rendering of text is OS specific and also specific OpenType, AAT or Graphite fonts (depending on what OS and what font rendering etchnology is being used).”

Other than this observation I really don’t have much to add to your recap of the issues relating to rendering and display of extended characters both precomposed and combining ones.

In the case of keyboard layout mapping, the correct use of Hex or Unicode code point is paramount. (Like the famous saying: garbage in, garbage out) KỌNYIN uses Unicode code points for its character mapping. KỌNYIN uses both precomposed and combining diacritical marks’ Unicode code points. All the characters labeled on keycaps uses precomposed Unicode code points in the mapping. You can only achieve characters with tonal marks by combining a based character with a tonal mark. All the tonal marks labeled on keycaps uses combining diacritical Unicode code points. The approach we believe gives consistent and uniform result for text handling and rendering regardless of the application. The technology is fully Unicode standard reliant, which is why the keyboard driver is only designed for Windows 2000 or above. (We are presently in the final development of the Mac OS X and Linux versions)

For our own in-house uses, we do have a script that maps any combining character to a corresponding precomposed glyph for internet communication purposes, like typing into this quicktopic portal. As you know, this portal does not translate combining characters properly and the default font does not include all extended Latin characters, so when you see “Adé” in my typing it is actually in Unicode code point lingo as U+0041, U+0064 & U+00E9; even though what I typed using the keyboard originally is U+0041, U+0064, U+0065 & U+0301.

Like you said, the answer is proper knowledge of scripting by web developers and better application development techniques by application programmers.

For Ěgbo and other tonal languages, the ability to freely use tonal marks is mandatory; and an input device without these capabilities will not be universally accepted. Trust me, we know, we spent over 7 years to arrive at that conclusion.

On the issue of getting KỌNYIN Africa Multilingual keyboard, we are presently waiting for final agreement of the characters to be included from our team of linguists. This is due before the end of this month. Currently the driver is for Windows 2000 or above, but we expect the beta for Mac OS X and Linux to be ready before the end of this year. So if you like to wait for the Linux version, we should begin shipping in February.

Que sera sera

Adé

Hi Adé,

Good to hear from you. Thankyou for your response.

1) I'd be interested in the possibility of getting KỌNYIN to work with SCIM or even KMFL on the Linux platform,esp teh African keyboard underdevelopment.

2) re /m183

I wasn't asking a question. Just raising the issue that people may need to be aware of further down the track:

1) currently different input solutions for Igbo do produce different output. One input solution (NITDA) does produce invalid sequences.

2) most applications DO NOT normalize text. Irregardless of whether they should. You mention Dreamweaver (one of the few tools that does have an option to normalize text). Unfortunately Dreamweaver is an exception rather than the norm.

3) major web services like Google and others do not normalize data. Despite Unicode and W3C recommendations that NFC data should be used on the web.

Web authors are the ones who should be responsible for normalizing their web pages, and currently most web tools don't allow normalization. But then a lot of commonly used HTML and XML editors can't handle Unicode or have broken Unicode implementations.

4) rendering of text is OS specific and also specific OpenType, AAT or Graphite fonts (depending on what OS and what font rendering etchnology is being used).

You say
(E.g. if you use one keyboard to type "Ẹ" it may look different using another keyboard)

I'm not discussing whether the output appears the same, thats a font and font rendering issue. I'm discussing which unicode characters are in the data.

As I said before I don't care what input solution people use to type. They can use any keyboard driver or keyboard they like.

As you indicate. It is an issue for content developers and authors. Therefore content developers and authors need to know what their tools do or do not do. They need to be aware that different keyboard drivers will produce different character sequences. They need to know that their web pages may be searchable through Google with certain drivers and not with others. Mainly a problem for people who use tones. They need to be aware that they should normalize their pages or their data. They can do this with Dreamweaver or they can do it with other tools. Generally most websites are scripting langauge and databse driven, so it usually should be done in the scripts before data is saved and before a search is conducted.

people creating word documents converting them to correctly generated unicode PDF files and uploading them to the web need to know that there are discoverability issues.

It will impact on spell-checking in word processors. The issue has already been seen in some Microsoft Office proofing tools for languages Microsoft uses combining diacritics for.

Passing of the issue as a purely application or developer issue ignores the fact that most applications and web services do not normalize data. It ignores the fact that the content developers and authors need to be aware of the issue. It ignores the fact that end users will have resource discoverability issues.

NITDA is a bad example here since their keyboard actually uses depreciated characters, ie some of the characters it uses are the wrong characters (characters that Unicode standard says should NOT be used).

Yes, in theory, I'add agree with your statement that "the action between an input text and what is displayed in the application or internet browser is not directly related to the keyboard used".

This assumes that application developers have done the right thing. But since most Latin script languages only use precomposed characters, and the need for normalization is only critical for some African , Central Asian, and a handful of South east Asian languages, which most developers are in ignorance of ....

You end up with a situation where very few software developers are aware of the need for normalization in their tools.

The whole point of my replies, isn't really about the relative merits of different keyboards or keyboard drivers (except for NITDA who really DO need to fix those flaws in their keyboard layout).

The issue I have is that end users esp. people who will be developing content for the web, whether its X/HTML, XML, RTF, DOC, PDF, text or some other format need to know that

1) differnet character sequences may be produced by different input solutions (most notably with tones). I believe it is useful for a developer or author to know which format their favourite input solution uses. Since this will inform their need to normalize data (if they are producing content only). If their site also collects data or allows searching normalization should alwyas occur.

More importantly, they need to be aware of the issue. They need to be aware that they need to take normalization issues into acocunt, because other services or applications including web browsers do not.

2) a small number of tools can normalize data. You've mentioned Dreamweaver already. SC Unipad can convert data. SIL produce an encoding converter called TECKit which can be used to normalize a Microsoft Word document. If you use Perl, ASP, ASP.Net. VB.Net, Python there are ways of doing it as well.

Ultimately, there needs to be a guide containing information on web development issues when the content is in African languages.

Most tutorials and books on web development are from a anglocentric or eurocentric perspective, and rarely touch web internationalization issues.

Its rare to find a book or tutorial on creating web sites that mentions the word normalization, or why its important or critical for some languages.

Andrew

Edited by author 11-03-2005 10:01 AM
The question I am asked to answer is: Is there a direct relationship between the text input using a specific input device and the text displayed in an application?

(E.g. if you use one keyboard to type “Ẹ” it may look different using another keyboard)

My answer is: NO!

This is like asking a person, how do you cook Ọgbọnọ with goat meat? Of course, you cannot, but you can use goat meat as part of the ingredients in Ọgbọnọ, if you want.

Please follow the roadmap to my answer.

1. Input Device, most common input device is the keyboard and mouse and I will reference keyboard in the physical and virtual sense. The keyboard is an input device and nothing more. When a user presses a key on the keyboard, the keyboard sends a scan code digit to the attached computer’s operating system (“OS”) (e.g. user presses key with letter U on the keyboard and let say the scan code for the key is 0xx44)

2. Operating System, when the OS receives the scan code from the keyboard, it will use the corresponding keyboard driver, which usually includes a keyboard layout mapping, to translate the scan code. The translated value can either be Hex or Unicode. (E.g. the Unicode value for Latin small letter “u” is U+075 and the Hex value is 0x75)

So, if the keyboard layout mapping was done in Unicode, the OS will translate the scan code 0xx44 to mean U+075 (I assume here that we are only dealing with Unicode compliant OS and I will not delve into codepages) The OS, now sends the new code to the opened software application. (E.g. MS Word, WordPerfect, FrontPage, PageMaker, Dreamweaver, etc)

3. Applications, all applications use fonts to render and display text values received from the OS. When an application receives a text value from the OS (in this case U+075) it will use the active font available to render and display the glyph representing the text value received, if an application does not recognize the text value, it will return a “?” mark value to the font for display. In this case the glyph for U+075 is “u” and if the font does not recognize the text value it will display a box.

That in short version is the roadmap from text input by a keyboard to text display by an application.

I answer the question to address Andrew’s frequent reference to “what an output a keyboard layout generates…” The answer is it depends on the OS, the application and font in use.

The main issue of character normalization and NFC or NFD is purely application to internet browser relations and has no direct relevance to the type of input device used.

Example: Dreamweaver web development application is fully Unicode compatible and it will properly display both precomposed and combining characters, but developers have to know to set the preferences specifically for internet browsers. Also, web developers have to do additional scripting to account for disparate treatment of text values by all the internet browsers. (My text example “u” is U+075 in Unicode, 0x75 in HEX and u in HTML(hex)) Most browsers use language codepages to support text translation, but most extended Latin characters are not contained in any codepage. This will be also be true for combining diacritics, so while browsers like Explorer can handle combining glyphs, Firefox cannot. A smart web developer has to write scripts to account for Firefox web browser shortcomings (normalization of text display across internet browsers). The answer to this problem is standardization under Unicode, if all the browsers a fully Unicode compliant, I think the problem will go away. (Not an expert in this area)

In conclusion, I say the action between an input text and what is displayed in the application or internet browser is not directly related to the keyboard used. Users will always get what the keyboard layout is mapped to give the application, what a user sees in the application is a different matter. (See NITDA)

Adé G. Oyegbọla
Co-President/CEO
Lagos Analysis Corporation
http://www.lancorltd.com

Edited by author 11-03-2005 06:25 AM
Andrew, /m181

We at KỌNYIN do not mind the constructive criticism of our product, in fact we welcome it, that is why we seek out knowledgeable people from linguists to software developers to website developers and media publication houses and offer complimentary copies of the product for their review and critic.

We are currently on the 4th version of the keyboard (7 years in the making) and most improvements were achieved because of the input we received from people. Don't get me wrong we have a load of experienced software engineers in-house, not to sell them short. LANCOR Technologies is a Boston, USA based company with extensive R&D portfolio. KỌNYIN Multilingual keyboard is only one of our products. (http://www.lancorltd.com/Konyin.html)

KỌNYIN Multilingual keyboard is fully compatible with Microsoft Windows 2000 or above, we just received the compatibility test result for Vista (Longhorn).

The physical keyboard is a perfect standard QWERTY keyboard without installing the driver. So that should answer your question about functionality. It is a complete plug and play standard keyboard.

When you install the driver, the "Ng" keys on the keyboard is activated and they function as perfect "make/brake" shift keys.

The keyboard uses Unicode standards for handling fonts and allows both precomposed and combining glyphs. The keyboard driver is completely font independent. The keyboard layouts are generated by proprietary DDK that mirrors MSKLC but incorporates 4 shift key functions.

If you have Adé’s email, you can send him a message about getting a complimentary copy, I am sure he will authorize one out to you.

KỌNYIN

Dear KONYIN,

re /m179

I'm not attacking your product. All I'm doing is expressing curisoity about how it functions.

It is true I have not purchased a copy. Generally, before I buy a product I like to know how it will behave and interact with the other applications that I use. Some Unicode porgrams will take input from Microsoft keyboard layouts put not work correctly with third party products. Some keyboard drivers i've tried in the past conflict with IMEs or input softwrae that I need to work with regualarly, In our projects we deal with over a hundred languages from all parts of the world.

if your keyboard layouts are generated by MSKLC then there wouldn't be a problem. If they're custom .. then ..

I acknowledge that my knowledge of keyboard drivers and their technologies ahve gaps, but the issue of what character sequences are generated by the keyboard in an application, whether those character sequences are normailized (i.e. NFC or NFD or something else), how the character sequences impact on developing web services, building in normalization routines, collation, searching, indexing, etc, how i impacts on the use of editing and proofing tools are all important issues.

For European and East Asian languages which dominate the IT and web development industries, these are not important issues, because keyboard layouts or IMEs will generate fully precomposed character sequences, rather than combining character sequences.

Languages that have a strong web presence and have competing character sequence models are indicative of the problems that will face languages like Igbo as they become more prevalent on the web.

Personally, I feel people should use any keyboard that they want. A physical keyboard solution is better for most people than just a software solution. US style keyboards can be very limiting.

What I am interested in is how the shift to unicode input systems will impact on software and web development.

re /m180

I had a look through my email archive for the past couple of years and saw a number of emails that I had recieved from Adé, but was unable to locate one regarding a complimentary copy of KỌNYIN. I assume that either the message got caught in my isp;s spam filters. A problem I have with some emails, most notably if they do not have 7-bit clean headers.

Andrew

Andrew,

I just had a chat with Adé now and he indicated to me that you were included in a private email to submit your mailing address to receive a complimetary copy of KỌNYIN Nigeria Multilingual Keyboard. But that you did not responde to the email.

So I wonder, what is your point?

KỌNYIN

Edited by author 11-02-2005 09:35 PM
Response to Andrew /m178

I will call your attention to Adé’s posting at http://www.quicktopic.com/15/H/KKgbRqJUAR8 posting /m213 in that posting Adé asks “Why don't you get a copy of the keyboard to find out, test it and report your experience to all.”

1. Do you have a copy of any version of KỌNYIN Multilingual keyboard?
2. Have you used the keyboard under any of the conditions you described?

If your answer is no to these 2 questions, and I think it will be, cause I cannot find any record of a sale or complimentary copy sent to you. Then I think, for lack of a better word, you are full…

I really respect your knowledge of the issues relating to characters for native languages and suggested solutions to website development issues. But when it comes to the technology developments of input devices and outputs in the Unicode environment, I think you need to brush up. I will not engage in discussing the technology behind KỌNYIN with you based on your ignorant questions. Like Adé said, get one and find out.

If you want to know, KỌNYIN keyboard driver has even been tested on the Microsoft Vista beta and found to be fully compatible.

At this point I think I will bid this forum goodbye, it does not seem to be serving the interest of people looking for information on current development on Ěgbo language computing anymore.

Ndeewo nụ

KỌNYIN

Hi Chinedu and KONYIN,

re /m177 and /m176

I'm not concerned about what physical keyboards or drivers or keyboard layouts people use. They can use whichever solution they feel appropriate. But they do need to be aware of the issues involved.

In the case of KONYIN, KONYIN's approach is interesting, but like most Igbo/Nigerian input projects, KONYIN doesn't give any idea of what output their keyboard layout generates.

Will the KONYIN keyboard work with other drivers or only with KONYIN's? How flexible is it as just a physical keyboard if decoupled form the keyboard driver. Partly this would depend on what scan codes their unique keys are using and if those scan codes are published allowing someone to create an alternative driver for it.

Just some proactical issues relating to keyboards and why I think that the characters generated by a keyboard layout is important when using applications and using the Internet.

I'll use Vietnamese as an example, since there is a lot of Vietnamese content on the internet and keyboard layout wise it suffers form similar problems to Igbo and other Nigerian languages when tones are used.

Unlike Nigerian languages (using tones), each character and tone combination used by Vietnamese exists as single characters in Unicode. Most keyboards would generate these precomp[osed characters. I've actually used one Vietnamese IME (WinVnKey) to type in Igbo.

Microsoft introduced Vietnamese support in the English version of Windows 2000. Due to the way Microsoft creates keyboard drivers, their driver could not generate Vietnamese in fully precomposed characters. So instead they use precomposed characters for distinct vowels (this includes the diacritics breve, circu,flex and side-hook) and use combining diacritics for tone markers (acute, grave, tilde, hook above, and dot below).

So a third-party (non microsoft) IME would type "o-circuflex-acute" (U+1ed1). Microsoft's keyboard layout will type "o-circumflex and combining acute" (U+00f4 U+0301).

Microsoft also added proofing tools like a Vietnamese spell checker in MS Office. If you type in vietnamese using Microsoft's keyboard layout, then the spell checker will work. If you use one of the third-party IMEs in precomposed mode, you will not be able to spell check, since the character sequences in the spell checker would not match the character sequences you were typing.

If an Igbo spell checker was developed for MS Word (and supported Igbo with tones) then which keyboard you could use or could not use would be a big issue. If you used the wrong igbo keyboard layout you would not be able to use the spell checker.

Searching for Vietnamese Unicode websites using Google is problematic. Google doesn't normalize their data. If you search google using a Vietnamese third party IME (using precomposed characters) then you will find websites that were written using precomposed characters. If you search using Microsoft's keyboard layout, you will only find websites written with that keyboard layout. The two sets of search results will be different. To tey to find a unicode website, in Google you'd need to do the search twice.

Similar issue with BBC website. If you search using precomposed characters, you'll find old Vietnamese articles only. If you search using Microsoft's keyboard layout you will only find the newer articles.

If you develop a Igbo language web servie it will be necessary to compensate for all the varied keyboar layouts since they will produce a range of outputs, precomposed, decomposed or some hybrid, and in the case of NITDA invalid character sequences.

The other issues that are linked to keyboards but aren't directly related to keyboards: fonts and minimum operating systems.

If you are typing in Igbo (without tones) there are a range of fonts you can use. For operating systems, Windows 2000 onwards is bets, although its possible to get Unicode input working to various degrees with a limited number of applications on older versions of Windows.

If you need to type Igbo with tones, then you need to use MS Office 2003, or any unscribe aware program on Windows XP (Service Pack 2). Fonts are very limited. There are only a couple of fonts currently available, and none available from Micrsoft.

The next version of Windows (Windows Vista) should ship with fonts suitable for Igbo with tones.

As i said earlier, doesn't matter what keyboard layout you use for Igbo. Just be aware of the issues relating to the relative strengths and weaknesses of your choice. There are benefits to using a physical keyboard or keyboard skins developed for Igbo. Makes typing easier initially. But irregardless of what layyout or driver oyu use, awareness of what character sequences are generated will be increasingly important when using Igbo based web services as they develop in the future.

Just my two cents worth.

Andrew