Multi-Lingual Squeak, Cathedrals, Bazaars and Fallen Cities.

Daniel Vainsencher danielv at netvision.net.il
Sat Mar 1 06:58:13 UTC 2003


Hi Eddie.

I understand your concerns, and in the final analysis, probably agree
multilanguage support is something that should be in the core. However,
we're not at a point where there's anything to do about MLSQ in the
core.

The reason for that is that currently, Yoshiki's work is experimental.
Since no one understands it (AFAIK) but him and Abe-san, nobody else can
maintain it. Until someone goes in and breaks it up into pieces we can
integrate, it'll remain a separate project. Since Yoshiki has stated he
will not have time to do this in the next few months, I called for
anyone interested in helping make this happen to step forward. AFAIK, so
far, no good.

This means that the integration of Yoshiki's work, right now, will have
to wait until he has the time to do it, or someone else shows up with a
serious itch.

Daniel

Edmund Ronald <eronald at cmapx.polytechnique.fr> wrote:
> I plead for Multilingual Squeak (call it MLSQ) to become the responsiblity
> of the core Squeak maintainers. Here's why:           
> 
> 1. MLSQ is important for all of us in non US locales. We would wish all
> Squeak to be locale-agnostic: Any program should run in any locale.
> 
> 2. For MLSQ to be transparent, it should therefore not require the
> programmer to understand any Unicode or other charset or encoding
> esoterica. MLSQ character processing should ideally isolate the programmer
> completely from the specificities of any multi-byte encoding.
> 
> 3. Clearly, MLSQ needs to be designed carefully by specialists familiar
> with multi-byte issues. Reliability from the start is important. Therefore
> a cathedral-like initial design approach, with good documentation by the  
> likes of Oshima-san and Abe-san makes sense, rather than letting 
> mods  accrete as it seems has happened with morphic.
> 
> 4. However, a Multilingual separate distribution (like Nihongo Squeak), or
> a loadable add-on, DO NOT MAKE SENSE. Such a separate package will
> inevitably get out of sync with the current beta, get out of sync with
> newer add-ons, unnoticed bugs will lie dormant, and people will be too
> busy to rewrite their US-centric software to ensure compatibility with
> MLSQ, retroactively, when foreign users demand it.
> 
> 5. If MLSQ is part of the core of every new distribution, any
> incompatibilities of MLSQ with standard tools will become immediately
> apparent. Furthermore, foreign users will immediately notice any issues
> with any new version in their own locales, at the alpha beta and gamma
> stages of each distribution and help nip them in the bud. As all software
> runs in any locale from the start, writers of add-ons will have bugs in
> multi-nationalization communicated to them by foreign beta-testers,
> allowing hackers to fumigate their add-on *before* it reaches maturity.
> 
> Which is why, again, I plead for internationalisation to be considered a
> core feature, to be intended from the start to be handed over to the core
> maintainers.
> 
> Edmund



More information about the Squeak-dev mailing list