[Programme] Traduisez vos programmes

Bonsoir à tous,

Avant toute chose, je m'excuse pour ma grosse absence du serveur ces derniers temps, j'ai à contrecoeur abandonné le serveur, simplement parce que l'absence des mods tels que Mekanism ou Thermal Expansion était pour moi difficile, je suis habitué à trop de mods pour ne pas jouer avec et CC sans Openperipheral entre autres est pour moi très difficile.

Cependant, même si je ne viens plus sur le serveur, de mon côté je continue à utiliser ComputerCraft et en ce moment je suis sur la création de pas mal de programmes pour ce dernier. Je souhaite donc vous les partager car cela fait déjà 3 programmes que je fais, aussi je vais vous les présenter car ils pourraient vous êtes utiles.

Bien, j'entre maintenant dans le vif du sujet ; le programme que je vous présence ce soir s'appel Translate API. J'avais parlé sur le serveur à l'époque, que je voulais faire un programme de traduction pour nos programmes, maintenant c'est chose faite (après 2h entre la recherche et le codage lol).
Ainsi, [b]Translate API{/b], est une API de traduction de vos programmes qui est très simple et utilise le type Table de LUA.

Mais tout d'abord, quelques liens. Le pastebin pour récupérer directement l'API : http://pastebin.com/ZLMCV0Vn et le github du projet avec un README.md pour toutes les informations sur son utilisation (vous y retrouverez aussi les autres programmes que je fais sur CC d'ailleurs) : https://github.com/Christophedlr/LUACCProgram/tree/master/api


Maintenant j'en viens aux explications sur son utilisation. C'est très simple, l'API fonctionne en deux fonctions :

• open : il ne demande qu'un seul paramètre qui est le nom du fichier de traduction (nom totalement libre)
  
• tr : il ne demande qu'un seul paramètre qui est la clé de traduction (on est dans un tableau je rappel c'est donc une clé pour retrouver la valeur)
  

Ainsi, la première fonction a pour but de charger le fichier de traduction, quand la seconde permet simplement de pouvoir faire la traduction.
Dans l'exemple suivant, je suis devant un programme de sécurité demandant un login et un mot de passe, nous voulons traduire en français.

french.lng :

Code:


{
    login = {
        text = "Utilisateur"
    },
    password = {
        text = "Mot de passe"
    }
}


Et voilà le programme de test :

Code:


os.loadAPI("translate")

translate.open("french.lng") -- Load french translation
print( The login translation in french is: ",translate.tr("login") )
print( The password translation in french is: ",translate.tr("password") )
print( The access translation in french is: ",translate.tr("access") )


Comme on le constate, french.lng est un tableau (Table) LUA (sérialisé), ce qui ressemble beaucoup au JSON pour ceux qui connaissent.
Le programme lui, charge l'API (attention je rappel que la variable translate est le nom du fichier appelé dans os.loadAPI, donc faite attention au nom).
Une fois l'API chargée, on ouvre le fichier de traduction et on affiche trois traduction.

Comme on le voit, la troisième traduction n'existe pas, il affichera donc à la place : "undefined access translation", ce qui permet lors du debug de voir qu'il y a une couille dans le potage (berk).


Ayant fait le programme en vitesse, pour l'instant il n'y a pas de système de création/édition de la traduction, c'est toutefois prévu et un éditeur sera fournis plus tard pour faciliter la rédaction des traductions. En attendant, vous allez devoir taper votre traduction à la main .

J'espère que ce petit programme vous sera utile. Personnellement je vais maintenant l'utiliser dans tout mes futurs développements, ainsi mes prochains programmes demanderont l'utilisation de cette API qu'il faudra installer (je planche sur un système d'installation justement, mais chut j'en parlerais en temps et en heure ).

Simple et efficace ^^
J'étais justement en train de prévoir une traduction dans mon programme (en cours), mais je suis du genre à opter pour l'affichage d'une langue par défaut, quand bien même aucun fichier de traduction n'aurait été chargé. Aussi de conserver dans le programme au moins une version du texte.

Disons que je ne partirais pas à priori sur le fait que le programmeur décide d'interrompre son programme au cas où la traduction foire. En principe tout l'intérêt de ton API est de détacher le travail de traduction du travail de programmation. C'est donc une ouverture pour collaborer avec des traducteurs, qui n'auront pas nécessairement besoin de comprendre le code du programme à traduire pour faire leur job.
Avec un texte par défaut, et le fait qu'un échec de translation.open(file) n'interrompe pas le programme, permettrait au traducteur d'être plus autonome, et de tester le programme au fur et à mesure. Voir même vérifier le contexte dans lequel le texte apparaît, car il y a aussi un souci d'interprétation, aussi un soucis d'espace disponible à l'écran.

Voici une petite modif en suggestion :

Code:

local table_translation = {}
local _init=false
debug = false

function open(filename)
    if fs.exists(filename) then
--        print("OK")
        local file = fs.open(filename, "r")
        table_translation = textutils.unserialize( file.readAll() )
        file.close()
        _init=true
        return true
    else
        print("The "..filename.." file is not exists")
        _init=false
        return false
    end
end

function tr(text,alt)
    if _init and table_translation[text] then
        return table_translation[text].text
    end
 
    return (alt and not debug) and alt or "Undefined "..text.." translation"
end

+ Variable locale _init, à false tant qu'un fichier valide n'ait été chargé (et évite d'interroger la table, si on sait déjà que ce n'est pas utile)
function tr(text,alt) + argument optionel "alt"
Ainsi la fonction pourrait d'utiliser ainsi :

Code:

translate.tr("button_submit","Submit")

En cas d'absence d'une traduction ou d'un fichier de traduction valide, le bouton affiche malgré tout "Submit" (version native)
S'il y a vraiment besoin que les traductions manquantes sautent aux yeux, il suffit de passer translate.debug à true

Bonjour Skypop,

Au départ je pensais faire comme cela, c'est à dire à la manière de QT, dont on indique à la fonction tr (que j'ai honteusement volée à QT justement lol), on passe en second paramètre, le texte à afficher par défaut si rien n'est trouvé.

Mais après j'ai renoncé à cette idée pour deux raisons :
1 - Pouvoir identifier de suite si on a oublié une traduction
2 - Si le travail est bien fait, au moins un fichier de langue est présent : l'anglais, et les traducteurs doivent normalement se baser sur ce dernier pour traduire dans les autres langues. Du coup il peut y avoir une différence entre le texte par défaut et le schéma de langue

Par contre cela me donne une idée et se serait un gros défit pour moi en LUA : recherche automatique comme le fait QT. En effet, sur QT, le programme de traduction se contente de scanner les fichiers sources indiqués afin de trouver les appels à tr ou trUtf8, il en récupère alors le texte puisque du coup ce n'est pas une "macro" comme je le propose mais bel et bien le texte lui même (on peut utiliser comme pour mon programme, simplement le but au niveau de QT c'est que tu écris comme d'habitude et traduit ensuite, c'est pareil pour les fichiers PO de traduction pour le web par exemple) et le note dans le fichier de traduction comme chaîne non traduite. Ce fichier de langue correspond à la langue dans laquelle on a écrit dans le code, donc normalement en anglais (si on fait le boulot correctement lol), c'est donc le fichier de référence qui sert pour la langue anglaise et comme schéma pour les traductions. Dans l'outil, on choisit donc les chaînes, on traduit et indique que c'est traduit, alors la chaîne traduite est utilisée sinon c'est la chaîne par défaut.

J'en viens du coup à mon idée. J'ai prévu mais pas eu le temps de le faire, un outil d'édition des fichiers de langues, comme le fait QT avec QTRanslator. Mon outil pourrait très bien scanné le fichier source que l'on indique, en récupérer du coup l'utilisation de tr, il enregistre donc ça dans le fichier de traduction et il ne reste qu'à traduire. Le problème étant qu'en utilisant un Table LUA (ou même du JSON), on ne peut avoir une "clé" qui est une phrase, donc on est obligé de rester sur le principe de la "macro".

Du coup, je peux comme tu le proposes, avoir une chaîne par défaut (au choix du développement de mettre un msg d'erreur ou le texte déjà dans une langue), il suffit ensuite juste de lancer l'outil pour générer le schéma de traduction, la valeur par défaut pourrait alors être cette chaîne de remplacement (si présente sinon pas de valeur bien entendu), du coup je simplifie le système de traduction tout en apportant une souplesse avec cette chaîne par défaut.


Là dans les jours qui suivent ça va être dur, mais je peux tenter de mettre ça en place pour la semaine qui vient. Après le problème dans tout les cas, c'est la distribution, un simple pastebin suffit pas ; du coup je suis entrain de plancher sur un nouvel outil qui serait un système d'installation basé là aussi sur les Table de LUA. Le fichier définissant le nom d'appel du programme et le lien direct absolu (attention par défaut seul github et pastebin sont acceptés sur CC, il faut modifier la config pour accepter d'autres sites via l'API http ou pour tous les acceptés).

Ainsi si le programme s'appel par exemple : "skypop", ben quand tu appels le prog d'installation avec ce nom, il va aller sur le lien et télécharger tout les fichiers indiqués dans le fichier de configuration ; du coup cela permet d'installer facilement des programmes multi-fichiers.

Mais bon j'en parlerais plus tard, car j'ai fait des tests ça fonctionne, reste qu'à faire le programme lui même lol.

Je comprend tout à fait tes deux raisons (mais ne sait rien de QT ^^).
Pour la première, c'est pour ça que j'ai rajouté une propriété "debug"
Pour la seconde, travail "bien fait" ou "mal fait" c'est subjectif, chaque programmeur a sa propre conception du travail bien fait, ou son propre seuil d’exigence.

L'intérêt majeur du texte par défaut, c'est qu'il permet de conserver une version du texte dans le code source du programme, dans la langue de son auteur original (ou langue qu'il maîtrise) Ainsi l'intégrité du programme est garanti quand bien même un fichier de traduction viendrait à se perdre, on aurait toujours la version originale de chaque texte. (à l'inverse, si c'est le programme est perdu, le fichier de traduction n'a plus d'utilité. C'est donc le programme qui compte avant tout)

Enfin, je ne pense pas qu'un traducteur puisse travailler correctement à la seule base du fichier de traduction. Ce n'est pas juste la conversion d'un fichier dans une autre langue. Il y a des ambiguïtés, des interprétations, même des contraintes (nombre de caractères, nombre de lignes) à considérer. Il est donc nécessaire de faire l'aller-retour entre le fichier et tester le programme.