-
- 659 Posts
Bonjour à tous,
Quelques suggestions :
Contexts -> Contextes (le terme existe en français autant l’utiliser)
Namespace -> ’Espace de nom’ ou ’espace de nommage’ (de nom me parait plus correct personnellement)
Symlink -> lien virtuel (?)
Email -> pourquoi rajouter un trait d’union ? soit on ’francise’ et c’est ’courriel’ sinon autant garder ’email’.
Je pense par ailleurs (mais ça n’engage que moi) que les termes ’Package’, ’Components’, ’Lexicon’, tout comme ’Chunks’, ’Templates’ et ’Templates variables’ ne devraient pas être traduits afin d’éviter les confusions lorsque l’on suit les forums anglophones ou les tutos en anglais. Les termes purement ’Modx’ devraient IMHO rester tels quels.
Cheers
-
- 428 Posts
Bonjour,
Je prends la suite pour quelques suggestions:
- Components: je propose d’utiliser simplement Composants. La notion de module est plutôt liée à Evolution.
- Namespaces: la traduction est effectivement «Espace de noms». D’ailleurs, Wikipedia explique très bien son utilité: http://fr.wikipedia.org/wiki/Espace_de_noms
- Lexicon: lexique, tout simplement.
- Package Management: gestion des paquets, peut-être. Mais je trouve pas le terme «paquet» très parlant. On peut probablement trouver mieux.
Je pense par ailleurs (mais ça n’engage que moi) que les termes ’Package’, ’Components’, ’Lexicon’, tout comme ’Chunks’, ’Templates’ et ’Templates variables’ ne devraient pas être traduits afin d’éviter les confusions lorsque l’on suit les forums anglophones ou les tutos en anglais. Les termes purement ’Modx’ devraient IMHO rester tels quels.
Sur certains termes, ça peut effectivement être plus simple. Il faut voir au cas pas cas.
Si on prend le terme Chunk, c’est difficile à traduire en français: morceaux, fragments... Pas très parlant.
Intégrateur web freelance
-
- 25 Posts
Salut Cheers,
Ok pour Contexts (contextes), Namespace (espace de nom), je les modifie dans ma liste (post précédent). Je retire également le - de e-mail de la liste.
Pour symlink, justement ce n’est pas un lien, c’est une ressource réelle qui reprend le contenu d’une autre page. D’où le duplicata ou réplique (mais je pense qu’il y a mieux).
Pour les termes type templates, templates variables, ... elles sont justement traduites dans les versions 1.0, d’où l’esprit de traduire ce genre de termes générales qui n’ont pas une très grande importance pour la "technique". Seule snippets, chunks et plugins (peut être quelques autres que j’ai oublié) sont gardés sous cette forme actuellement.
-
- 25 Posts
Salut Fairytree,
J’ai modifié dans la liste tes propositions. J’ai aussi modifié "package management" en "Gestion des composants" (suite logique avec ta proposition sur les modules).
Les termes "MODx" à traduire doivent rester compréhensible sans pour autant repousser l’utilisateur. En étant plus clair, n’oublions pas que cette traduction doit servir la communauté francophone, et certains termes que l’on connait nous, ne seront pas forcement clairs pour un utilisateur lambda si on ne traduit pas certains termes critiques.
Des idées pour symlink et static ressource ?
H.S : j’ai déjà traduit les pages suivantes : login.inc.php et dashboard.inc.php
-
- 25 Posts
Symlink (n’est pas un lien, c’est une ressource réelle qui reprend le contenu d’une autre page) doit être considérer comme un objet ou entité comme weblink = lien car ce terme est utilisé par exemple pour créer un "symlink", il n’y a pas de référence vers un document. De plus, il doit être court. Idem pour static ressource.
Gestion des composants semble plus parlant et surtout plus cohérent avec le reste du gestionnaire et les termes déjà proposés.
Il est important d’avoir installé MODx Révo et navigué dans ses menus pour bien comprendre le fonctionnement et la particularité de chaque page et/ou action avant de traduire.
MAJ : Traduction de dashboard.inc.php, login.inc.php et default.inc.php
-
- 25 Posts
Bon j’ai cherché toute l’après-midi, une solution intéressante pour le partage et l’édition des fichiers de traductions de MODx Révolution.
Malheureusement, je n’ai pas trouvé de solution qui regroupe : édition, partage, présentation formaté du code PHP, sécurité (contre les modifications abusives des fichiers), ...
Si quelqu’un a une solution à proposer pour nous permettre d’avancer efficacement et dans le même sens.
-
- 659 Posts
Hello je reviens vers vous,
Pour Symlink le plus simple est peut être de garder Symlink plutôt que de tenter une traduction ’approximative’ qui pourrait être source de confusion. D’autant que la subtilité du symlink réside non seulement dans le fait qu’il s’agit d’une ressource ’réelle’ mais aussi dans la façon dont l’URL est rendue (en FUL) dans le cas du weblink l’URL de la source ’réelle’ de l’info affichée, dans l’autre (symlink) l’adresse de la page ’hote’ du contenu affiché par le biais du symlink... j’aurais tendance à associer naturellement ’symlink’ à quelque chose comme ’symbolic link’ (lien symbolique ... qui n’est pas très "parlant" ni représentatif).
Quant à ’static Resource’ : "ressource statique" ne vous parait pas approprié ? "ressource externe" (puisqu’il s’agit essentiellement de fichiers ’externes’)?
Package management pourrait être gestion des paquets en effet... Mais j’en reviens aux autres sections du forum ou aux sections de download on y fait toujours mention de "package" pourquoi pas un barbarisme (pour une fois) et quelquechose comme "gestion des packages" ?
Cheers
☆ A M B ☆
