Need help please.
Problem:
--------
1. Current library built for unix and supports ASCII characters only.
2. This library must now accept wide characters from Japanese client.
You need to doublebyte enable the library except for the most trivial uses. Doing so is not trivial.
Facts:
------
1. The library does not really evaluate the Japanese characters to make logical decisions.
If the data just passes through, that might be relatively trivial.
We believe base64 encode the character array to avoid any "bad things happening in the code" (such as hitting a null value or other values that could potential cause problems).
Is the (non-Japanese) data already base 64 encoded? If so, why? Why create trouble handling that just to avoid checking for null values? Anyway, if you really aren't going to process the Japanese characters in this library except to pass them thru, then you need to take the Japanese text, base64 encode it, and then pass it to the library the usual way. Then retrieve it the usual way and base64 unencode and voila!
Of course this may just move your questions to other parts of your program, but you haven't asked about those places. without knowing what the application is or what the configuration is except "unix" it is hard to say more.
2. Cannot rewrite library in time allowed and don't really need to based on Fact item #1. Plus, pressure to get product to market is greater than internationalizing the library.
This is probably a guaranteed method to fail in Japan. Japanese users and your Japanese partners if you have them have had many years of experience with bad software form the us that claims to work. They will know how to break it quickly. Then you will learn a hard lesson about doing business with Japanese while not taking heed of the well known requirement for quality.
What I need help with:
----------------------
1. How do I set up an ASCII based unix machine, test application and test environment to send Japanese characters to the library in question.
I see from your web site that the application is likely some sort of encryption device, possibly for email. Having run the Japanese software group at an email company in the past,I can tell you Japanese email is fraught with its own perils under any circumstances.
Without knowing what the actual channel is that you want to pass the text thru, it is hard to say how you will want to test it.
You also have not described the time schedule and why you consider it tight. Is it safe to assume that your plan to counteract any lack of experience and time schedule is to spend money to hire someone who has both?
2. Do I need to create hex input or binary input to represent Japanese characters. Since I'm using a standard keyboard how do we get Japanese characters into the application?
Use the Japanese Input Method Editor supplied with or for the operating system. But that does not guarantee that the data will actually get to the application properly if the application has not been coded to handle it. This is part of internationalizing your code, and now you see why skipping corners during the initial development is coming back to haunt you.
3. What am I not considering here? What gotchas will I come across by not making my library i18nized?
The gotchas are going to fall into the categories of "Won't work" or "Data passes thru ok, but the rest of the application doesn't know how to handle it". OTTOMH, I would watch out for endianness when you base64 encode Japanese multibyte text too. Probably OK, but worth taking a close look at.
Unfortunately, I've never done any i18n or l10n work before so I'm really having trouble figuring out where and how to get started. Any advice is appreciated.
There is no magic bullet here in general. if Zixit values the opportunity in Japan, I would suggest you be open to the offers you are sure to get from experienced folks to assist you. If you don't get any, contact me off-list and I will put you in touch with some.
Barry Caplan
Publisher, www.i18n.com
