Conseil pour la traduction de certains textes

Remarque générale

• Limesurvey produit des questionnaires , pas des enquêtes ou des sondages qui dont 2 termes moins généraux

Remplacement en cours ou a effectuer

• contacts : pour les informations concernant les personnes dans la table centralisée
• Base centralisé des contacts : la table des contacts, en anglais : Participant panel, précédemment traduit par Panel de participants
• participant : pour les informations des personnes liées à un questionnaire en particulier. (token_table).
• invitation : uniquement le système d'envoi par courriel.
• code d’invitation : le code spécifique pour le participant à un questionnaire.
• courriel : au lieu de mail, email ... , préférer courriel, adresse de courriel ou message selon la phrase.

Remarques plus générales

• Guillemet et apostrophe (') :l'apostrophe par défaut peut ne pas être fonctionnelle (par exemple sur les pdf ou sur la valeur par défaut lors de l'ajout des réponses, transformée en &amps;#39; ). Il faut préférer le "guillemet-apostrophe" (cf wikipedia ) réalisable sur certain clavier avec [AltGR][MAJ] ’

* Message d'origine *

Bonjour à tous,

Il y à quelques semaines Nickko demandait à changer la liste automatique de Genre pour Monsieur/Madame plutôt que pour Masculin/Féminin sur le rapport de bug : Gender values in french are not correct .

J'ai pour l'instant fermé le bug : Masculin/Féminin me semble adapté à Genre, et Monsieur/Madame à titre et Homme/Femme à ????

Maintenant, ce n'est pas uniquement à moi de prendre la décision, donc : votre avis ?

Ce sujet peut servir pour d'autres discussion grammaticale ou d'autres remarques sur les chaines de langue.

Denis

Vu que la civilité Mademoiselle a été supprimée, j'y suis plutôt favorable. Néanmoins, quid des questionnaires adressés à des mineurs (lors d'activités pédagogiques par exemple)... Pourquoi pas une option supplémentaire pour le choix du couple du genre ?

En fait, je me demande si c'est une bonne idée d'avoir cette question dans les types prédéfinis, et s'il ne faudrait pas plutôt traiter ça comme un jeux d'étiquettes.

Il pourrait être proposé des jeux d'étiquettes directement à l'installation de LS avec des titres comme civilité (M. / MME), sexe 1 (H/F), sexe 2 (M/F), etc. Voire même d'autres non lié aux civilités/sexes.

Ainsi, on simplifiait aussi le choix du type de question à la forme et la logique (choix unique, choix multiple, etc.)

Nickko wrote: En fait, je me demande si c'est une bonne idée d'avoir cette question dans les types prédéfinis, et s'il ne faudrait pas plutôt traiter ça comme un jeux d'étiquettes.

Il pourrait être proposé des jeux d'étiquettes directement à l'installation de LS avec des titres comme civilité (M. / MME), sexe 1 (H/F), sexe 2 (M/F), etc. Voire même d'autres non lié aux civilités/sexes.

Ainsi, on simplifiait aussi le choix du type de question à la forme et la logique (choix unique, choix multiple, etc.)

Une sorte de séries étiquettes proposées à optionnellement à l'installation ?

Pas bête ça, c'est vrai que les étiquettes sont peu utilisées, par contre faudra gérer le multilinguisme: on place toutes les étiquettes, juste celle sélectionée etc ... Ca remplis la BDD pour pas grand chose.

@rems : bin oui, mais non : multilinguisme . A propos, c'est quoi la EN ?

EN ?

Penses-tu que quelques étiquettes même dans les 53 langues prennent beaucoup de place en DB ?
Je ne suis pas sûr de ce que j'avance, mais je pense que c'est loin de prendre tant de place que ça.

Moi, je ne les proposerais pas en option. Par contre je leur offrais plus de visibilité.
Pourquoi ne pas proposer les étiquettes qui seraient installées par défaut directement dans la liste des types de questions.

Par exemple "liste de boutons radios avec genre". Bon ça fait un peu long et ça revient sur l'intérêt que j'avais précédemment évoqué, c'est à dire simplifier le nombre d'option dans la liste.

Ou alors proposer les listes d'étiquettes dans une liste en plus juste sous le type de question.

EN -> Anglais (code international )

Sinon, cela devient un plus gros chantier, retravailler l'éditeur des réponses/sous-question pour l'ajout plus rapide d'étiquettes, ou lors de la création.

Pour ma part, c'est peu gênant car j'ai simplement créer mes questions "Civilité" (Monsieur/Madame/Maitre/Docteur/...), "Sexe civil" (Homme/Femme), "Sexe sportif" (Masculin/Féminin).

J'ai exporté chaque question que je conserve au chaud dans un répertoire de modèle et quand j'en ai besoin, j'importe la bonne.

Je n'utilise même plus la question "Genre" fournie de base.

Donc s'il y a d'autre priorité en terme de Dév. je pense que ce changement est accessoire.

Si jamais on doit traduire correctement la question pré-existante, il faut s'en tenir au sens officiel. je vous propose donc à nous en tenir à la version de l'OMS : Masculin / Féminin
www.who.int/gender/whatisgender/fr/index.html

Homme / Femme est selon eux lié au sexe (humain) et non au genre.

Salut,

Avec l'arrivée de la version 2, il y a la nouvelle fonctionnalité "central participant database panel".

Je ne sais pas trop quoi choisir comme traduction, au début j'avais plus utilisé "BAse des panelistes", je trouvais cela court et agréable. Par contre c'est très orienté comme terme paneliste, même si pas mal d'utilisateur l'utiliseront dans ce cadres, ce n'est pas uniquement destiné à ça.

Un nouveau traducteur merci Qat utilise "Base de données centrale des participants", le terme participant est pas mal je trouve, je proposerais bien : "Base centralisé des participants".

• Les participants : dans la base centralisé.
• Les invitations : les lignes de la table des invitations.
• Les répondants : les personnes répondant au questionnaire (avec ou sans invitation, on peut parler de répondant de la table d'invitations au besoin)

A propos : on parle directement d'invitation, et pas de jeton d'invitation. L'invitation correspond à la ligne de la base de données, le code (ou code de l'invitation) à la colonne 'token' de cette base de données.

Qu'est ce que vous en pensez ? Sachant que le principe est de rester clair et assez généraliste et concis.

Denis

Bonjour Denis, et merci de m'accueillir sur le forum.

A propos de "central participant database panel", il est vrai que ma traduction est assez hasardeuse. N'ayant pas retrouvé le contexte de cette expression, j'ai traduit le plus littéralement possible. Et j'ai en plus fait une erreur au sujet de "panel".

[strike]Je crois qu'on peut donc parler de "panel de la base centralisée des participants".[/strike]Edit : OK, je viens de retrouver le contexte. La phrase exacte est "central participant database/panel" avec un slash. Ce qu'on peut traduire par "Panel/Base centralisée des participants"

Concernant "jeton d'invitation", cela correspond systématiquement à "token" dans mes propositions de traduction. J'ai choisi cela car je ne trouvais pas d'expression utilisée systématiquement dans le reste de la traduction (pafois 'jeton', parfois 'code', parfois 'invitation', ...). Je pense effectivement qu'il ne faut pas mélanger le concept de "token" = (code, jeton) avec celui d'invitation (plus large). Je suis donc favorable à ce qu'on utilise systématiquement "code d'invitation", ou "code" seul lorsque le contexte le permet.

Cela signifie qu'il faut éradiquer le terme jeton des traductions existantes...

Qat wrote: Bonjour Denis, et merci de m'accueillir sur le forum.

Merci surtout à toi de participer à la traduction

A propos de "central participant database panel", il est vrai que ma traduction est assez hasardeuse. N'ayant pas retrouvé le contexte de cette expression, j'ai traduit le plus littéralement possible. Et j'ai en plus fait une erreur au sujet de "panel".

C'est la gestion centralisé d'une base qui sera ensuite utilisé sur les invitations. J'ai certains client qui vont considérer ça comme une base de panelistes, mais c'est pas que ça.
De mon coté, je n'aime pas trop le termes techniques dans les traduction. Ta traduction est bonne, mais je ne sais pas si elle n'est pas trop technique .

Cela signifie qu'il faut éradiquer le terme jeton des traductions existantes...

C'est historique, avant même que je commence à bosser sérieusement sur LS. Sur la1.70 , de souvenir : jeton d'invitation, disparition du terme "jeton" au fur et à mesure de la 1.8 (je crois). C'est pour cela aussi que je me permet de remplacer certaines traduction de la 2.0 pour reprendre la traduction existante. Par exemple, le fait d'ajouter un point à une phrase créé une nouvelle chaine de traduction, j'essaye de reprendre la traduction précédente plutôt que d'en recréer une nouvelle .

Encore , un énorme merci pour les traductions

Denis

Si cela vous peut vous aider concernant la traduction:

* un paneliste est en effet trop orienté en terme métier (orienté sondage alors que l'outil peut permettre d'autre action métier)
* un participant est censé avoir "participé". Quid des prospects en base ayant jamais répondu.

la base centrale si j'ai bien compris les évolutions de la 2.0 va contenir les participants (qui ont répondu à des Q. anonymes ou non) mais aussi tous les prospects (pour les sondages non anonymes mais répondants pas).
On est plus dans la définitions des destinataires des Q. ... on pourrait mêmes imaginer les nommés "clients" mais là encore c'est trop orienté commerce.

Pour ma part, si cela ne pouvaient pas entraîner de confusion avec les contacts administratifs des questionnaires, j'aurais choisis "base centralisée des contacts".
Sinon, à défaut, le terme "participant" (même si jamais de réponse) semble la meilleur option.

J'aime bien les "contacts".

Je viens d'approuver un paquet de traduction avec participants ... :huh: