[sword-devel] Re: sword-devel Digest, Vol 19, Issue 30

[DM Smith]

I cut my teeth on C++, as a teacher's aide to it and other OO languages 
at the University of Pittsburgh. In the early days, I compiled C++ 1.0, 
2.0 and 3.0 for various unix architectures and found and fixed bugs in 
these implementations. In those early days I also wrote a significant 
set of core classes (string, stack, queue, lists, and the like) as there 
was nothing available. In those days there was no support for multibyte 
character sets in the language.

The problem of "rolling your own" is that of cost. With everyone wanting 
to create their own base set of classes arguing that it met their 
projects specific needs, it left the large company, for which I worked,  
in the untenable situation of retraining very competent C++ programmers 
when re-assigning them to new projects. By standardizing on a few core 
infrastructures, starting with those created in house and later 
migrating to those created by 3rd parties and recognized as "industry 
standard", the company was able to realize shorter project schedules, 
increased software reliability and greater reuse of code and, very 
importantly, of developers.

I think that C++ as a supported language has come a long way and there 
is a robustness of 3rd party add ons which address many, perhaps most or 
all, of the missing features needed for enterprise programming. But it 
seems that there is still a need for industry standardization, such as 
in GUI toolkits. I would like to see the day that a Sword GUI runs on 
Windows, Mac and Linux using the platform's look and feel. I think that 
day is coming with the efforts posted here.

The problem of i18n and l10n is that it is non-trivial. Using a solution 
that is complete and "industry standard" will help all 
internationalized/localized programs to be complete. It does not make 
sense to me for anyone to re-invent the wheel, especially when you can 
get a top of the line wheel for free.

With regard to this and this thread, IBM's ICU4C has support for 
ResourceBundles.
(see: http://icu.sourceforge.net/userguide/localizing.html)

David Blue (Mailing List Addy) wrote:

>On Tuesday 01 November 2005 07:39 am, DM Smith wrote:
>  
>
>>C++ does not support internationalization or localization. It is an
>>afterthought at best.
>>    
>>
>
>>From the design point of view of a language, i18n should be an after thought 
>unless you have built in strings (and even in java they're a class) with the 
>exception of making sure your character types are able to hold Unicode bytes 
>instead of just ASCII. Also I can think of at least two good tool 
>kits/libraries for doing localization and internationalization of programs. 
>gettext which lots of gtk (straight C) based programs use, and qt's (C++) 
>built in internationalization stuff. So there *is* support, it's not not 
>necessarily wide spread because I'm not sure how windows handles it. But in 
>terms of i18n or being able to internationalize or localize a program that 
>should be up to the programmer on how to do it, not the language since 
>different programs have different needs.
>