Simplifier la création des fichiers local

[Lipki]

Je Pense que ce serait vraiment pratique de simplifier la création des fichiers local. ne serais que pour simplifier la traduction de certaine application, et pour éviter des contributions incomplètes, seulement traduit en utf-8 par exemple.

Il y a forcément une solution, php, macro d'éditeur de texte, ou autres choses.

---

Cela pourrait être ajouter en ligne de commande.

php jelix.php --myapp addlocal mon/fichier/local.txt module langue

Soit les fichiers existe, et les stringlocal sont ajouter, soit les fichiers n'existe pas et il sont créer.

Il faut bien garder le fichiers sources, pour pouvoir faire des modifications facilement.

---

Je pense a autres choses, si il est possible de faire cela en php, pourquoi ne pas compiler les fichiers local de la même manière que les templates, ce serais encore plus simple.

---

Je m'en vais faire des recherches sur l'encodage en php, car je ni connais pas grand choses

[Lipki]

Pour notre bast qui doit en avoir vraiment besoin :)

[Lipki]

$string = 'le texte';
$encode = mb_detect_encoding($string, "UTF-8, ISO-8859-1, ISO-8859-15", true);
// ou $encode = mb_detect_encoding($string);

$string_iso1 = mb_convert_encoding($string, "ISO-8859-1", $encode);
$string_iso15 = mb_convert_encoding($string, "ISO-8859-15", $encode);
$string_utf8 = mb_convert_encoding($string, "UTF-8", $encode);

Ca ma pas l'air sorcier :) ...

[Lipki]

tiens qui est julien ??

[bballizlife]

Voir le ticket #268 qui porte déjà sur le sujet et qui est pour le moment prévu pour Jelix 1.3

[Lipki]

ok c'est pas tous a fait la même approche quand même.

Enfin jelix 1.3, c'est un peut loin, surtout que l'on peut faire quelque chose de simple rapidement.

[bballizlife]

Cependant je ne comprends pas bien ce que tu veux faire ici. Si c'est pour lancer une commande pour copier un fichier properties dans le bon module, c'est pas méga overkill ?

Pour résumer : quel est vraiment le but de ce ticket ?

[Lipki]

Tous simplement d'écrire a la main :

ui.txt

Et de générer automatiquement :

ui.ISO-8859-1.properties ui.ISO-8859-15.properties ui.UTF-8.properties

Soit en ligne de commande, soit en créant les fichiers comme sont créer les fichiers de templates compiler.

C'est plus clair comme ça ??

[bballizlife]

J'ai personnellement du mal à trouver un intérêt à avoir un jelix-script pour copier un fichier properties dans un autre charset. On duplique ici une fonctionnalité d'un éditeur de texte.

[laurentj]

@bballizlife : quand tu installe un module tiers et qu'il n'y a pas les fichiers properties dans la langue/locale que tu veux, une ligne de commande est bien pratique pour faire la conversion de tout les fichiers en même temps.

@lipki: comme a ecrit bballizlife, ce ticket est un duplicata du 268. La prochaine fois, avant de créer un ticket, vérifie qu'il n'existe pas déjà ;-) C'est pas parce qu'un ticket est prévu pour une version x.x qu'on ne peut pas le résoudre pour une version plus "proche". Au contraire. La roadmap est fait en fonction du temps dispo des contributeurs.

Julien est le "component owner" de jLocale tout simplement. Et ce ticket ne concerne pas jlocale mais les scripts jelix-scripts.

Bon sinon, ce serait cool d'écrire les tickets en anglais si possible. Si on veut aussi des contributeurs étrangers...

[Lipki]

Replying to laurentj:

@lipki: comme a ecrit bballizlife, ce ticket est un duplicata du 268.

Dans le 268, bballizelife propose un script très complet et donc long à faire :) ici je ne propose qu'un simple scripts de conversion de fichier, qui pourrait être disponible très rapidement.

La prochaine fois, avant de créer un ticket, vérifie qu'il n'existe pas déjà ;-)

J'ai chercher pourtant :)

C'est pas parce qu'un ticket est prévu pour une version x.x qu'on ne peut pas le résoudre pour une version plus "proche". Au contraire. La roadmap est fait en fonction du temps dispo des contributeurs.

Ok cool

Bon sinon, ce serait cool d'écrire les tickets en anglais si possible. Si on veut aussi des contributeurs étrangers...

ce sera sans moi :(, si j'écris en anglais mes tickets ne seront plus de la contribution, mais du spam !

:)

[laurentj]

rien ne t'empêche, sur le 268, de proposer une première version simple. Par contre, je ne suis pas fan du ui.txt en argument : autant pouvoir indiquer un fichier properties en argument, + la liste des charsets dans lequel on le veut

[Lipki]

Un tour sur le 268

et retour ici.

---

Je propose donc un patch.

Le principe est de créer les fichiers properties manquant pendant le build. On ne créer donc qu'un seul fichier properties de l'encodage que l'on souhaite(UTF-8 par exemple)

• lib/jelix/core-modules/jelix/locales/fr_FR
  • acl2db.UTF-8.properties
  • acl2db.ISO-8859-1.properties
  • acl2db.ISO-8859-15.properties
  • acldb.UTF-8.properties
  • acldb.ISO-8859-1.properties
  • acldb.ISO-8859-15.properties
  • ect. ...

Ce qui donne dans le manifest

cd lib/jelix/core-modules/jelix/locales/fr_FR
# acl2db.UTF-8.properties
# acldb.UTF-8.properties
 ...

j'ai ajouté dans le manifest un caractère #.
Lorsque jManifest trouve ce caractère il créer les encodages manquant dans le dossier de destination.

Voila ce que l'on obtiens avec le mode verbose

copy  ./lib/jelix/core-modules/jelix/locales/fr_FR/acl2db.UTF-8.properties      to      ./top/lib/jelix/core-modules/jelix/locales/fr_FR/acl2db.UTF-8.properties
encode into  ./top/lib/jelix/core-modules/jelix/locales/fr_FR/acl2db.ISO-8859-1.properties
encode into  ./top/lib/jelix/core-modules/jelix/locales/fr_FR/acl2db.ISO-8859-15.properties
copy  ./lib/jelix/core-modules/jelix/locales/fr_FR/acldb.UTF-8.properties       to      ./top/lib/jelix/core-modules/jelix/locales/fr_FR/acldb.UTF-8.properties
encode into  ./top/lib/jelix/core-modules/jelix/locales/fr_FR/acldb.ISO-8859-1.properties
encode into  ./top/lib/jelix/core-modules/jelix/locales/fr_FR/acldb.ISO-8859-15.properties

---

Cela permet d'alléger le build, et d'éviter les erreurs, car ça réduit sérieusement le nombre de fichier a écrire.
C'est également plus facile pour la traduction.

On peut également envisager de faire cette opération lors de la première utilisation d'un module, a l'image de la compilation des fichiers de template.

review? mais il faut évidement le finaliser.

[Lipki]

Replying to laurentj:

Bon, l'idée générale du patch, je suis ok, mais cela ne correspond ni au ticket 268, ni au ticket 503, ca la tu proposes non pas une ligne de commande mais une modif sur le build. Ça n'est donc pas vraiment le même usage.

donc retour au 503, ça correspond mieux effectivement.

[Lipki]

Alors pour finaliser, j'ajoute sous forme de paramètre la liste des encodages.

Sinon le symbole # pour te convient ?

[laurentj]

Pas sûr que le '#' soit trés explicite. Je pencherais plutôt pour un 'e', comme "encode". ou alors cch comme "convert charset".

à part ça, il y a un soucis dans ton patch, il faut passer à jManifest, d'une manière ou d'une autre la liste des encodages vers lesquels il faut convertir, cette liste pouvant être déterminée par les scripts de build.

Maintenant, il faut savoir comment fait-on pour la suite, parce qu'il faut bien garder en tête que tu modifie jBuildTools, qui n'est donc pas censé être spécifique à Jelix. Donc :

• soit on fait quand même un truc spécifique à Jelix, comme tu as fait, c'est à dire donc que jBuildTools sait manipuler ces fichiers properties à la manière "jelix"
• soit un fait un truc plus générique comme par exemple un truc comme l'explication suivante.

Actuellement, la syntaxe des lignes est

 flag nom_fichier (nom_fichier_genere)

le nom_fichier_genere étant facultatif. On pourrait supporter une syntaxe spécifique pour les lignes des fichiers à convertir, où le nom_fichier_genere pourrait contenir une morceau comme "%charset%", qui serait remplacé par le nom du charset cible.

  cch truc.UTF-8.properties (truc.%charset%.properties)

Il manque peut être un autre truc : informer à jManifest, par un paramètre ou autre quel est le charset d'origine des fichiers.

Donc j'hésite entre faire un truc spécifique (plus simple), et un truc générique (donc utilisable dans d'autres projets, et pour d'autres fichiers autres que les fichiers properties de jelix).

Au fait, ton patch ne contient pas la suppression de tout les fichiers properties devenus inutiles.

[Lipki]

Ma première idée était d'ajouter les charset dans le fichier ini.

MAIN_TARGET_PATH = _dist
PACKAGE_TAR_GZ = 1
PACKAGE_ZIP = 1

[charset]

ch1 = "ISO-8859-1"
ch2 = "ISO-8859-15"
ch3 = "UTF-8"

Mais comme tu le dit je n'ai penser qu'a Jelix.

informer à jManifest, par un paramètre ou autre quel est le charset d'origine des fichiers.

Je ne sait pas si c'est indispensable, dans le patch actuel le charset d'origine est détecter, je ne sait pas a quel point cette détection est fiable, mais je pense que cela suffit.

Au fait, ton patch ne contient pas la suppression de tout les fichiers properties devenus inutiles.

Non, je ne l'ai fait que sur un dossier, pour l'exemple, mais je vais le faire sur tousse pour finir.

[laurentj]

Ma première idée était d'ajouter les charset dans le fichier ini.

pas de cette façon, c'est trop lourd

Ce serait mieux d'avoir

  PROPERTIES_CHARSET_TARGET = "UTF-8, ISO-8859-1, ISO-8859-15" 

Je ne sait pas si c'est indispensable, dans le patch actuel le charset d'origine est détecter,

oui j'ai pas fait gaffe. Mais pas sûr que mb_detect_encoding soit fiable. La détection de charset n'a jamais été une science exacte. En tout cas, il vaut mieux lui indiquer la liste des charsets (paramètre encoding_list à la fonction).

[Lipki]

Et pourquoi ne pas faire comme ça

cch truc.UTF-8.properties[charset=UTF-8] (truc.%charset%.properties)

Après le nom du fichier, on ajoute entre crochet des méta données, ça permet d'être très générique.

"cch" peut-être une fonction avec en paramètre ce qui ce trouve entre [], d'une certaine manière c'est un système de plugin pour jManifest.

Je pousse le bouchon un peut plus loin.

---

PROPERTIES_CHARSET_TARGET = "UTF-8, ISO-8859-1, ISO-8859-15"

cch[charset=UTF-8] truc.UTF-8.properties (truc.%charset%.properties)

resultat :

truc.UTF-8.properties
truc.ISO-8859-1.properties
truc.ISO-8859-15.properties

---

cch[charset=UTF-8; list=ISO-8859-1, ISO-8859-15] truc.UTF-8.properties (truc.%charset%.properties)

resultat :

truc.ISO-8859-1.properties
truc.ISO-8859-15.properties

[Lipki]

Bon dans ce nouveau patch, il y a le paramètre PROPERTIES_CHARSET_TARGET.

PROPERTIES_CHARSET_TARGET = "UTF-8, ISO-8859-1, ISO-8859-15"

Le cch pour remplacer le #.

le nom de fichier cible avec le 'charset' dedans.

cch autherror.UTF-8.properties(autherror.charset.properties)

J'ai pas mis '%charset%' car ça fait une erreur dans la regex principal, et je préfère pas jouer avec cette regex.

Fatal error: Uncaught exception 'Exception' with message 'build/manifests/jelix-lib.mn : syntax error on line 286
' in C:\wamp\www\jelixbuild\build\lib\jManifest.class.php:127
Stack trace:
#0 C:\wamp\www\jelixbuild\build\buildjelix.php(202): jManifest::process('build/manifests...', '.', './top/', Array, '', true)
#1 {main}
  thrown in C:\wamp\www\jelixbuild\build\lib\jManifest.class.php on line 127

L'encodage est toujours auto détecter, j'attends ton avis pour les[]

cch truc.UTF-8.properties[charset=UTF-8] (truc.%charset%.properties)
// ou
cch[charset=UTF-8] truc.UTF-8.properties (truc.%charset%.properties)
// ou ??

[laurentj]

version 2 du patch

[laurentj]

j'ai corrigé 2-3 trucs, et ajouté le support du paramètre de conf DEFAULT_CHARSET qui permet de spécifier le charset des fichiers traités. Ainsi on n'a pas à l'indiquer dans le manifest. J'ai aussi rétabli le %charset%.

Pas intégré dans le trunk car il y a des problèmes d'accés sur le svn sur berlios.de. Le patch n'intègre pas la suppression des fichiers de locale, car il faut plutôt faire un svn delete sur ceux-ci.

[laurentj]

Patch intégré dans le trunk. Merci pour ce patch :-)

[Lipki]

a cool je suis content que ce patch soit intégrer :)