Ajout extension .lang dans la liste déroulante (idem .ini)
eldy
OpenSource.
Les fichiers langues sont des .ini mais avec l'extension .lang.
Ce sont donc des fichiers textes code=valeur comme tout fichier
ini.
Le seul fait d'avoir une extension en .lang empêche d'utiliser
phpLangEditor comme outils officiel de traduction pour le projet.
Serait-il possible, d'ajouter cela dans la liste déroulante des
extensions ?
Car hormis cela, phpLangEditor répond parfaitement aux attentes du
projet. Ceci nous éviterais d'avoir à redévelopper un outil concurrent
alors qu'il manque si peu pour pouvoir devenir l'outil standard de
traduction du framework Dolibarr et tous les projet qui gravite
autour ?
enca...@gmail.com
Heureux d'apprendre qu'un projet comme Dolibarr veut utiliser
phpLangEditor.
Actuellement le parsing des fichiers de langue se fait en fonction de
l'extension choisie lors de l'envoi du fichier. Ma crainte est
que .lang puisse être utilisé aussi bien comme extension de fichier
php (on ne sait jamais) que pour des fichiers ini. Il faut donc que
je revois plus fondamentalement le code de lecture des fichiers afin
de les interpréter correctement quel que soit leur contenu.
Ne vous serait-il pas possible dans un premier temps de renommer vos
fichiers en .ini le temps de la traduction avec phpLangEditor ?
La version 2.4 de phpLangEditor a été soumise il y a bientôt 3
semaines à Mozilla pour publication sur le site officiel mais est
malheureusement toujours en attente de validation. Je vais essayer de
trouver le temps de refaire le code de parsing des fichiers afin de
détecter le type de contenu sur base du contenu réel et non de
l'extension mais aussi pour améliorer la prise en charge d'autres
syntaxes php telles que les tableaux ou les constantes. Ce sera
normalement pour la prochaine version (2.5 ou 3.0). Toute aide est la
bienvenue.
Bonne continuation
Eldy
> Bonjour Eldy,
>
> Heureux d'apprendre qu'un projet comme Dolibarr veut utiliser
> phpLangEditor.
>
> Actuellement le parsing des fichiers de langue se fait en fonction de
> l'extension choisie lors de l'envoi du fichier. Ma crainte est
> que .lang puisse être utilisé aussi bien comme extension de fichier
> php (on ne sait jamais) que pour des fichiers ini. Il faut donc que
> je revois plus fondamentalement le code de lecture des fichiers afin
> de les interpréter correctement quel que soit leur contenu.
>
> Ne vous serait-il pas possible dans un premier temps de renommer vos
> fichiers en .ini le temps de la traduction avec phpLangEditor ?
>
renommer ces ficihers puis restaure a chaque modif de traduction,
surtout dans un environnement de développement muni de CVS.
Pour une efficacité optimale nous aimerions lever cette barriere.
Que penses-tu d'ajouter une option meme cachée (par exemple dans les
options obtenues par l'URL "about:config" de firefox) et qui permet de
modifier la liste des extension fichier .ini (on y remplace .ini ou
ajoute .lang).
Nous indiquerions dans la doc du traducteur dolibarr cette étape
supplémentaire de configuration après install du module et qui fait
l'objet d'une démarche volontaire des traducteurs Dolibarr pour avoir la
ligne apparaitre.
Ensuite, une fois l'opération faite, l'outil est définitivement
utilisable avec les .lang
Mais seul les utilisateurs Dolibarr ont cette fonction, phpLangEditor
garde en standard sa fonction limité au .ini.
> La version 2.4 de phpLangEditor a été soumise il y a bientôt 3
> semaines à Mozilla pour publication sur le site officiel mais est
> malheureusement toujours en attente de validation. Je vais essayer de
> trouver le temps de refaire le code de parsing des fichiers afin de
> détecter le type de contenu sur base du contenu réel et non de
> l'extension mais aussi pour améliorer la prise en charge d'autres
> syntaxes php telles que les tableaux ou les constantes. Ce sera
> normalement pour la prochaine version (2.5 ou 3.0). Toute aide est la
> bienvenue.
>
A part tester, je suis deja hélas pris mais si on a les .lang géré en
option caché, je teste de suite.
L'absence d'outils conviviaux simple étant un frein à la traduction de
Dolibarr.
> Bonne continuation
>
>
> On Jul 9, 12:06 pm, eldy <eld...@gmail.com> wrote:
>
>> Je travaille sur le projet Dolibarr ERP/CRM, un important projet
>> OpenSource.
>> Les fichiers langues sont des .ini mais avec l'extension .lang.
>>
>> Ce sont donc des fichiers textes code=valeur comme tout fichier
>> ini.
>>
>> Le seul fait d'avoir une extension en .lang empêche d'utiliser
>> phpLangEditor comme outils officiel de traduction pour le projet.
>> Serait-il possible, d'ajouter cela dans la liste déroulante des
>> extensions ?
>> Car hormis cela, phpLangEditor répond parfaitement aux attentes du
>> projet. Ceci nous éviterais d'avoir à redévelopper un outil concurrent
>> alors qu'il manque si peu pour pouvoir devenir l'outil standard de
>> traduction du framework Dolibarr et tous les projet qui gravite
>> autour ?
>>
> >
--
Laurent Destailleur.
---------------------------------------------------------------
EMail: el...@destailleur.fr
Web: http://www.destailleur.fr
IM: IRC=Eldy, Jabber=Eldy
AWStats (Author) : http://awstats.sourceforge.net
CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net
AWBot (Author) : http://awbot.sourceforge.net
Dolibarr (Contributor) : http://www.dolibarr.org
enca...@gmail.com
J'ai fais quelques modifications relatives à ta 3eme idée. J'ai
packagé une nouvelle version de phpLangEditor (2.5b) disponible ici :
http://code.google.com/p/phplangeditor/downloads/list
La propriété à modifier dans le about:config est
"phplangeditor.file.typeOfLangExt". Les valeurs possibles sont 'php'
et 'ini', je pense que c'est la façon la plus souple d'aborder la
chose. C'est actuellement en beta, il faudrait que j'ajoute une
interface pour modifier cette valeur facilement mais j'aimerai
d'abord que tu me confirmes que la solution choisie est correcte dans
le cas de Dolibarr.
Dès que je sais quoi je soumets la verison stabilisée à Mozilla pour
publication.
Bien à toi,
Sébastien
On 11 juil, 17:13, Eldy <e...@destailleur.fr> wrote:
> encai...@gmail.com a écrit :
Eldy
> Hello Eldy,
>
> J'ai fais quelques modifications relatives à ta 3eme idée. J'ai
> packagé une nouvelle version de phpLangEditor (2.5b) disponible ici :
> http://code.google.com/p/phplangeditor/downloads/list
>
> La propriété à modifier dans le about:config est
> "phplangeditor.file.typeOfLangExt". Les valeurs possibles sont 'php'
> et 'ini', je pense que c'est la façon la plus souple d'aborder la
> chose. C'est actuellement en beta, il faudrait que j'ajoute une
> interface pour modifier cette valeur facilement mais j'aimerai
> d'abord que tu me confirmes que la solution choisie est correcte dans
> le cas de Dolibarr.
>
J'ai donc mis lang dans la constante cachée (Pour une interface pour
modifier c'est pas forcément nécessaire
en tout cas pas pour dolibarr, la procédure du "traducteur dolibarr"
s'occupera d'expliquer comment changer
ce parametre).
J'arrive bien à ouvrir le fichier lang source.
Les chaines sont correctement détectés en correctement encodées (après
choisir ISO-8859-1) et affichées.
Par contre, pas moyens d'ouvrir les fichier lang de traduction. On vois
bien les fichier lang dans la liste mais s'ils
ne sont pas en ini, ils ne s'ouvre pas.
Mais même si je renomme le fichier en .ini et si je remet le paramétrage
d'origine, pas moyen d'ouvrir le fichier traduction. Seul le fichier
source s'ouvre.
Je joins une copie écran montrant la zone du bas toujours vide alors
qu'il y a des choses dans le fichier traduit ouvert.
Je joins aussi les 2 fichier lang pour test que j'ai renommé en .ini
pour que tu constates par toi meme mais qu'ils soit en .ini ou .lang,
meme pb...
Je n'avais pas ce souci dans une version bien antérieure.
--
Laurent Destailleur.
---------------------------------------------------------------
EMail: el...@destailleur.fr