Hello,
je suis en train de traduire le fichier po des outils vorbis, et j'ai
quelques soucis que j'aimerais partager avec vous.
En amuse gueule, voici les conventions de traduction que j'ai utilisé. Est
ce que vous trouvez des horreurs dans la liste ?
# chanel = canaux
# chunk = trame (faute de mieux)
# cutpoint = point de césure (utilisé pour l'outil vcut)
# parse = analyse
# playtime = temps d'écoute
# raw …
[View More] = brut (adjectif)
# sample rate = taux d'échantillonnage
Pour cutpoint, je suppose qu'il faut que j'explique. l'outil vcut prend un
ogg et le coupe au point indiqué (style « 3 minutes apres le début »). Point
de coupure était un peu moche, et cette idée de césure m'a plu.
Pour chunk, c'est toujours la galère. Un dico dit « gros morceau » et
l'autre « short, thick piece of anything ». Avec ca, je suis bien. De ce que
j'ai compris du contexte, une piste ogg est coupé en morceaux de taille
fixe, chacun d'eux etant un chunk. Si j'ai raison, il me semble que
l'anlogie avec les trames reseaux tient la route, non ?
Ensuite, je ne sais pas comment traduire bitrate. J'ai l'impression d'avoir
le mot au bout de la langue, mais rien ne vient. Un peu de contexte :
msgid "Avg bitrate: %5.1f"
[...)
" -b, --bitrate Choose a nominal bitrate to encode at. Attempt\n"
" to encode at a bitrate averaging this. Takes an\n"
" argument in kbps.\n"
" -m, --min-bitrate Specify a minimum bitrate (in kbps). Useful for\n"
" encoding for a fixed-size channel.\n"
" -M, --max-bitrate Specify a maximum bitrate in kbps. Useful for\n"
" streaming applications.\n"
" -q, --quality Specify quality between 0 (low) and 10 (high),\n"
" instead of specifying a particular bitrate.\n"
" This is the normal mode of operation.\n"
" Fractional qualities (e.g. 2.75) are permitted\n"
Autre expression qui me résiste, « bits/sample ». J'ai pas d'idée. Juste du
contexte :
msgid "WARNING: Invalid bits/sample specified, assuming 16.\n"
[...]
" -B, --raw-bits=n Set bits/sample for raw input. Default is 16\n"
Je suis preneur de tout indice.
Merci, Mt.
PS: cette traduction a lieu dans le cadre du Translation Project, et on
cherche toujours des volontaires ;)
http://www.iro.umontreal.ca/contrib/po/HTML/
--
Un clavier azerty en vaut deux.
[View Less]
> D'après Thierrry Vedel, chercheur au Cevipof (Sciences po) :
>
> "à long terme, lŽInternet favorise la démocratie car il est un outil
> dŽaccès au savoir et de diffusion des connaissances. Et comme les
> résultats de dimanche lŽont rappelé une fois encore, un niveau
> dŽéducation élevé favorise le rejet des extrémismes, la tolérance,
> lŽacceptation des différences, lŽintérêt pour lŽAutre. "
> http://fr.news.yahoo.com/020426/166/2kg8v.html
>
> Ne peut-on pas …
[View More]dire la même chose du logiciel libre ?
Partage, entraide, liberté, éthique, etc. ça fait partie des arguments que
nous utilisons auprès de l'UNESCO pour obtenir le classement au patrimoine
mondial. Cf http://oumph.free.fr/patrimoine
--
Benoît Sibaud
[View Less]
bonjour,
je suis en train de traduire la RFC OpenPGP
et je rencontre les termes suivants :
String-to-key (S2K) specifiers
3.6.1.1. Simple S2K
3.6.1.2. Salted S2K
la notion de salted me pose problème ....
est ce bien pour dire que c'est complique ?
dans ce cas est il judicieux d'utiliser "compliqué".
je vous remercie
--
_______ __
( O O ) ( ) | ) \_/ .".
--oOOo--( )--oOOo----------------/V\---
Sebastien Person // \\
…
[View More] tel.: 06 70 00 08 95 /( )\
sebastien.person(a)insa-rouen.fr ^'~'^
[View Less]
Bonjour,
David Merill, qui travaille à la nouvelle application de gestion des
documents et des participants du LDP accueille avec plaisir les
volontaires pour réécrire sa maquette Perl en Python. Je vais donc essayer
d'en faire ma dernière action productive en tant que responsable du LDP,
ce qui me permettra d'arrêter la conscience tranquille. Mais comme je vous
l'ai dit, je manque cruellement de temps...
Xavier Antoviaque, Guylhem Aznar et Guillaume Lelarge ont déjà dit qu'ils
pourraient ê…
[View More]tre intéressés (le sont-ils encore ?). S'il y en a d'autres,
qu'ils me contactent. Python est facile à apprendre et je serai toujours
disponible pour répondre aux questions. L'application n'est vraiment pas
difficile à écrire, juste un peu fastidieuse car il y a beaucoup d'écrans
à gérer. Mais si vous n'avez jamais fait d'application web + base de
données, ou si vous croyez que Php-rulez, c'est une bonne occasion de vous
lancer :-)
--
Nicolas Chauvat
http://www.logilab.com - "Mais où est donc Ornicar ?" - LOGILAB, Paris (France)
[View Less]
Voici le "brouillon" du message à envoyer sur la liste lampadas. Comme
précisé précédemment, puisqu'il est sensé représenter nos idées en tant que
groupe, je le présente ici pour relecture et corrections éventuelles.
J'ai essayé autant que possible de condenser les consensus, mais il peut y
avoir des aspects à revoir.
Notez également que l'anglais n'est certainement pas parfait. Donc s'il y a
des choses qui vous choquent trop, n'hésitez pas à corriger aussi...
===
Hello all,
The intent …
[View More]of this mail is to summarise the results of the discussion that
took place in the french mailing-list traduc(a)traduc.org recently, leading the
contributors of the "LDP fr" to discuss needed features and development ideas
for an interface similar to Lampadas.
Now that our two projects are merging, we think that it would be a good idea
to give you the results of our thoughts. The intent is also to start a new
discussion, together, and define what we want Lampadas to be exactly at the
end.
I] The translation process
As traduc.org is today used for translation only purposes, our main
contribution may be on this point.
A] Today
By now, the translation process consists of three steps, involving three
types of users : the translator, the proof-reader(s) and the project
coordinator. As the translator does the main job, he is designed responsible
for his document and also quite naturally the document maintainer.
- the translator choose a document or a new version of a maintained document
is avaible,
- the translator translates or makes the appropriate changes,
- when finished, he announces the document ready for proof-reading on the
mailing-list,
- one or more proof-readers contact the translator and help him correcting
its translation (diffs),
- when satisfied, the final version is submited to the project coordinator,
who publish it if he estimates that enough precautions about its reliability
have been taken. What "enough precautions" is depends of the nature of the
document, and of te number of mistakes found by the proof-readers.
This system works well and for a quite long time now, but it has also proven
its limits : the coordinator has too much work, and very few steps are really
automated.
B] The future
We needed a translation process manager, so we started to discuss the changes
this interface would introduce, as well as what would be automated and what
would not.
Changes :
- There would not be only one project coordinator this time, allowing the
amount of work to be divised among two or three. This also avoids some lack
of responsivness when the coordinator has no or not enough time to spare for
the projet.
- The process could be a little more standardized than before (for the
proof-reading step, mainly), becoming more clear to the newcomers. The exact
rules (numbers of proof-readings needed, exact process of the proof-reading
step) have not being detailed yet.
- A new kind of user could be introduced, similar to your markup assistants,
providing help to the translators having difficulties to pass the
XML/SGML/... validation automation.
What would be automated :
- The registrations of documents, traductions and users.
- The publication of the documents (web, FTP, archives...).
- The translation process. Excluding the points in the "What would not be
automated" section, the interface should automate all the steps; from the
selection of a particular document to its publication approval by one of the
coordinators.
- The interface should include a depository of the changes in a document
(translations, proof-readings, comments), like the one a CVS depository could
provide, but probably in a more user-friendly way.
What would not be automated :
- The discussions between the contributors to the project. The mailing-list
would of course be preserved and a translator would still have to subscribe
to it. The discussions between a translator and his proof-reader(s) could
still be made privately by email; a summary of these discussions could be
attached to the document, for later reference.
- The approval of a publication by a project coordinator; this task is
simplified, but one still has to say "ok" before the document is published.
Some alredy existing tools have been proposed for particular tasks :
- Roundup ( http://roundup.sf.net ) : to track user and proof-readers error
reports.
- MoinMoin ( http://moin.sf.net ) : to reference common traduction problems,
solutions and general help to the translator.
II] The document redaction process
As stated previously, it would be a good idea to allow contributions to the
LDP in any langage, and not just the english -> foreign langages translation
scheme that is actually in use.
But, as we do not have discussed this point further, and that you do have a
good experience on this point, we let you speak first. :-)
And remember that it is just an overview of what we have discussed apart. We
have to start a discussion on this...
--
Xavier.
[View Less]
Au risque de relancer un troll, est-il envisageable de passer la liste en
Reply-to ? Traduc est la seule à laquelle je suis abonné (plus de 20) qui ne
le soit pas.
Cdt,
Jérôme
PJ : le message qui a raté la liste
---------- Message transmis ----------
Subject: Re: [Traduc] pam et nsswitch
Date: Mon, 22 Apr 2002 22:28:19 +0200
From: Jérôme Fenal <jfenalml(a)free.fr>
To: Thierry Vignaud <tvignaud(a)mandrakesoft.com>
Bonsoir,
Le Lundi 22 Avril 2002 09:34, vous avez écrit :
&…
[View More]gt; Fabrice Clerc <clercf(a)wanadoo.fr> writes:
> > Pour PAM: pluggable authentification modules
> > J'ai pensé à modules d'authentification raccordables
>
> plugin est plus ou moins passe dans le langage informatique, alors
> pourquoi pas "plugins d'authentification"
Non !
Plugin est devenu greffon en français et plugiciel en québécois.
« Greffable » n'existant pas, on peut utiliser transplantable, à moins de
vouloir risquer le néologisme.
> > Pour NSS Name Service Switch, j'ai le choix entre
> > Aiguilleur de service de nom et
> > Commutateur de service de nom.
>
> dacodak pour commutateur, ca correspond mieux a la realite qu'aiguiller
Pour moi, ça me va.
Cdt,
Jérôme
--
Jerome Fenal
jfenal AT free.fr
-------------------------------------------------------
--
Jerome Fenal
jfenal AT free.fr
[View Less]
Je ne pense pas être hors sujet en demandant votre avis pour la trad de ces
deux termes
J'ai cherché sans la trouver une traduction existante de ces deux termes à
utiliser.
A ma connaissance, le man de PAM est en attente de traduction, et je n'ai
rien trouvé pour nss.
Pour PAM: pluggable authentification modules
J'ai pensé à modules d'authentification raccordables
En fait, n'étant pas au courant de tout le fonctionnement de PAM, je trouve
que le terme de branchable est assez hideux, et que …
[View More]le mot raccordable
donne un sens de "modularité".
Pour NSS Name Service Switch, j'ai le choix entre
Aiguilleur de service de nom et
Commutateur de service de nom.
Je trouve le terme "aiguilleur" plus élégant que "commutateur" même si pour
les équipements réseau, on dit commutateur pour un switch.
Fabrice
[View Less]
Bonjour,
Après quelques jours passés à m'imprégner plus avant du fonctionnement passé
de traduc, je vous livre mes premières réflexions quant à la mise en oeuvre
d'une interface étendue et automatisée. Ce point ayant été communément admis
comme prioritaire, il est donc nécessaire d'ouvrir dès maintenant un débat
quant à ses spécifications exactes.
Car, on a pu le voir ces derniers jours, plusieurs interfaces existent déjà,
et peuvent éventuellement être réutilisées sur traduc.org (voir …
[View More]sur le LDP
fr, si le projet devait finalement se concrétiser). Mais avant de se lancer à
corps perdu dans l'installation et le développement de telles architectures,
encore faut-il savoir ce que l'on doit en attendre.
Ce mail se veut donc un point d'ouverture à une discussion devant aboutir à
la rédaction des spécifications de l'interface. Il n'a rien d'une proposition
finie pour l'instant, et la discussion nécessite le concours du maximum de
personnes, ceci afin que l'outil final corresponde le plus possible aux
besoins de chacun.
Notez que beaucoup de passages ne font que reprendre des idées déjà énoncées
par ailleurs sur la liste.
I] Vue d'ensemble
Le premiers stade de l'élaboration des spécifications consiste à définir les
tâches accomplies par l'application finale au travers de principes généraux.
Ces principes, ou règles de base, définiront la structure interne du suivi
des traductions, et donc - par extension - de traduc.org. Ils serviront
également de référence lors de l'élaboration de l'interface (que celle-ci
soit créée de toutes pièces par nos soins, ou adaptée de celle d'un projet
tiers).
Cette étape est donc particulièrement importante, et est également la moins
technique de toutes. Les points auxquels on s'attachera seront les suivants :
gestion des utilisateurs, gestion des documents, publication. Cette liste est
éventuellement à compléter, si vous voyez d'autres aspects qui demandent une
réflexion de notre part.
2] Gestion des utilisateurs
Actuellement, il y a trois types d'utilisateurs sur traduc : les traducteurs,
les relecteurs et le coordinateur. Dans le cadre d'un passage à l'automatisé,
il peut être intéressant de repenser cette attribution des rôles, qui a été
prévue à l'origine pour une gestion "manuelle" des traductions.
Le grand pas en avant que permet l'automatisation est la
possibilité de déléguer toute la partie validation effective d'une
traduction. Pour éviter les traductions fantaisistes, on est en effet obligés
de conserver une validation manuelle de toute proposition de traduction.
Actuellement, le système consiste à attendre la validation de trois
relecteurs, qui est constatée par le coordinateur, lequel publie le nouveau
document.
Pour éviter cela, on peut distinguer deux types de relecteurs : ceux
ayant déjà fait la preuve de leur sérieux (typiquement en soumettant/relisant
une traduction validée), et les 'nouveaux'. Les traductions ou relectures
doivent obtenir l'aval d'un utilisateur confirmé avant d'être publiés. Le
coordinateur n'intervient alors plus là que pour régler des problèmes
ponctuels, tels un mauvais plaisantin qui se serait glissé entre les mailles
du filet.
3] Gestion des documents
Cette partie détaille l'évolution d'un document depuis son intégration en
langue étrangère jusqu'à sa parution.
Ici, il semble clair que toutes les procédures se font en ligne. Une page
spécifique regroupe les documents en attente de traducteur ou de relecteur,
il est possible d'y consulter le document en VO (et évenuellement VF pour les
documents non relus) pour se faire une idée. Si l'utilisateur est loggé et
n'est pas déjà en train de traduire/relire un document, il peut décider de
s'occuper de celui-ci.
Pour éviter les doublons, une fois qu'un utilisateur s'occupe d'un
document, il est marqué comme [EN COURS] et ne peut plus être pris par un
autre. Pour éviter le squat, le traducteur (et le relecteur aussi, dans une
certaine mesure) devra indiquer à intervales réguliers l'avancement de sa
traduction, ainsi que les raisons d'un éventuel retard (relances par mail).
Au bout d'un certain laps de temps (2 mois?), le retard sera visible du
coordinateur (avec les explications éventuellement fournies par le
traducteur), qui pourra décider de libérer le document. L'utilisateur pourra
d'ailleurs décider lui-même de libérer un travail qu'il effectue.
Il est possible à tout moment d'uploader un travail partiel, ceci afin de
permettre à tous de voir l'avancement des travaux, mais aussi de pouvoir
transmettre ce document s'il change de main.
Une fois terminé, le document traduit est soumis à validation des
utilisateurs confirmés. S'il y a à redire, les modifications sont à intégrer
par l'auteur lui-même. Il va sans dire qu'un utilisateur confirmé ne pourra
pas auto-approuver une de ses propres traductions...
Pour les diffs entre deux versions d'un document, ou lors d'une relecture, il
faut regarder les possibilités techniques exactes (notamment au niveau de
xmldiff, comme mentionné par Nicolas Chauvat), mais il ne paraît pas
inenvisageable de proposer une interface web complète à ce niveau.
4] Publication
Un document traduit, c'est déjà une bonne chose. Mais encore faut-il que l'on
puisse y accéder simplement et agréablement...
Il pourrait en effet être intéressant de proposer les documents par un autre
moyen que le FTP. Et même lorqu'ils sont mis directement sur le web (cf
Freenix), force est de constater que c'est un peu fouilli et rébarbatif,
comme présentation.
Il manque une valeur éditoriale, même très simple, qui permettrait au moins
de regrouper les documents par thèmes. Une autre bonne (?) idée serait
d'avoir un moteur de recherche (bon, ok, il y a déjà Google...).
Au final : tout ceci n'est qu'une première ébauche. J'insiste à nouveau sur
le fait que ce genre de chose doit être le fruit d'un travail de groupe pour
être vraiment utile. Et notez bien que je ne m'approprie pas le rôle de
coordinateur : ce mail est avant tout un pavé dans la mare. A la charge du
futur (ou présent?) coordinateur d'obtenir un consensus.
A vous !
--
Xavier.
[View Less]