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

[nicolas cellier]

Le Lundi 01 Mai 2006 13:43, Pascal Grossé a écrit :
> J'ai quelques remarques à faire:
>
> - le fait que la chaîne en anglais serve de clé peut poser de gros
> problèmes lorsqu'il s'agit d'un mot générique utilisé dans plusieurs
> acceptions différentes. Regarder par exemple ce qui se passe pour 'start',
> qui est traduit en 'démarrer la simulation'. Cette traduction est bonne
> pour le premier usage (avec 'où'), mais pas du tout pour les deux suivants.
>
> - la gestion des phrases "construites" n'est pas faite du tout (enfin, pas
> correctement). Voir par exemple la seconde utilisation de 'start', dans
> roundedCornersString. Il y a déjà le problème du mot start, mais surtout:
> que ce passe-t-il pour les langues où le verbe ne se place pas en début de
> phrase (je pense à l'allemand par exemple). Il y a des problèmes similaires
> pour les pluriels aussi. Par exemple, le russe est plus compliqué que le
> français et l'anglais, il n'y a pas que la distinction singulier/pluriel.
> Il en est de même pour d'autres langues "slaves".
> Voir par exemple le forum suivant pour quelques explications plus
> complètes: http://forum.java.sun.com/thread.jspa?threadID=657299&start=0
>
> J'imagine que ces problèmes sont déjà connus, mais quelle est la
> position "officielle" de la communauté squeak ? Rien que le premier
> problème évoqué nécessiterait une refonte complète du système de
> traduction, où on n'utiliserait plus directement les chaînes de caractères
> mais (par exemple) un identifiant qui appellerait la bonne chaîne traduite,
> du moins pour les chaînes ambigües. Le second problème est encore bien plus
> compliqué, voir par exemple la manière dont tout ceci est géré en java
> (tout n'est pas à jeter là-bas):
> http://java.sun.com/docs/books/tutorial/i18n/format/messageFormat.html
>
> Je suis bien conscient que gérer ces problèmes correctement demanderait un
> travail énorme, et pas très sexy, avec en plus une nécessité de
> coordination entre tous les traducteurs au minimum. Y a-t-il déjà eu des
> initiatives en ce sens ?
>
> Pascal

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).

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...

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 
question:
Est-ce qu'il ne serait pas temps de passer la vitesse supérieure en Squeak ?

Nicolas