Il y a trois problématiques : le langage de programmation, la localisation unique/multiple et la traduction proprement dite.
Le langage de programmation
Aujourd'hui, grosso modo, il y a deux grandes familles de langage : le langage C avec ses multiples dérivés et les langages de script comme Python. Ces langages ont, au fil des ans, développés des procédures de traduction. L'une des plus connue est gettext.
La localisation unique/multiple
Par localisation je mets dans le même sac (par simplification) la traduction pure, les variantes linguistiques et les contraintes politiques locales (mots interdits par le politiquement correct). Quand on développe un projet, surtout si l'on n'est pas anglophone, la question de la traduction de son œuvre se pose assez tôt. il y a deux voies : traduire le code source avant compilation (ce que fait gettext) ou bien intégrer toutes les traductions dans le logiciel avant sa compilation. Dans le dernier cas, la variable d'environnement (LANG, par exemple) détecte la localisation à appliquer au moment où l'utilisateur lance le logiciel.
L’œuvre de traduction
Si l'on est dans le cas de gettext, effectivement, la chose est plus facile car cet outil permet d'opérer sans grande connaissance de la programmation. Dans les autres cas, c'est beaucoup moins limpide. Et encore moins quand on touche à des langages moins main stream (comme mon projet fBlog qui est en Fortran). Reste que la traduction d'un logiciel n'est pas strictement une tâche littéraire ! En effet, une traduction mot à mot n'est pas toujours possible même dans le cas le plus simple de celle des menus de navigation à l'intérieur du logiciel. Même si les mots comme "Edit", "File", "Save"... ont leur équivalents bien connus, il y aura toujours des options de navigation qui seront nouvelles. Et c'est là où un spécialiste de la langue atteindra ses limites. De ce qui précède, une traduction suppose non seulement d'être linguiste mais aussi d'avoir une pratique réelle du logiciel que l'on veut traduire. Et si l'on ne dispose pas d'outils comme gettext, il faut être capable de se plonger dans le code source. Enfin un dialogue avec l'auteur du logiciel finira par devenir indispensable car il y aura la nécessité de synchroniser sa traduction avec les mises à jour du logiciel pour les intégrer dans son paquet. La connaissance d'une langue véhiculaire (le plus souvent l'anglais) et l'aptitude à communiquer directement (mail, par exemple) ou indirectement (push par GitHub...) est souhaitable. Il y a aussi la question du copyright des traducteurs ce qui est chose délicate dans le cas d'une traduction initiée par une structure publique au sein d'un collectif.
# Le point de vue d'un développeur
Posté par Denis Bernard . En réponse au journal Traduction des logiciels libres. Évalué à 5.
Il y a trois problématiques : le langage de programmation, la localisation unique/multiple et la traduction proprement dite.
Le langage de programmation
Aujourd'hui, grosso modo, il y a deux grandes familles de langage : le langage C avec ses multiples dérivés et les langages de script comme Python. Ces langages ont, au fil des ans, développés des procédures de traduction. L'une des plus connue est gettext.
La localisation unique/multiple
Par localisation je mets dans le même sac (par simplification) la traduction pure, les variantes linguistiques et les contraintes politiques locales (mots interdits par le politiquement correct). Quand on développe un projet, surtout si l'on n'est pas anglophone, la question de la traduction de son œuvre se pose assez tôt. il y a deux voies : traduire le code source avant compilation (ce que fait gettext) ou bien intégrer toutes les traductions dans le logiciel avant sa compilation. Dans le dernier cas, la variable d'environnement (LANG, par exemple) détecte la localisation à appliquer au moment où l'utilisateur lance le logiciel.
L’œuvre de traduction
Si l'on est dans le cas de gettext, effectivement, la chose est plus facile car cet outil permet d'opérer sans grande connaissance de la programmation. Dans les autres cas, c'est beaucoup moins limpide. Et encore moins quand on touche à des langages moins main stream (comme mon projet fBlog qui est en Fortran). Reste que la traduction d'un logiciel n'est pas strictement une tâche littéraire ! En effet, une traduction mot à mot n'est pas toujours possible même dans le cas le plus simple de celle des menus de navigation à l'intérieur du logiciel. Même si les mots comme "Edit", "File", "Save"... ont leur équivalents bien connus, il y aura toujours des options de navigation qui seront nouvelles. Et c'est là où un spécialiste de la langue atteindra ses limites. De ce qui précède, une traduction suppose non seulement d'être linguiste mais aussi d'avoir une pratique réelle du logiciel que l'on veut traduire. Et si l'on ne dispose pas d'outils comme gettext, il faut être capable de se plonger dans le code source. Enfin un dialogue avec l'auteur du logiciel finira par devenir indispensable car il y aura la nécessité de synchroniser sa traduction avec les mises à jour du logiciel pour les intégrer dans son paquet. La connaissance d'une langue véhiculaire (le plus souvent l'anglais) et l'aptitude à communiquer directement (mail, par exemple) ou indirectement (push par GitHub...) est souhaitable. Il y a aussi la question du copyright des traducteurs ce qui est chose délicate dans le cas d'une traduction initiée par une structure publique au sein d'un collectif.