Tim Bray wrote: > I'm with Mr. Roddey. At this point in history, doing extra work or adding > > extra complexity in order to empower people to dodge internationalization > is just not defensible on business, engineering, or ethical grounds. -Tim [JBDP] Well I kind of agree on the moral front: I got really pissed off at the "let them speak English" attitudes that I saw exhibited on comp.std.c. But there is a practical side too: I just don't have a library of routines that perform string-like operations on unsigned shorts -- and my legacy code does not accept strings in the form of arrays of unsigned shorts!
And who's doding internationalization? I'm quite happy to have "UTF8J" strings and (if the need arises) quite happy to write versions of functions like 'strlwr' and 'stricmp' that handle UTF8J. And hey, it's hardly internationalized now: I certainly don't have a routine that does a 'strlwr' on an array of unsigned shorts. But in practice this is unlikely to be an issue: non-ASCII fields will be things like client names and the client comments fields in their requests and these will simply be passed through the system. The problem is not that I am trying to dodge i18n but that I need to have my stuff running now and the world around me does not support i18n. (Still, maybe it will soon...[*]) So, I am not asking to dodge i18n: I am asking for code that will support i18n but will also work with the body of code (including system libraries) that I already have. The key question is how great the extra complexity would be. The impression I get from Dean Roddy's message is that it is more than just a question of changing the typedef for XMLCh and tweaking the input transcoding. I'll stcik with the wrapper classes for now... -- jP -- [*] Things could be worse: in my last job we were still using MSVC 5.1!! This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP, CREDIT SUISSE FIRST BOSTON, and each of their subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity.
