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

[stéphane ducasse]

Si mais c'est pas une question de volonte mais de bras et de gens qui  
veulent aider.
Je pense que les packages en MC seraient l'endroit ideal pour stocker  
les traductions des applications.
Mais il faut le faire et mon assiette est pleine.
Donc bien sur cela vaudrait la peine de discuter et former un groupe  
sur squeak-dev sur le sujet

Stef

On 1 mai 06, at 14:41, nicolas cellier wrote:

> 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
>
> _______________________________________________
> Squeak-fr mailing list
> Squeak-fr at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr