[sword-devel] ICU and internationalization in sword

[Martin Gruner]

This would make sword unusable on Handhelds for non-Roman languages. There 
must be a better way. 
I don't know too much about ICU. Is it possible only to extract the 
functionality you want, say, by static linking? For example, would the 
toupper functionality really blow up the api so bad that it cannot be used on 
handhelds? 
I agree that there are things that should be optional like transliteration, 
but I consider locales and search stuff integral parts of the sword api which 
should function well on all platforms. And I do not consider the roman-script 
world the main target for sword. The index-based search could be optional as 
well since it requires additonal disk space.
That does not mean we have to use ICU to accomplish these tasks. Maybe there 
are third ways, such as a handcoded toupper function with an extended array?

Martin

Am Dienstag, 1. Oktober 2002 09:46 schrieb Troy A. Griffitts:
> My position on ICU:
>
> We use it in the engine.  It is never exposed in the engine and is
> always optional.
>
> For example, we have a utf8_toupper function in the api that does it's
> best to change a utf8 string to uppercase.  If the api is configured to
> use icu, it does a much better job for non-roman script languages.
>
> If you don't configure the api with unicode, the engine will not present
> options to the user for transliteration, which also uses the icu library.
>
> I don't have a problem using the icu library where necessary.  And if
> there is anything that we want to support for which icu already includes
> rich support, then I think we should use it.
>
> I am not willing to make a dependency on icu.  We are not required to do
> so.  With good design, we can take complete advantage of it's benefits,
> and still provide acceptable roman script functionality without it.  The
> 16 megs of flash memory in the zaurus and ipac will not allow it.
>
> To use icu for your search problem, you may, for example, if you NEED
> functionality for word breaks that icu provides you, add a function to
> our string utilities called:
>
> const char *utf8_getNextWordStart(const char *buf) {
> #ifndef _ICU_
>    return strtok(buf, " ");  // well, basically
> #else
>    // do some fancy icu calls
>    // to let it determine next word break
>    // and return result.
> #endif
> }
>
> I think if you investigate further, you will find that icu really
> doesn't give you much language-specific word break support.  Does it
> work on Chinese?
>
> 	Do you have any other reason you would like to force a dependency?
>
> 	-Troy.
>
> Martin Gruner wrote:
> > I agree with Joel. ICU dependancy is the price we have to pay for clean
> > Unicode support. We also will need it for the locale handling (toupper).
> >
> > Martin
> >
> > Am Dienstag, 1. Oktober 2002 00:40 schrieb Joel Mawhorter:
> >>Hi all,
> >>
> >>I'm writting to get reactions to the idea of making sword dependent on
> >> ICU. Currently we only have optional dependencies on ICU (at least for
> >> transliteration but I'm not sure what else). I would like to suggest
> >> making ICU required for sword. The reason I would like to see this
> >> happen is that I would like to use functionality in ICU in the searching
> >> and indexing code (and probably other things in the future). Dealing
> >> with strings in a language specific way is far from trivial for many
> >> operations. For example, doing a search for whole words only (e.g.
> >> searching for God doesn't return godly) isn't too hard just for English
> >> but to do this for all languages that are or can be supported by sword
> >> requires a lot of special logic since punctuation and even the concept
> >> of what a word is vary so much from language to language. Either we can
> >> use thirdy party code to do this or someone else or I can write this
> >> specially for sword. I can't speak for others but I think that if I had
> >> to write code like this it would likely not be as good as the ICU
> >> implementation is. Another example of something we need is case
> >> insensitive searching. Currently this is done with stristr() wich only
> >> handles ASCII. ICU allows this for any language supported by Unicode. I
> >> have already concluded that index creation will need to depend on ICU
> >> since the hardest part of indexing is breaking up a text into words
> >> which is different from language to langauge.
> >>
> >>Since ICU is well designed (IMO), open source, cross platform and
> >> contains about everything you could think of for Unicode string
> >> handling, the only downside I can see to requiring it is the added size
> >> requirements for the ICU libraries. The default build of the three main
> >> ICU 2.2 libraries on my machine total about 14 MB and they gzip to about
> >> 5.5 MB. For most platforms this is not a siginificant size increase.
> >> Even downloading over a modem, this doesn't add too much download time.
> >> For platforms where size is a significant issue, sword could be
> >> statically linked against ICU so that we only linked in the parts of ICU
> >> that we needed.
> >>
> >>I think that if we want to eventually have really good support for
> >>non-Latin based languages in sword we will at some point have to start
> >>using a library like ICU. I would rather do that now so that I don't have
> >>to write a bunch of code for searching that I will just throw out later.
> >>Another advantage of requiring ICU is that the front ends can start using
> >>it as well for internationalization of the user interfaces. What do you
> >> all think about this, especially regarding the advantages and
> >> disadvantages? Obviously Troy has the final say on this one but I
> >> thought a open discussion on this would be good.
> >>
> >>In Christ,
> >>
> >>Joel Mawhorter