SME et nouveau système de traduction : avez vous des infos ?

par **sibsib** » 07 Avr 2008 11:14

Hello,

Apparemment, SME devrait changer assez sérieusement son mode de traduction des contributions: passage d'un système assez propriétaire vers un système plus standard de fichiers .po (qui sont les fichiers sources et .mo (qui sont les fichiers utilisés par les applications).

Je viens de passer un bon moment à chercher des infos sur contribs.org, mais nada, rien d'exploitable.

Concrètement, je cherche deux informations :
1) Est ce que çà concerne la version 7.X, ou uniquement la version 8 ?
2) Existe-t-il un peu de doc pour les pôvres contributeurs (ecoeurés), ou alors la seule réponse est 'please post to the bugtracker' ?

Merci,
Pascal, futur ex contributeur...

par **unnilennium** » 07 Avr 2008 18:06

le seul truc que je puisse dire c'ets que si tu mets ta contribs sur le repo smecontribs la communauté se charge d'adapter la modif de traduction.

JPP

par **ecureuil1** » 07 Avr 2008 18:46

po et mo c'est gettext.

C'est gettext que j'ai utilisé pour le site web de mgetty/vgetty

pour faxviamail aussi d'ailleurs... je n'avais pas le courage de mettre formagick!

anne

par **sibsib** » 07 Avr 2008 21:16

unnilennium a écrit:le seul truc que je puisse dire c'ets que si tu mets ta contribs sur le repo smecontribs la communauté se charge d'adapter la modif de traduction.

JPP

Voui, et si mon caractère franco-gaulois s'oppose à l'hébergement de mes contribs chez mes amis censeurs, je fais quoi ?

Ceci dit, çà va se finir comme çà, c'est insensé, cette histoire ! Je vais jeter l'éponge, et il y a bien quelqu'un qui déposera mes contribs sur contribs.org.

M'enfin quand même, il n'y a pas moyen de savoir ce qu'on développe ?

Complètement ***** BBBIIIIIIIIIIIIIPPPPPPPPPPPP ***** cette histoire :-(

A+,
Pascal

par **sibsib** » 07 Avr 2008 21:18

ecureuil1 a écrit:po et mo c'est gettext.

C'est gettext que j'ai utilisé pour le site web de mgetty/vgetty

pour faxviamail aussi d'ailleurs... je n'avais pas le courage de mettre formagick!

anne

Oui Anne, je connais po et mo, que je fréquente sur d'autres projets disons ... moins élitistes ;-)

La question est plutôt :

Comment écrit-on une contrib maintenant, que doit-on faire pour qu'elle fonctionne sur les versions anciennes et actuelles (çà, je sais que c'est -encore- une question tabou chez contribs.org : on passe toujours à la dernière version, dès que disponible), toussa, toussa...

A+,
Pascal

par **unnilennium** » 08 Avr 2008 00:45

je trouves juste dommage de pas faciliter l'installation de tes contribs en les mettant directement sur un repo yum ?

Je serais pas contre la mise en place d'un repo francophone, j'avais même proposé de l'héberger sur mon serveur ovh mais y'a pas eu de suites.

Deux choses qu'on déplore pas mal avec Ecureuil c'est :
1- souvent on manque d'info sur le role d'une contrib
2- il faut courir sur le site perso de chacun et dans les dossiers perso de contribs.org pour dénicher qq chose.

JPP

par **sibsib** » 08 Avr 2008 21:04

Hello,

Ne mélangeons pas tout :

Je n'ai rien contre le fait de mettre des contribs à un endroit facilement accessible. Il se trouve que pour moi, la machine la plus accessible est la mienne ;-)

Ce que je trouve scandaleux, c'est une modification majeure (et sans doute justifiée, là n'est pas la question) sur SME, et l'équipe de dev qui dit tranquillement :

Mettez vos contribs chez nous et on vous aidera à les mettre à jour. Gardez lze chez vous et allez vous faire voir...

Il vaudrait 100 fois mieux que les gens qui savent comment çà marchent documentent le bébépour qu'on puisse continuer de contribuer comme avant.
La prise d'otage, on est un peu loin de la Somalie, non ?

A+,
Pascal

par **jibe** » 08 Avr 2008 22:39

Salut,

On peut comprendre que contribs(.org) cherche à rassembler un peu les contribs(utions) pour que tout soit centralisé. Effectivement, la remarque d'unnilennium est juste : pas facile de savoir ce qui existe comme contribs "sauvages", et le mieux placé pour fédérer tout ça est bien évidemment celui qui fait la distrib... Cela d'ailleurs peut permettre de faire respecter une certaine unité et une certaine qualité dans les contribs proposées.

Mais d'un autre côté, je croyais que SME était une distrib "libre". Or, "l'invitation" à mettre les contribs chez eux ressemble étrangement, comme dit sibsib, à de la prise d'otage. Et s'il y a d'excellents membres dans l'équipe contribs, il y en a aussi qui font un peu n'importe quoi avec les contribs qui leur sont confiées. On peut comprendre que tous les auteurs n'apprécient pas...

Et puis, la philosophie du logiciel libre ne m'a jamais paru être la rétention d'information pour garder le monopole... Ca me fait penser à un autre éditeur qui prétend s'ouvrir aux logiciels libres et aux formats non propriétaires, mais qui ne fait en fait que jeter de la poudre aux yeux et fait tout pour conserver ses prérogatives... D'ailleurs, son OS et SME ont en commun l'obligation de rebooter chaque fois qu'on installe une bricole :twisted:

Bref, j'apprécie en général assez peu que certains fassent leur salade dans leur coin quand une équipe tente de rassembler les énergies et d'organiser un peu le travail. Mais la façon dont ils s'y prennent chez contribs ne peut qu'amener les auteurs à aller voir ailleurs... Et retenir l'info n'incite pas à respecter certaines normes, ce qui va faire qu'il y aura de plus en plus de contribs qui manquent de cohérence avec l'ensemble. Ou pire, de moins en moins de contribs pour SME et de plus en plus pour ClarkConnect ou autres... C'est quand même extrêmement dommage :cry:

par **ecureuil1** » 09 Avr 2008 00:13

jibe a écrit:Salut,

Et puis, la philosophie du logiciel libre ne m'a jamais paru être la rétention d'information pour garder le monopole... Ca me fait penser à un autre éditeur qui prétend s'ouvrir aux logiciels libres et aux formats non propriétaires, mais qui ne fait en fait que jeter de la poudre aux yeux et fait tout pour conserver ses prérogatives... D'ailleurs, son OS et SME ont en commun l'obligation de rebooter chaque fois qu'on installe une bricole

Moi, c'est Cactus, une personne de Contibs qui m'a dit qu'il fallait absolument rebooter.
Leur fameux : ' signal-event post-upgrade; signal-event reboot' après chaque yum.

Que mon fils fasse un reboot de son serveur quand il ne sait quel service il faut redémarrer, je comprends. Mais une personne qui est sensée connaitre sme et liniux, là je ne comprends pas vraiment.

anne

par **unnilennium** » 09 Avr 2008 00:46

@Ecureuil1

SME est une distrib simplifiée pour les administrateurs novices. D4autre part par manque de temps et donc de moyens, les dev de SME ont du s'orienter par facilité vers l'option on fait rebooter apres une mise a jour ou une installation pour etre sur que tous les services prenent en compte leurs nouveaux fichiers de configuration modifiés apres l'expend des templates.

Bon on est tous d'accord que la commande signal-event reboot est violente quand on a juste un service httpd-e-smith restart peut suffire, mais parfois il y'a un paquet de services à relancer et il est plus simple pour la majorité des novices de faire un reboot.

maintenant je comprends la façon de dire systématiquement faite le signal-event reboot après le post-upgrade.... aprés a charge aux administrateurs averti de tenter de faire sans mais si ca marche pas ... reste à le faire .

@Jibé et Sibsib

Effectivement le dialogues peut paraitre un peu rude... l'absence d'info difficiles, et surtout l'absence de doc, mais quand elle n'est pas la la doc on peut essayer de la produire ... dés qu'on a les infos . pour le moment tout fonctionne sans alerte ... nous aviserons .. non ?

Bon en attendant j'ai posté sur la dev liste ... peut être une réponse en vue.

JPP

par **sibsib** » 09 Avr 2008 14:33

Hello, JPP,

Ben ton post a été productif :-)

En résumé (et à ce qu j'ai compris) :

* SME a choisi de mettre en place un outil (pootle) pour rendre le portage de SME en multi-langue nettement plus aisé.
* Pootle qui se base dur des fichiers .po (sources) et .mo ('compilés') pour la gestion des langues est conçu à la base pour fonctionner en UTF-8. SME a toujours été pensé en ISO-8859-1
* La devteam a considéré que le passage à UTF-8 était un bon choix, même s'il va être synonyme de pas mal de petits désagréments pour les logiciels déjà internationalisés : quitte à mettre de nouveaux outils de traductions en place, autant les mettre avec ce qui semble être aujourd'hui le vrai standard d'internationalisation. De plus, çà ouvre d'autres portes, puisque par exemple, çà permet de gérer les caractères grecs.

Donc, SME 8 sera UTF-8, et SME 7.3 (oui, oui, 7.3 !) le sera aussi. (En vrai, j'espère tout de même qu'une fois releasé, la devteam numérotera cette version 7.4, même si c'est le seul changement. Pour le moment, en test, çà reste une 7.3).

Un certain nombre de packages ont déjà été mis à jour (dans testing).

Je vous transfère les liens qui nous ont été fournis par Jonathan (in English, oeuf corse).

http://translate.contribs.org/
http://bugs.contribs.org/show_bug.cgi?id=3858
http://bugs.contribs.org/show_bug.cgi?id=4139

Le point qui ne (me) parait pas clair : passant en UTF-8, mais spécifiant le type de jeu de caractères dans les fichiers, je comprends mal pourquoi les fichiers encodés en ISO-8859-1 ne passent pas, même si ceci ne devrait se faire que pendant une phase de transition...

Donc, il me semble que les contribs devront exister dans les deux formats pendant quelques temps. Le boulot semble finalement assez light (un programme nommé iconv semble en mesure d'assurer la conversion des fichiers en automatique).

Mais pourquoi cacher une information aussi critique au fond du bugtracker ?

Note pour les auteurs de contribs pas standard SME (je pense notamment aux panels de Firewall services, mais il doit y en avoir d'autres) :
Le navigateur reçoit maintenant ses informations en UTF-8. Donc si un panel exotique est lui en ISO-8859-1, çà va être la fête aussi... Ne vous croyez pas à l'abri ;-)

(Bref, je râle :-)

)

A+,
Pascal

par **sibsib** » 09 Avr 2008 15:05

Hello,

J'ai oublié un truc super important :-)

En fait, bien qu'utilisant pootle, les fichiers de traductions restent des fichiers xml comme avant, positionnés au même endroit dans l'arborescence.

A+,
Pascal

par **Muzo** » 09 Avr 2008 19:03

sibsib a écrit:Le point qui ne (me) parait pas clair : passant en UTF-8, mais spécifiant le type de jeu de caractères dans les fichiers, je comprends mal pourquoi les fichiers encodés en ISO-8859-1 ne passent pas, même si ceci ne devrait se faire que pendant une phase de transition...

En passant de iso-8859-* à UTF-8 tu ne change pas que ton jeu de caractères, tu changes aussi l'encodage du fichier, tu modifies la nature du fichier.
Si tu ne changes que le jeu de caractères (sans changer la nature du fichier qui reste DOS/UNIX-ASCII), et que tu dis à un logiciel, prend ces jeux de caractère, tu vas te retrouver au mieux avec des ? à la place des caractères acdentués, au pire avec des zigouigoui incompréhensibles.

Car tout éditeur/logiciel doit savoir que le fichier qu'il va ouvrir contient des caractères dont la taille (en binaire) est variable.

Pour avoir fait une migration de tout un site web (java+html) de iso vers UTF-8, cela ne se fait pas sans risques, et c'est très lourd, car tu dois modifier la nature de ton fichier.

/Muzo

par **unnilennium** » 09 Avr 2008 19:03

bon au pire on commence a être habitué et a traduire de nous même les problemes de charsets : une solution peut être d'encoder tous les caractères spéciaux en langage html poru ce qui est du serveur manager.

les caract�res peuvent poser probl�me on peut lire malgr�s tout...

par **sibsib** » 09 Avr 2008 20:44

Muzo a écrit:
sibsib a écrit:Le point qui ne (me) parait pas clair : passant en UTF-8, mais spécifiant le type de jeu de caractères dans les fichiers, je comprends mal pourquoi les fichiers encodés en ISO-8859-1 ne passent pas, même si ceci ne devrait se faire que pendant une phase de transition...

En passant de iso-8859-* à UTF-8 tu ne change pas que ton jeu de caractères, tu changes aussi l'encodage du fichier, tu modifies la nature du fichier.

Oui, Exact, Muzo, je me suis mal exprimé :

Si SME passe en encodage UTF-8, il faut que tout ce sui est présenté le soit en UTF-8.

Maintenant, puisque (dans le cas qui me préoccupe, c'est à dire dans les panels) FormMagick semble être en mesure de faire la différence (ou alors je suis trop optimiste ?), alors FormMagick pourrait ouvrir un fichier XML, lire dans ce fichier que c'est de l'ISO-8859-1, et transcoder les données à la volée en UTF-8.

Mais bon, traitement supplémentaire, donc bugs possibles supplémentaires...

Il vautpeut-être mieux 'transitionner sec' :-)

A+,
Pascal

SME et nouveau système de traduction : avez vous des infos ?

SME et nouveau système de traduction : avez vous des infos ?

Qui est en ligne ?