Re: Problems commiting damned-lies package

[Emmanuele Bassi <ebassi gmail com>]

Hi Alexandre;

thanks for the reply.

On Tue, 23 Jun 2020 at 18:30, Alexandre Franke <afranke 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]