Talk:International Components for Unicode

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Software  
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 ???  This article has not yet received a rating on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Software.
 

October 2006[edit]

I've just expanded the article a little and made some corrections. I used 2 sources not referenced in the article:

At one stage, IBM sold a C++ kit called the "Taligent Internationalization Library". I don't know if this came from CommonPoint, or was an early name for ICU4C.

Perhaps the article should mention a major design difference between ICU and C locales? In ICU, locales are just labels that a program can use to load an appropriate formatter, date converter, string bundle, etc. In C, locales carry all the locale-specific information with them, so one setlocale() call can change all locale-related settings.

Cheers, CWC(talk) 07:42, 15 October 2006 (UTC)

Neutrality[edit]

User Hdante (talk · contribs) has tagged the article with Template:POV-check for the words "much richer", in the sentence

ICU provides much richer internationalization facilities than the standard libraries for C or C++, and most operating systems.

Being richer than standard C or C++ is quite easy. Being richer than "standard Unix" isn't much harder.

Presumably Hdante is concerned that ICU is not "much richer" than operating systems such as Windows (see Uniscribe) and OS X (see ATSUI). Note that Uniscribe and ATSUI both provide rendering, whereas ICU does not. Can someone familiar with Uniscribe and ATSUI tell us how they compare to ICU for text processing? Cheers, CWC(talk) 03:10, 5 November 2006 (UTC)

The term "richer" is in question!?[edit]

C and C++ have almost no internationalization features when compared to .Net or Java. The POSIX API specification or Unix, which some people confuse to be a part of the C programming language, has some basic internationalization features. Unfortunately, most of the POSIX internationalization framework requires a whole application to use one locale at a time through setlocale instead of allowing multiple locales in use for a multithreaded application.

C and C++ do not include or promise the following:

  • A Unicode based regular expression engine in order to handle text in multiple languages
  • Unicode based collation algorithm and language sensitive string searching
  • Handle BiDi issues
  • Handle all Unicode properties needed for proper handling of text in multiple languages
  • Calendars besides the Gregorian calendar
  • An extensive timezone API. The majority of POSIX implementations don't even provide the full Olson timezone ID or rules for the timezone.
  • Promise that Unicode is always available. There are many legacy codepages that are not portable enough to use reliably in source code.
  • ... and many other features.

If you're a pure Windows programmer, it's more difficult to say that ICU has a richer internationalization framework than Windows. Windows has a great internationalization framework integrated into the OS that is available throughout C and C++. Mac OS X also has some great internationalization features, but Mac OS X already uses ICU for many of these features (so it's not a useful point to compare ICU to ICU in this case).

There is a reason why "most" is used in this sentence. There are many other operating systems besides Windows that don't provide good internationalization features without ICU, like Linux, Free BSD, Net BSD, Open BSD, z/OS, i5/OS, Palm OS, Solaris, AIX and many other lesser known operating systems. This is why many companies already use ICU. If ICU didn't have a richer internationalization API than what C/C++ provided, no one would be using it. ICU is used by many companies and open source projects out there.

ICU's layout engine is just a small part of ICU4C.

In general, I agree with CWC's comments.

User:UTF-8 (User:Rursus added by manually examining history: comment was from 08:13, 15 November 2006)

1. Four tildes (~~~~) please!
2. I think "richer" is too vague a phrasing, and too POVvy. I'll change it to "more extensive" or some such. Rursus dixit. (mbork3!) 06:48, 10 June 2011 (UTC)

appears to be a variant[edit]

The cited ICU license is the MIT-X11 license, which for whatever reason appears to be slighted by OSI. It's used by ncurses, e.g., as noted here TEDickey (talk) 01:13, 3 February 2014 (UTC)

Nice page, thanks for the link. At some point in time before 1995 porting PC Curses 1.4 to something with less or at least more interesting bugs and nearer to SVR3.2 was a part of my job; later published as version 3.5.1.1 ;-)
For the purposes of NetRexx MIT and Expat are similar enough: Expat License redirects to the MIT License mess, and commons:Template:Expat is a proper subset of commons:Template:MIT.
If you're confident fix the affected page(s) as you see fit. IANAL, I was worried about "All rights reserved" and about the missing upper case. But apparently that is no problem — the commons template even requires the copyright blurb, and the MIT license article here shows the upper case variant as, well, variant. –Be..anyone (talk) 08:46, 5 February 2014 (UTC)
done TEDickey (talk) 01:41, 6 February 2014 (UTC)