Since pelican 3 supports multilingual content, why do we have two git repositories “webstie_fr” and “website_en” ? Would’nt it be nice to fuse them ?
It has been historically been built like this.
If you want to work on it, I could help, I would be glad to.
The idea behind is to have two websites making their own ways.
I would prefer to have one original language and translate the others from using Weblate tool.
1 Like
It is not easy to maintain a multi-language site. My experience with the RTM and Ğeconomicus is there to prove it. Because you do not choose the frequency of the work. And every time you change the original language, you need to verify the builds of the translated versions.
The decision to separate the two sites allow to translate only important articles, so is more easy to maintain.
On the RTM, we do not use weblate anymore (it was buggy, then down…). @jytou use a po editor I think. It is faster.
So you can do it if you want, but do not slow the french contributors on the french version, and just have in mind the hard work it is.
3 Likes
I’m perfectly aware of the difficulty to maintain a multilingual website. But I think it would be far easier to have a single site with optional translation.
And I think it is worth it if we want to translate it in esperanto
1 Like
Merci de continuer d’en parler ici au lieu de sur Masto pour qu’on en discute.
2 Likes
Instancié de cette manière ça me dérange moins que la dernière fois qu’on l’avait mis en oeuvre (il me semble qu’on utilisait de véritables fichiers de traduction, c’était vriament compliqué).
La, c’est juste des fichiers anglais posés à côté des fichiers français. Ca me parait pas mal.
1 Like
Le principal souci, c’est celui dont je parle ici : la compatibilité avec pelican-page-hierarchy.
La 2eme solution me semble bien. La 3eme pourquoi pas, mais il faudrait que ça soit réintégrer au plugin d’origine pour qu’on ait pas à le maintenir ensuite 
Oui, c’est celle à adopter pour l’instant. La 3 fonctionne si pélican-page-hierarchy accepte les modifications pour le multilingue.
(En attendant, c’était plus facile de faire la 1 automatiquement)
Le problème, c’est qu’en cas de conflit, même si on a la bonne URL, le breadcrumb ne fonctionne plus. Faut voir si c’est acceptable en production ou si on attend de résoudre ça.
Quand est-ce qu’on peut merge ça à votre avis ? Je fais une pull request tout de suite et on met en production ou il manque quelques trucs ? (genre la mise en prod automatique)
Ta PR est un peu grosse.
Faut qu’on y jette un œil attentif.
Et dans, dans le futur, faut qu’on utilise GitLab Pages pour générer le site.
1 Like
Je vais regarder comment marche GitLab pages. J’ai forké l’exemple pour pelican (https://hugo-trentesaux.gitlab.io/pelican/), mais je ne sais pas encore comment installer plantuml par exemple (il faudrait accéder au docker). Et oui, je veux bien qu’on jette un coup d’œil ensemble avant de mettre ça en production.
Plus qu’y jetter “un œil attentif” il faudrait surtout déployer un site de test sur genre test-site.duniter.org afin de ne plus prendre de risque.
On s’est déjà tapé la honte sur linuxfr… Le site duniter est beaucoup consulté tout les jours a toutes les heures de la journée, c’est une folie de continuer à déployer directement dessus comme on l’a toujours fait, il est temps de mettre en place un site de test !
2 Likes
Je comprends pas bien l’erreur du job GitLab pages
console du job (pas de problème à l'installation des dépendances)
Running with gitlab-runner 10.8.0-rc3 (5470b911)
on docker-auto-scale e11ae361
Using Docker executor with image python:2.7-alpine ...
Pulling docker image python:2.7-alpine ...
Using docker image sha256:5fdd069daf25f69ca2cea5dbf4461e9663f8dd6caaab5bd96439b0b16e8958a0 for python:2.7-alpine ...
Running on runner-e11ae361-project-6426436-concurrent-0 via runner-e11ae361-srm-1526729755-43426500...
Cloning repository...
Cloning into '/builds/Hugo-Trentesaux/pelican'...
Checking out 1d7c3f5d as master...
Skipping Git submodules setup
$ pip install -r requirements.txt
Collecting pelican (from -r requirements.txt (line 1))
Downloading https://files.pythonhosted.org/packages/82/62/6a81e2f2c8f20a80643d78ed93de42813c4decc0e3fc341e76106e0f881b/pelican-3.7.1-py2.py3-none-any.whl (134kB)
Et juste un petit warning à la fin :
warning
$ pelican -s publishconf.py
Done: Processed 23 articles, 19 drafts, 24 pages and 35 hidden pages in 6.00 seconds.
Done: Processed 37 articles, 5 drafts, 52 pages and 7 hidden pages in 13.40 seconds.
Done: Processed 37 articles, 5 drafts, 52 pages and 7 hidden pages in 20.50 seconds.
Uploading artifacts...
WARNING: public/: no matching files
Uploading artifacts to coordinator... ok id=69274126 responseStatus=201 Created token=JNELaE3x
Job succeeded
La “compilation” passe, mais le déploiement pas…
[edit] c’était un peu laborieux et je suis vraiment débile, mais voilà le site compilé et servi par GitLab pages https://hugo-trentesaux.gitlab.io/pelican/ (toujours sans platuml)[/edit]
Je plussoie le test avant de déployer sur le site officiel.
J’aimerais bien prendre les choses en main. Pour cela, j’ai besoin de votre avis @cgeek @elois @Moul @Inso sur les points suivants :
- Est-il pertinent d’avoir un site multilingue (chaque langue pouvant toujours se développer indépendamment
- Est-ce que la façon dont je l’ai fait (avec le plugin i18n) est maintenable
- Quel échéancier peut-on se fixer
Deuxièmement, nous souhaitons à tout prix éviter les erreurs comme la “honte” citée plus haut. Pour ça, on propose un déploiement automatique avec GitLab pages sur un site de test, et un déploiement manuel régulier vers le site officiel.
Il faut donc faire les choses suivantes :
- corriger le bug page-hierarchy/i18n
- documenter les conventions d’édition du site mieux que ce que j’ai fait
- ajouter un nom de domaine “test.duniter.org” par ex et le lier aux GitLab pages
- résoudre le problème de plantuml (peut être compiler les graphiques à part, ça ne me paraît pas absurde)
- s’organiser pour le déploiement manuel vers le site officiel duniter.org
Je n’ai pas beaucoup de temps, mais je veux bien le consacrer à ça si je sais que c’est utile. Je ne vais pas m’acharner à faire un site multilingue si vous n’avez pas envie de vous en servir. Mais je pense que ce serait vraiment bénéfique à duniter de profiter de la communauté esperanto, et le meilleur moyen que je trouve d’y arriver est de traduire le site en esperanto.
Je pense que ça fait beaucoup d’un coup de rendre le site multilingue et de gérer son déploiement avec GitLab Pages.
Il faut faire les deux séparément et de manière méthodique.
De plus, notre objectif premier est de libérer un serveur mourant sur lequel se trouvent le site, le serveur XMPP et Weblate et de les migrer sur notre autre serveur.
Donc, dans un premier temps, je mettrais en priorité la migration du site web, avec le déploiement GitLab Pages, puis la gestion du multilingue (à savoir l’ajout de l’espéranto) qui est bien moins prioritaire, bien que je sois très en faveur pour cette langue.
Pour la migration, il faut prendre en considération que le serveur XMPP et le site doivent être migrés en même temps, car ils dépendent du même enregistrement DNS.
Pour la migration du site, on peut voir deux possibilités, migrer le fonctionnement actuel sur notre autre serveur ou implémenter le déploiement GitLab Pages.
Actuellement, il y a disons que moi qui s’occupe du site. Donc, que moi qui pourrais reviewer ton travail, bien que j’ai aussi d’autres priorités en vue.
Voilà, pour l’état des lieux actuel.
J’ai une question concernant la gestion du multilingue de Pelican.
Actuellement, des redirections en fonction de la langue du navigateur est gérée au niveau d’un vhost ngnix.
Pelican, gère ça nativement avec i18n ? et tout le code serait dans le même dépôt git ?
J’ai survolé tes modifications, mais c’est être sûr de ce dont on parle.
1 Like
Oui je suis d’accord, idéalement il faudrais deux job de déploiement, un sur le site de test en automatique puis un sur le site de prod en manuel. Gitlab-ci permet de gérer finement ça donc normalement c’est possible, j’ai juste un doute sur la possibilité d’avoir deux job pages différents, @1000i100 tu en pense quoi ?
Installation de plantuml pour le plugin pelican :
1 Like
J’en pense qu’un rsync pour faire le déploiement, (ou un git pull en ssh) ça marche bien aussi, du coup, rien ne nous empèche d’avoir un job pages en auto, et un déploiement custom déclenchable en 1 clic.
1 Like