[Squeak-fr] Re: Traduction fr: d'autres remarques

[Pascal Grossé]

nicolas cellier wrote:
> Dans les années 90 j'avais utilisé le selecteur #traduire envoyé à un
> String et le Dictionnaire pour mes applications écrites en Smalltalk
> VisualWorks (VW), mais n'était pas satisfait pour les mêmes raisons.
> J'avais aussi des substitutions comme par exemple:
>  'Le fichier $1 n''existe pas' traduireEtSubstituerArg1: fileName.
> 
> Depuis quelques années, VW a choisi d'utiliser un symbole pour entrée dans
> le dictionnaire.
> Il s'agit en fait d'un dictionnaire à 2 niveaux:
>  -1er niveau = symbole de l'application (qu'il appellent catalogID)
>  -2nd niveau = symbole de l'item à traduire
> 
> Ceci permet de réduire le risque de conflits entre applications
> (utilisation d'un même clé de second niveau).

Ça parait une très bonne idée, en effet.

> Ils ont raffiné ce mécanisme de substitution avec des tag <2s> signifie
> insérer le deuxiéme argument (un string) <1p> signifie insérer le résultat
> de printString envoyé au premier argument. Je m'étais amusé à enrichir ce
> mécanisme avec des tags de mise en forme <bold> </bold> etc...

C'est une bonne chose, mais si on veut gérer correctement les pluriels il me
semble que c'est encore insuffisant, on ne peut pas se contenter d'une
simple insertion d'arguments. Je viens de lire la doc VW à ce sujet, je
n'ai pas trouvé d'autres informations.

> Dans les programmes on stocke la clé et une traduction dans une langue par
> défaut, et éventuellement le catalogID (bien que des mécanismes permettent
> pour la plupart des interfaces de définir le catalogID une fois pour
> toutes dans la classe qui gère l'interface de l'application).
> 
> Ensuite, les traductions sont rentrées dans des fichiers texte séparés
> sous la forme: clé = valeur
> L'encodage du fichier peut être défini en entête (pour tous les caractères
> non ASCII).
> Le fait d'avoir des fichiers séparés facilite énormément le travail de
> traduction réparti.
> De plus, inutile d'avoir une image volumineuse contenant les traductions
> de toutes les applications dans toutes les langues...
> Et il y a un sous répertoire par langue avec un fichier par catalogID,
> éventuellement un chemin d'accès multiple vers les dictionnaires de
> traduction ce qui permet de résoudre la modularité.
> Une table d'accès binaire est compilée pour accélérer les accès, et un
> mécanisme de cache en mémoire limite les accès disque.
> 
> Je ne sais pas si il faut reproduire mot à mot la solution VW
> (avantage=solution 100% Smalltalk) où regarder ce qui se fait en dehors de
> Smalltalk (avantage=récupérer des outils existants), mais je me pose la

Je ne suis pas sûr que reprendre telle quelle la solution VW soit possible,
ne serait-ce que pour des problèmes de licence. Mais c'est certainement un
bon point de départ ou d'inspiration.

> question:
> Est-ce qu'il ne serait pas temps de passer la vitesse supérieure en Squeak
> ?

Je viens de fouiller un peu dans les archives de squeak-dev. Le sujet a déjà
été évoqué à plusieurs reprises, notamment par Hilaire il n'y a pas très
longtemps, mais sans aucun succès. J'ai vraiment l'impression que beaucoup
d'anglophones considèrent le système actuel comme suffisant. Et je ne suis
pas certain qu'en remettre une nouvelle couche dans squeak-dev puisse
apporter quelque chose. À moins peut-être que le problème soit exposé par
Alan Kay lui-même :-)

Plus sérieusement, il faudrait peut-être imaginer/créer de notre côté une
infrastructure qui fonctionne et est à la fois souple et robuste (tout un
programme...). Je vais me documenter plus sérieusement pour voir ce qui se
fait ailleurs.

Pascal