English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Re: localization, internationalization and Caml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 1999-10-25 (15:25)
From: Matías Giovannini <matias@k...>
Subject: Re: localization, internationalization and Caml
skaller wrote:
> Matías Giovannini wrote:
> > Strings can be localized with a package mechanism, à la Java. I don't
> > like hardwired strings in code, they're a maintenance nightmare (not
> > that I always abide by my own rule :-)
>         It doesn't matter what you like (or what I like).

It doesn't, my point is: the functionality for localized strings can be
had, only through an indirect route, as are "string packages".

As an aside, let's keep the tone light, ok?

> > >         Have you ever seen a Japanese program? I have.
> > >         Yes. What ocaml does not provide is a way of encoding
> > > extended characters -- \uXXXX \UXXXXXXXXX in strings, or in identifiers.
> >
> > No need to. Use \HH\LL. Again, what OCaml does is sensible, if crude.
>         Irrelevant. The \u \U escapes are ISO recommended, used in
> C and C++, and must be supported.

Well, OCaml is *not* ISO recommended, is *not* C and it is certainly
*not* C++. Let's learn to live with languages other than ISO-mandated,
ISO-validated, ISO-standardized and whatnot.

In fact, now that I think of it, standardization is driven by market
pressure. If OCaml were a commercial product, I guess things would be
different. But it's not (thank Pete), see below.

> > > > Which makes me think, John, you already have variable-length int arrays.
> > >
> > >         But they're not standard (yet).
> >
> > They are! Don't be put off by its status as "experimental feature".
> > Nat's been around since CamlLight.
>         Oh, I must have misunderstood your comment: Nat is standard,
> I'm using it in Viper, but 'a Varray -- a variable length array of 'a,
> is not.

And it's not going to be, unless someone comes with a sound typing
strategy *and* an efficient implementation for them.

> > Again, anyone can download the source code and modify OCaml to suit his
> > tastes. OCaml's goal is not to be a model of i18n awareness, but a
> > platform for experimenting with types in a functional setting.
>         Ocaml is a tool, it doesn't have a goal. :-)
> Humans have goals. The problem is that the designers of ocaml
> have been too successful: ocaml is so good that other people now
> want to use it, and _their_ goals are important too.

Let me restate it: OCaml is the intellectual property of INRIA,
developed under a specific project (Projet Cristal if I remember
correctly) with very definite goals. The project *has* goals, anything
outside those goals is a gift (what is more, everything falling *within*
those goals already *are* a gift), and must be accepted as that. If
INRIA decides that since OCaml is useful to many many people around the
world and want to make one of its goals to turn OCaml into a platform
for experimenting in the implementation of programming languages with
strong i18n support, well, bring the champagne. In the meantime, we'll
have to build upon what it's there.

Suppose the following scenario: INRIA decides that the MacOS platform is
not nearly significative enough to justify the porting effort, and so it
is dropped. What should I do? Plead, certainly, until I'm told "don't
whine, there's nothing we can do". What would be my options? Use a
Wintel box, or make my own port.

This scenario is not unrealistic: there's no native compiler under
MacOS, and there won't be until someone ports it. I can't do it, the
implementors can't do it, and such is life.

> >It
> > happens that OCaml is open enough, and extensible enough, and efficient
> > enough to make a good i18n effort possible, and that is a tribute to its
> > success as strongly-typed, imperative, fast functional language.
>         I agree. It could easily become a leader in this field,
> since implementing complex stuff is relatively easy in ocaml :-)
> > The implementors have made clear in more than one occasion that they're
> > not interested in making OCaml a standard language (remember the thread
> > "How to convince management?"). But don't take my word for it, ask Pierre.
>         My point was simply that the ISO internationalisation requirements
> are not unreasonable, and that other languages will be doing this work,
> some because they have to, and some because they want to stay part of
> the real world -- and encourage non-English (woops, I mean, non-Latin
> :-)
> clients, who, after all, may well make significant contributions.

Hm. I see your point. I don't necessarily agree, though.

I got your message. I couldn't read it. It was a cryptogram.
-- Laurie Anderson