Bonsoir Sophie (23h ici),
Sur Mac, les polices des langues inclues dans le système sont
présentes par défaut. OSX est une "distribution" multilingue qui
propose une petite vingtaine langues d'interface, avec les
systèmes d'entrées correspondants les encodages etc. En gros il
n'y a pas une version "japonaise" une version "française" etc.
Ok, cela ne veut pas dire pour autant que OOo sait qu'elles sont
présentes.
OSX a des fontes dans 3 emplacements à priori (notations unix):
polices système:
/System/Library/Fonts
polices supplémentaires accessibles à tous les utilisateurs:
/Library/Fonts
polices utilisateur:
~/Library/Fonts
Les polices dont je parle (Osaka et Hiragino) sont toutes deux des
polices système. Les polices DTP sont des fontes supplémentaires.
Elles apparaissent ou pas dans la liste des polices OOo ? Hiragino
est-ce différent de Hiragana (juste pour ma culture perso ;) ? Est-
ce que tu ne peux utiliser la table de remplacement pour fixer la
bonne police ?
Les polices Hiragino (6) et peut–être d'autres n'apparaissent pas
dans le menu polices accessible à partir de la fenêtre du document,
et n'apparaissent pas non plus dans les paramètres accessibles à
partir de Format>Characters.
Hiragino est une police qui couvre la plupart des caractères japonais
et donc pas exclusivement les 50 et quelques hiragana (je dis et
quelques pour ajouter les variations). Je n'ai pas trouvé de
références précises sur le web, mais la police doit contenir _au
moins_ 3000 caractères.
En consultant la table de remplacement j'ai aussi remarqué la chose
suivante:
les polices décrites en caractères sino-japonais présentes dans /
Système/Library/Fonts et dans /Library/Fonts ne sont pas accessibles
dans OOo (Osaka est décrite en alphabet et est présente) et les
polices présentes dans ~/Library/Fonts sont toutes présentes même
celles décrites en caractères sino-japonais...
Mais ce n'est pas concluant parce que les fontes DFP sont
présentes dans OOo avec leur nom anglais, alors qu'elles sont
décrites en japonais dans TextEdit lancé en japonais... hummm...
Je comprends que pour un problème de localisation ça puisse être
génant, mais le nom ne doit pas interférer sur l'utilisation ?
Non, mais un japonais va plus souvent utiliser des polices japonaises
avec une description japonaise donc si cette description existe (et
elle existe puisque OSX l'utilise) OOo pourrait utiliser la
description qui correspond à la variable d'environnement, mais pour
le moment c'est un détail.
Bon, on va voir avec les collègues de ma zone horaire...
oui, imho ils auront surement plus d'expérience que nous, mais la
réponse m'intéresse pour faire une entrée FAQ pour les utilisateurs
qui rencontreraient les mêmes difficultés. Sporadiquement, il
m'arrive d'avoir de telles demandes.
En tout cas, comme je viens de remarquer plus haut il y a un problème
au niveau des fontes accessibles à travers le système dans leurs deux
emplacements possibles. Fondu qui bloque ?
PS: [OT] merci pour tes retours sur la liste traduc :)
je t'en prie, c'est le seul truc que je me considère capable de
faire :) des commentaires sur les listes de traduction ;)
Tu as permis de nous relancer sur un projet que nous avons mis en
place aux rencontres mondiales l'an passé et sur lequel nous avons
du mal à trouver le temps d'avancer.
J'avais dans l'idée de proposer une présentation mais comme j'ai vu
que Ale semblait avoir fait un truc très similaire l'an dernier j'ai
laissé tombé. Mais je suis toujours dispo pour ce domaine. Si il y a
des trucs à faire, il y a une réelle expertise qui est en train de se
créer dans le monde de la traduction autour de OmegaT et
implicitement de OOo (en bientôt ODF de manière indépendante peut-être)
Jean-Christophe
ps: à propos de traduction, j'avais envisagé d'organiser un mini
atelier à Lyon pendant la période de la conf OOo pour faire se
rencontrer les 20 personnes qui sont actives pour le développement
de OmegaT et d'autres personnes qui veulent participer mais
septembre n'a pas été considéré comme la meilleure option par ceux
qui songeaient se déplacer. Donc on a opté pour les rencontres
Lyonnaises du libre en octobre, je viens de confirmer la
réservation de mon billet d'avion, et j'aimerai bien pouvoir
rencontrer des gens de OOo impliqués dans la traduction pour voir
quelles sont les améliorations à apporter du point de vue "OOo/ODF
pur", vu que ce que la plupart d'entre nous, traducteur, faisons
ce sont des trads de documents convertis, donc n'utilisant pas
forcément toutes les fonctions de OOo/ODF.
Je ne sais pas s'il y a beaucoup de traducteurs sur la liste, tu
pourras peut-être faire un appel sur la liste [EMAIL PROTECTED] peu de temps
avant les JLL. En tout cas tu rencontreras des membres du projet
francophone puisque nous aurons sûrement un stand sur place.
Super ! Mes premier utilisateurs français de OOo ;)
Pour boucler cette histoire, depuis janvier je travaille beaucoup
avec l'équipe OOo-ja, pas que par mail, et j'ai commencé à faire
ma tournée des agences de traductions pour leur montrer les
bénéfices liées à l'utilisation d'outils libres, dans mon "monde"
à moi ça veut dire en gros OOo+OmegaT. Ca commence à prendre mais
j'ai bien conscience qu'il nous reste un certain nombre de
problèmes pour pouvoir supporter intégralement l'intégration à un
milieu de travail centré sur OOo. Si vous avez des idées de votre
coté je suis preneur.
Tu dois rencontrer les mêmes résistances que celles que nous
rencontrons à chaque migration. Il serait peut-être intéressant de
connaître les problèmes dont tu parles pour essayer des mutualiser
des réponses, si elles sont possibles.
En fait oui et non. La migration fait clairement gagner de l'argent
au freelance _et_ aux agences.
Les freelances parce que OOo/ODF leur permet d'utiliser un outil
gratuit/libre qui augmente de manière très sensible leur
productivité. Un exemple concret: j'avais 35 pages de tables dans
Word à traduire en 4 jours la semaine dernière, avec quantité de
répétitions. L'agence n'étant pas capable de donnée une estimation
précise elle me propose un tarif approximatif, 90,000 yen pour 12000
caractères, mais la traduction du document dans OmegaT (après passage
à ODF grâce à OOo) me montre que le document ne contient que 6000
segments uniques, tout le reste n'étant que répétitions. Donc je suis
en fait payé 90,000 yen pour 6000 caractères que je peux aisément
boucler en 2 jours.
Du coté de l'agence. Si elle analysait le projet à ma manière, mais
sachant qu'elle n'a pas les moyens de pré-traduire le texte, elle
peut me proposer un tarif basé sur 9000 signes par ex, facturer 12000
au client qui ne fait aucun travail de gestion de son patrimoine
textuel et au final lui garantit une meilleur qualité vu que la
différence de 3000 signes peut servir à payer un relecteur où à
d'autres investissements.
Quand aux client finaux, ils sont réticents à changer d'outils non
pas à cause des coûts etc, mais tout simplement parce qu'ils ne se
sont jamais posé la question de la valeur de leur patrimoine texte.
Et qu'ils ont un budget traduction.
Les outils qui fonctionnent directement sur les formats MSO sont
coûteux. J'ai fait une présentation dans une agence spécialisée dans
la traduction de brevets il y a 2 semaines et ils ont un poste
"administratif" qui crée les mémoires de traduction pour référence
visuelle (ouptut en format texte bilingue) et pré-traduit les textes
avec un outil (Trados freelance) qui coûte autour de 200,000 yens.
Les traducteurs (5) travaillent dans Word sans outils spécifique, sur
le document pré-traduit (qui sera par la suite de nouveau travaillé
pour créer une mémoire de traduction etc) avec à coté la traduction
de référence en visuel.
Le passage à ODF/OmegaT leur permet d'importer la TM Trados
automatiquement, de créer leur propre TM et d'en bénéficier
automatiquement en direct pendant le processus même. Les glossaires
pré-créés sont aussi utilisables etc.
Une fois les bénéfices de la migration expliqués avec les chiffres à
l'appui, en général les responsables tombent sur les fesses et se
demandent comment ils ont pu passer à coté de quelque chose d'aussi
bien pendant aussi longtemps. Bon c'est vrai qu'on s'améliore de
jours en jours, mais je pense que les efforts des autres équipes
"libres" ont aussi contribué à la diffusion de OmegaT en japonais (le
tutoriel a eté traduit par une des personnes qui écrit le plus de
livres d'introduction à OOo ici, Yutaka Kachi avec lequel tu as peut-
être déjà échangé, M. Hirano est très présent aussi, des gens de
Mozilla ont bossé sur l'interface utilisateur etc.)
Pour info, on est en train de travailler sur la prochaine version
de OmegaT qui devrait corriger l'intégralité des problèmes
découverts dans le traitement des fichiers OOo. Sortie en août-
septembre.
Bon courage :) Pour info, tu devrais peut-être aussi cibler les
Rencontres Mondiales du LL qui seront à Amiens l'année prochaine.
Il y a un thème documentation/internationalisation dans lequel
OmegaT et vos problématiques auraient tout à fait leur place.
Muriel Shan Sei Fan (éditrice et traductrice) était responsable du
thème cette année, je l'étais l'an passé et ni l'une ni l'autre
n'avons fait de track outils mais je pense que cela pourrait être
pertinent d'associer méthodologie et outils, à la fois pour la doc
technique et l'i18n.
Ca tombe bien, je ne connais pas Amiens :) Mais en regardant sur le
site de Muriel, j'ai vu que Thomas Huriaux a présenté Debian et il se
trouve que c'est Thomas qui a crée le filtre PO pour OmegaT :) Et que
Muriel est assistante dans ma fac d'origine :) Du beau monde :) Ce
sont les gens de la section chinois qui m'ont convaincu d'abandonner
les math en DEUG pour le japonais...
Et à propos de doc technique, j'ai une deadline pour demain matin...
Bonne fin de week-end.
Jean-Christophe
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
