Pour organiser une traduction collaborative de fichiers tels que celui que tu as cité (php, po...), voici un système qu'on utilise pour traduire Anwiki lui-même, mais aussi des applis externes.
Ca demande un minimum de temps à mettre en place, mais ensuite c'est très efficace :
1) Import initial des fichiers de trad vers Anwiki :
Il s'agit de faire un script qui va rechercher tous les fichiers de trad dans une langue donnée, en extraire une liste d'associations clés-valeurs et les injecter dans Anwiki.
2) Traduction collaborative des fichiers :
Les traducteurs qui se connectent à Anwiki voient et traduisent ces contenus exactement comme ils le font pour autres contenus.
De plus, aucun risque qu'un traducteur "casse" ou détourne un fichier, ou que des chaines soient oubliées, vu qu'on édite un contenu structuré et synchronisé.
J'ai repris ton exemple ici : http://demo.anwiki.com/fr/trfile (passe en mode "translate", puis "edit")
3) Export des traductions :
Un script va retransformer les contenus traduits d'Anwiki vers le format initial des fichiers de trad.
Cet export peut être déclenché dès qu'un traducteur enregistre une modification, ou simplement se faire manuellement.
4) Mise à jour des fichiers de traduction originaux :
Lorsque les fichiers de traduction originaux ont changé, on réexécute le script d'import réalisé en 1).
Ce script va repérer qu'ils ont déjà été importés, et va faire une mise à jour "intelligente", exactement comme si tu éditais les contenus depuis Anwiki.
Il va repérer les changements effectués, et resynchroniser en conséquence les traductions déjà effectuées.
Les clés nouvelles ou modifiées seront marquées comme non traduites, les clés supprimées seront supprimées des traductions.
S'il y a des nouvelles chaînes à traduire, les traducteurs seront alertés par RSS et repassent à l'étape 2).
Pour la réalisation du script évoqué en 1), on a un script générique qu'il suffit d'étendre par héritage, pour indiquer :
- comment trouver les fichiers de trad sur le disque (spécifique à chaque usage)
- comment extraire les associations clés-valeurs, et comment effectuer l'opération inverse pour exporter les traductions. Le script sait déjà le faire pour les tableaux php et les fichiers po.
Ce script n'est pas inclus dans la release, il sera distribué à part en tant que composant.
Effectivement, une ancienne règle de filtrage était encore active... ça devrait passer maintenant.
N'hésitez pas à proposer vos idées d'amélioration, le mode de fonctionnement du système n'est pas encore figé. Je réfléchis notamment à la possibilité d'intégrer un processus de relecture/validation. Actuellement tous les traducteurs sont au même niveau, le dernier qui édite l'emporte.
Merci pour cet excellent résumé, je ne m'attendais pas à être publié si rapidement :-)
J'ajoute un lien vers une démo en ligne qui vous permet de tester les fonctions multilingues ( édition, traduction, gestion des contenus) : http://demo.anwiki.com
Hébergé sur TuxFamily depuis quelques mois, je tiens à souligner la qualité des services proposés et le professionnalisme de l'équipe. TuxFamily réunit vraiment les conditions idéales pour le lancement d'un projet libre en toute sérénité :)
Je précise qu'on peut effectuer des dons immédiatement via Paypal - perso je n'avais pas remarqué le lien.
Loin de moi l'idée de créer un troll, je pose cette question car j'envisage justement d'adopter la licence AGPL pour une appli web que je développe.
J'ai parcouru la licence mais je ne suis pas spécialiste du domaine, alors je me renseigne.
Ma question est bien plus générale que les mots de passe dans la configuration, je m'intérroge sur les limites de la personnalisation de l'appli, prévue et acceptée par l'auteur.
Désolé, je ne savais pas dans quel sens prendre ta remarque :)
Il ne me semble pas que le cas de la configuration/personnalisation soit explicite dans le texte de l'AGPL ; ça me conforte dans l'idée que la licence est compliquée à mettre en oeuvre pour des applis web classiques.
Il faut bien mettre ces mots de passe quelque part (connexion BD). Très souvent, un fichier de conf se résume à du code qui initialise des variables. Or, tout code source modifié sur un serveur publique doit être redistribué... la licence ne fait pas la différence.
Et quid des templates ? Qui va vouloir redistribuer ce qui fait l'identité de son site web ?
Concrètement, je vois mal comment cette licence peut être appliquable à une application web du style CMS, système de forums ou d'e-commerce.
Ce genre d'applications nécessite généralement d'éditer des fichiers de configuration, de personnaliser des templates... Ces modifications aussi minimes soient-elles devront être rendues publiques.
Ne faudrait-il pas trouver un juste milieu entre la modification du coeur de l'application, et sa personnalisation/intégration ?
...your modified version must prominently offer all users interacting with it [...] an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server[...]
Connaissez-vous des exemples de mécanismes permettant de transmettre le code source modifié ?
Merci pour tes liens, ils sont intéressants (mais j'avoue que je n'ai pas encore tout lu).
J'ai jeté un coup d'oeil à Wikini, sa simplicité et son organisation du code me plaisent beaucoup !
Par contre, il y a des textes français en dur un peu partout, ça représente un travail considérable de les extraire. Sais-tu si quelqu'un a déjà commencé de ce côté là ? Le projet Wikini est-il lui-même toujours actif ? (la dernière release semble dater du 2004-11-25)
Sinon, j'ai aussi essayé WackoWiki. Bon point, les chaînes en dur ont été sorties dans des fichiers de traductions, mais pas mal de fonctions inutiles ont été ajoutées.
Enfin, je n'ai pas vu de grosse différence entre Wikini et Wikkawiki. Je finis par m'y perdre entre tous ces wako/wikka/wakka wiki, connais-tu un lien qui les compare ou résume leurs différences ?
Je vais à priori m'orienter vers Wikini, pour lequel j'essaierai de développer un module permettant de traduire facilement une page. Mon idée première est de permettre la traduction des contenus phrase par phrase, sans toucher aux codes de mise en forme.
Ainsi, le traducteur pourra se concentrer sur sa traduction et les pages devraient rester homogènes.
Je te tiendrai au courant si mon projet se concrétise...
Effectivement, TikiWiki semble être l'un des seuls wikis à gérer de façon native les contenus multilingues.
Malheureusement, il me paraît bien lourd pour l'utilisation que j'en ferais et j'ai quelques doutes sur la qualité de son développement (sur dokuwiki.org, on peut voir une moyenne de 200 requêtes SQL par page, ça me paraît complètement démeusuré !).
Il ne semble exister aucune solution permettant une vraie synchronisation des contenus multilingues, je vais peut-être essayer de développer un tel outil.
[^] # Re: Démo en ligne
Posté par anw . En réponse à la dépêche Publication de Anwiki 0.1.0 alpha 1. Évalué à 3.
Ca demande un minimum de temps à mettre en place, mais ensuite c'est très efficace :
1) Import initial des fichiers de trad vers Anwiki :
Il s'agit de faire un script qui va rechercher tous les fichiers de trad dans une langue donnée, en extraire une liste d'associations clés-valeurs et les injecter dans Anwiki.
2) Traduction collaborative des fichiers :
Les traducteurs qui se connectent à Anwiki voient et traduisent ces contenus exactement comme ils le font pour autres contenus.
De plus, aucun risque qu'un traducteur "casse" ou détourne un fichier, ou que des chaines soient oubliées, vu qu'on édite un contenu structuré et synchronisé.
J'ai repris ton exemple ici : http://demo.anwiki.com/fr/trfile (passe en mode "translate", puis "edit")
3) Export des traductions :
Un script va retransformer les contenus traduits d'Anwiki vers le format initial des fichiers de trad.
Cet export peut être déclenché dès qu'un traducteur enregistre une modification, ou simplement se faire manuellement.
4) Mise à jour des fichiers de traduction originaux :
Lorsque les fichiers de traduction originaux ont changé, on réexécute le script d'import réalisé en 1).
Ce script va repérer qu'ils ont déjà été importés, et va faire une mise à jour "intelligente", exactement comme si tu éditais les contenus depuis Anwiki.
Il va repérer les changements effectués, et resynchroniser en conséquence les traductions déjà effectuées.
Les clés nouvelles ou modifiées seront marquées comme non traduites, les clés supprimées seront supprimées des traductions.
S'il y a des nouvelles chaînes à traduire, les traducteurs seront alertés par RSS et repassent à l'étape 2).
Pour la réalisation du script évoqué en 1), on a un script générique qu'il suffit d'étendre par héritage, pour indiquer :
- comment trouver les fichiers de trad sur le disque (spécifique à chaque usage)
- comment extraire les associations clés-valeurs, et comment effectuer l'opération inverse pour exporter les traductions. Le script sait déjà le faire pour les tableaux php et les fichiers po.
Ce script n'est pas inclus dans la release, il sera distribué à part en tant que composant.
[^] # Re: Démo en ligne
Posté par anw . En réponse à la dépêche Publication de Anwiki 0.1.0 alpha 1. Évalué à 2.
N'hésitez pas à proposer vos idées d'amélioration, le mode de fonctionnement du système n'est pas encore figé. Je réfléchis notamment à la possibilité d'intégrer un processus de relecture/validation. Actuellement tous les traducteurs sont au même niveau, le dernier qui édite l'emporte.
# Démo en ligne
Posté par anw . En réponse à la dépêche Publication de Anwiki 0.1.0 alpha 1. Évalué à 6.
J'ajoute un lien vers une démo en ligne qui vous permet de tester les fonctions multilingues ( édition, traduction, gestion des contenus) :
http://demo.anwiki.com
[^] # Re: Tuxfamily à Mont-de-Marsans en 2008 ?
Posté par anw . En réponse à la dépêche L'hébergeur TuxFamily appelle les adeptes du libre à soutenir leur initiative. Évalué à 4.
Je précise qu'on peut effectuer des dons immédiatement via Paypal - perso je n'avais pas remarqué le lien.
[^] # Re: Mise en oeuvre
Posté par anw . En réponse à la dépêche Publication de la licence « GNU Affero General Public Licence Version 3 ». Évalué à 3.
J'ai parcouru la licence mais je ne suis pas spécialiste du domaine, alors je me renseigne.
Ma question est bien plus générale que les mots de passe dans la configuration, je m'intérroge sur les limites de la personnalisation de l'appli, prévue et acceptée par l'auteur.
[^] # Re: Mise en oeuvre
Posté par anw . En réponse à la dépêche Publication de la licence « GNU Affero General Public Licence Version 3 ». Évalué à 1.
Il ne me semble pas que le cas de la configuration/personnalisation soit explicite dans le texte de l'AGPL ; ça me conforte dans l'idée que la licence est compliquée à mettre en oeuvre pour des applis web classiques.
[^] # Re: Mise en oeuvre
Posté par anw . En réponse à la dépêche Publication de la licence « GNU Affero General Public Licence Version 3 ». Évalué à 2.
Et quid des templates ? Qui va vouloir redistribuer ce qui fait l'identité de son site web ?
# Mise en oeuvre
Posté par anw . En réponse à la dépêche Publication de la licence « GNU Affero General Public Licence Version 3 ». Évalué à 3.
Ce genre d'applications nécessite généralement d'éditer des fichiers de configuration, de personnaliser des templates... Ces modifications aussi minimes soient-elles devront être rendues publiques.
Ne faudrait-il pas trouver un juste milieu entre la modification du coeur de l'application, et sa personnalisation/intégration ?
Connaissez-vous des exemples de mécanismes permettant de transmettre le code source modifié ?
[^] # Re: tiki-wiki
Posté par anw . En réponse au message Wiki/cms : synchro de contenu multilingue. Évalué à 1.
J'ai jeté un coup d'oeil à Wikini, sa simplicité et son organisation du code me plaisent beaucoup !
Par contre, il y a des textes français en dur un peu partout, ça représente un travail considérable de les extraire. Sais-tu si quelqu'un a déjà commencé de ce côté là ? Le projet Wikini est-il lui-même toujours actif ? (la dernière release semble dater du 2004-11-25)
Sinon, j'ai aussi essayé WackoWiki. Bon point, les chaînes en dur ont été sorties dans des fichiers de traductions, mais pas mal de fonctions inutiles ont été ajoutées.
Enfin, je n'ai pas vu de grosse différence entre Wikini et Wikkawiki. Je finis par m'y perdre entre tous ces wako/wikka/wakka wiki, connais-tu un lien qui les compare ou résume leurs différences ?
Je vais à priori m'orienter vers Wikini, pour lequel j'essaierai de développer un module permettant de traduire facilement une page. Mon idée première est de permettre la traduction des contenus phrase par phrase, sans toucher aux codes de mise en forme.
Ainsi, le traducteur pourra se concentrer sur sa traduction et les pages devraient rester homogènes.
Je te tiendrai au courant si mon projet se concrétise...
[^] # Re: tiki-wiki
Posté par anw . En réponse au message Wiki/cms : synchro de contenu multilingue. Évalué à 1.
Malheureusement, il me paraît bien lourd pour l'utilisation que j'en ferais et j'ai quelques doutes sur la qualité de son développement (sur dokuwiki.org, on peut voir une moyenne de 200 requêtes SQL par page, ça me paraît complètement démeusuré !).
Il ne semble exister aucune solution permettant une vraie synchronisation des contenus multilingues, je vais peut-être essayer de développer un tel outil.