Hi Alexandre; thanks for the reply.
On Tue, 23 Jun 2020 at 18:30, Alexandre Franke <afra...@gnome.org> wrote: > Hi Emmanuele, > > As I mentioned in the other thread this conversation has become quite > dense and it would be hard for me to address everything that has been > said, but I thought you should know that the people pushing for Damned > lies to be kept are in line with your position. > I'm glad that there's at least a rough consensus on that. I appreciate the work that has been put into making DL work across the whole GNOME project, and if that's the best approach to translating GNOME components, I'm all for it. > On Mon, Jun 22, 2020 at 1:13 PM Emmanuele Bassi via gnome-i18n > > The fact that DL pushes to the main development branch *also* irks me to > no end; > > Agreed. In a better world once the “Ready to commit” state is reached > on DL, the “Submit to repository” action would instead open a merge > request and display it’s state in the DL workflow. That MR would allow > for CI to run. Once CI passed, I suppose the MR could be automatically > merged and the DL workflow archived? > > That would be great. As I said, GitLab even has that baked into the `git push` workflow through push options. If Damned Lies is just calling `git`, it can move to a merge-request based workflow today, with minimal cost. > > If people spent time improving Damned Lies instead of working around it > with their own scripts, > > we would probably have a better tool already. > > I somewhat agree, although poor translators who DIY their own scripts > doesn’t necessarily make developers that can extend something like > Damned lies (or Weblate, or whatever other platform). It is a > recurring issue that translators are not developers and we fail to > attract developers to tackle our issues. > Development is a part of the improvement process, but it's completely understandable. The infrastructure in GNOME is generally under-resourced—which is another reason why we moved to a "turn key" solution like GitLab. > > Or, maybe, a better tool already exists, and we should move to it. > > DL is the better tool in the bigger picture of i18n platforms, and I’m > pretty sure no other tool is able to do what we were talking about > above (regardless of other features like online translations). > That's good to know. Now while I can’t commit right now to addressing all the other points > made in this thread, I do have a proposal. GUADEC is in a few weeks. I > can prepare a BoF session around planning improvements to the GNOME > translation experience. The translation BoF at GUADEC is a regular > event but sadly it is usually always the same participants and > content, which mostly consists of making wish lists or rehashing the > same issues. I have been one of these participants and I’m not blaming > any of them for not making significant progress. > > Emmanuele, would you be able and willing to attend this session? As a > developer, CI caretaker and maybe even Foundation representative, your > insights would be greatly appreciated. > I'd be happy to attend, and expand on what a modern workflow for GNOME project entails. My main concern is trying to get translations of UI and documentation into the general trajectory that GNOME set upon; I don't have a horse in the race, and I don't really have any preference for localisation tools. What I want is to get my software in the hands of our users in a working state, and that requires changes not just in how developers and maintainers work, but also in how people translating and documenting GNOME work. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com]
_______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
