I18n again (oh no, not that guy again!)

I18n again (oh no, not that guy again!)

[Benoit de Boursetty]

	Hi,

	This message first announces a webpage in French for the two
*very*little* tools that I have written recently in OCaML:
 - a library for raw PPM/PGM image files I/O
 - a parser and pretty-printer for O'CaML with keywords in French.
	Both are available at:
http://www.stud.enst.fr/~debourse/caml_fr.html (French)
http://www.stud.enst.fr/~debourse/caml.html

	Collisions between keywords and user-defined bindings may occur
during translations. An escape mechanism exists for printing (a value
called "let" will be printed out as "let__"). Currently, no unescape
mechanism exists (the __ tail is not removed) for parsing.

	Second, I must acknowledge that what I did, localizing the O'CaML
parser for the French language, is not very useful because keywords are
not really English, they are symbols that are used verbosely in every
country. Like, one could say, the sum character (cap. sigma) in math is
not really Greek, and certainly nobody wants to write sums with a Roman
"S". (*)

	However, it seems to me everybody likes to have identifiers in
their native language. And whenever you find you have done something
valuable and want to share it with the community, you start translating
identifiers / type constructors / etc. that appear in the interface. But
if it has already occured to you, you must know it's not really simple:
you also have to translate *every occurence* of such identifiers /... in
your implementation file. And if you want to give away the compiled module
but not the source, you must do the translation work alone.

	Most modern GUI toolkits allow localization. Well, my point is
that the 'I' in GUI stands for Interface, so a modern module Interface
should also provide the same functionality. Like for GUIs, localizing
wouldn't require that translaters have the code of the implementation. I
don't know how to do it best, but don't you think it could be useful?
Haven't some people here experienced the painful search/replace loops when
translating a piece of code?

	Best regards

	Benoît de Boursetty.




(*)
...and this was one of P. Weis' contradictions to my proposition.

	Still, I have noticed that all of the French profs in CS whom I
had the priviledge to learn from are *very much* used to writing
algorithms in what is called "pseudo-code" at board. The only difference
with O'CaML code being only that keywords are in French... So with the
parser I wrote they'd be able to write almost direct "pseudo-code" into
O'CaML.

	So there's a little paradox: we use a "globally consensual"
language for math expressions and nobody feels like using another one; but
we also use "pseudo-code" for algorithms, which is generally just a
translation of the original keywords from English to the native language.
Maybe because math expressions are rather graphical and abstract, so that
you understand them directly in your language, whereas when you see
"while" written somewhere, you read it in English first.

---

Re: I18n again (oh no, not that guy again!)

[Benoit de Boursetty]

	Bonjour,

--- (English below)

> Je constate que les connectives logiques (or, and, not) ne sont pas
> traduites en francais (lorsqu'elles sont ecrites en toutes lettres,
> bien sur, et non sous leur forme ||, &&). Est-ce voulu, ou est-ce un
> oubli ?
> 
> C'est un peu dommage de lire 
> 
>   si l = 0 or dirname.[l - 1] = '/' alors dirname ^ filename
>   sinon dirname ^ "/" ^ filename
> 
> au lieu de
> 
>   si l = 0 ou dirname.[l - 1] ...

	Les connecteurs or, and et not sont definis dans le module
Pervasives.

	A mon avis, donc, le probleme que tu souleves, et je suis
tout-a-fait d'accord avec toi, est plus le manque d'une interface de
modules multilingue, qu'une omission dans la localisation du parseur :
c'etait bien d'ailleurs le sens de mon precedent message.

---

> [In your French syntax of O'CaML, the keywords "and", "or", "not" are
>  not translated.]

	These "keywords" are only defined in the Pervasives module.

	Thus I think the problem you raise, and I agree with you, is more
the lack of a multilingual module interface than a miss in the parser
localization: this was what I meant in my previous message.

Best regards / cordialement,

Benoit de Boursetty.