Damned Lies automatic update

[Guillaume Bernard]

Hi all Damned Lies users,

The production instance of Damned Lies has been updated automatically to
integrate the new automated deployment system. We do not expect any issue but,
in case, feel free to fill an issue here:
https://gitlab.gnome.org/Infrastructure/damned-lies/-/issues

For those who remember, this is part of the deployment conversations we had two
months ago.

Thank you all, and happy translation!
--
Guillaume Bernard



signature.asc
Description: This is a digitally signed message part
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies is down

[Yuri Chornoivan via gnome-i18n]

понеділок, 2 травня 2022 р. 12:02:15 EEST Andrea Veri написано:
> Alexander,
> 
> mind verifying now?
> 
> Thanks!

Hi,

Works perfectly for Ukrainian.

Many thanks for your work.

Best regards,
Yuri

> 
> On Sat, Apr 30, 2022 at 11:27 AM Alexander Shopov 
> 
> wrote:
> > Gnome-shell now gave:
> > 
> > An error occurred during applying your action: The commit failed. The
> > error was: “[Errno 128] Command: "['git', 'fetch']", Error: Host key
> > verification failed. fatal: Could not read from remote repository. Please
> > make sure you have the correct access rights and the repository exists. ”
> > 
> > To be on the safe side - I archived the actions and started again. Again
> > the same mistake.
> > 
> > The same happened with gsettings-desktop-schemas
> > 
> > Kind regards:
> > 
> > al_shopov
> > 
> > На сб, 30.04.2022 г. в 10:50 ч. Andrea Veri  написа:
> >> Alexander,
> >> 
> >> thanks for reporting, it should be fixed by now, please confirm, cheers!
> >> 
> >> On Sat, Apr 30, 2022 at 10:36 AM Alexander Shopov 
> >> 
> >> wrote:
> >>> Getting the same when trying to submit Bulgarian translation of
> >>> gnome-shell, I'd presume it is a global thing still missing.
> >>> Kind regards:
> >>> al_shopov
> >>> 
> >>> На сб, 30.04.2022 г. в 10:25 ч. Alexander Shopov 
> >>> 
> >>> написа:
> >>>> I tried uploading the Bulgarian translation of
> >>>> gsettings-desktop-schemas, but I got this error:
> >>>> 
> >>>> An error occurred during applying your action: The commit failed. The
> >>>> error was: “[Errno 128] Command: "['git', 'fetch']", Error: Warning:
> >>>> Permanently added 'gitlab.gnome.org' (ED25519) to the list of known
> >>>> hosts. no such identity: /home/l10n/.ssh/ssh-privatekey: No such file
> >>>> or
> >>>> directory g...@gitlab.gnome.org: Permission denied
> >>>> (publickey,gssapi-keyex,gssapi-with-mic). fatal: Could not read from
> >>>> remote
> >>>> repository. Please make sure you have the correct access rights and the
> >>>> repository exists. ”
> >>>> 
> >>>> Kind regards:
> >>>> 
> >>>> al_shopov
> >>>> 
> >>>> На сб, 30.04.2022 г. в 9:50 ч. 
> >>>> 
> >>>> написа:
> >>>>> And last update :-).
> >>>>> 
> >>>>> The service has been restored as it should at around 1am UTC+2. You
> >>>>> can
> >>>>> use the app normally now.
> >>>>> 
> >>>>> Le 29/04/2022 22:26, Guillaume Bernard a écrit :
> >>>>> > Hi,
> >>>>> > 
> >>>>> > Evening update (from Paris Time :-)). We first had issues with the
> >>>>> > database service which was unable to serve incoming connections from
> >>>>> > Damned Lies. Next, we had another issue with the deployment of the
> >>>>> > application.
> >>>>> > 
> >>>>> > I point out that this is not associated to yesterday runtime update
> >>>>> 
> >>>>> you
> >>>>> 
> >>>>> > may had followed on this mailing list.
> >>>>> > 
> >>>>> > As some of you have seen, two other issues remain: the data storage
> >>>>> 
> >>>>> is
> >>>>> 
> >>>>> > missing. I do not expect any data loss from this side (because the
> >>>>> > storage is still visible and appears okay on the cloud interface).
> >>>>> > We
> >>>>> > also use an old snapshot of Damned Lies that was dumped two years
> >>>>> 
> >>>>> ago.
> >>>>> 
> >>>>> > This is probably the one we use for the staging instance. We should
> >>>>> 
> >>>>> not
> >>>>> 
> >>>>> > have lost any data as well.
> >>>>> > 
> >>>>> > Thanks for your patience all,
> >>>>> > Have a nice week-end, we keep you updated.
> >>>>> > --
> >>>>> > Guillaume Bernard
> >>>>> > 
> &

Re: Damned Lies is down

[Andrea Veri]

Alexander,

mind verifying now?

Thanks!

On Sat, Apr 30, 2022 at 11:27 AM Alexander Shopov 
wrote:

> Gnome-shell now gave:
>
> An error occurred during applying your action: The commit failed. The
> error was: “[Errno 128] Command: "['git', 'fetch']", Error: Host key
> verification failed. fatal: Could not read from remote repository. Please
> make sure you have the correct access rights and the repository exists. ”
>
> To be on the safe side - I archived the actions and started again. Again
> the same mistake.
>
> The same happened with gsettings-desktop-schemas
>
> Kind regards:
>
> al_shopov
>
>
>
>
> На сб, 30.04.2022 г. в 10:50 ч. Andrea Veri  написа:
>
>> Alexander,
>>
>> thanks for reporting, it should be fixed by now, please confirm, cheers!
>>
>> On Sat, Apr 30, 2022 at 10:36 AM Alexander Shopov 
>> wrote:
>>
>>> Getting the same when trying to submit Bulgarian translation of
>>> gnome-shell, I'd presume it is a global thing still missing.
>>> Kind regards:
>>> al_shopov
>>>
>>> На сб, 30.04.2022 г. в 10:25 ч. Alexander Shopov 
>>> написа:
>>>
>>>> I tried uploading the Bulgarian translation of
>>>> gsettings-desktop-schemas, but I got this error:
>>>>
>>>> An error occurred during applying your action: The commit failed. The
>>>> error was: “[Errno 128] Command: "['git', 'fetch']", Error: Warning:
>>>> Permanently added 'gitlab.gnome.org' (ED25519) to the list of known
>>>> hosts. no such identity: /home/l10n/.ssh/ssh-privatekey: No such file or
>>>> directory g...@gitlab.gnome.org: Permission denied
>>>> (publickey,gssapi-keyex,gssapi-with-mic). fatal: Could not read from remote
>>>> repository. Please make sure you have the correct access rights and the
>>>> repository exists. ”
>>>>
>>>> Kind regards:
>>>>
>>>> al_shopov
>>>>
>>>> На сб, 30.04.2022 г. в 9:50 ч. 
>>>> написа:
>>>>
>>>>> And last update :-).
>>>>>
>>>>> The service has been restored as it should at around 1am UTC+2. You
>>>>> can
>>>>> use the app normally now.
>>>>>
>>>>> Le 29/04/2022 22:26, Guillaume Bernard a écrit :
>>>>> > Hi,
>>>>> >
>>>>> > Evening update (from Paris Time :-)). We first had issues with the
>>>>> > database service which was unable to serve incoming connections from
>>>>> > Damned Lies. Next, we had another issue with the deployment of the
>>>>> > application.
>>>>> >
>>>>> > I point out that this is not associated to yesterday runtime update
>>>>> you
>>>>> > may had followed on this mailing list.
>>>>> >
>>>>> > As some of you have seen, two other issues remain: the data storage
>>>>> is
>>>>> > missing. I do not expect any data loss from this side (because the
>>>>> > storage is still visible and appears okay on the cloud interface). We
>>>>> > also use an old snapshot of Damned Lies that was dumped two years
>>>>> ago.
>>>>> > This is probably the one we use for the staging instance. We should
>>>>> not
>>>>> > have lost any data as well.
>>>>> >
>>>>> > Thanks for your patience all,
>>>>> > Have a nice week-end, we keep you updated.
>>>>> > --
>>>>> > Guillaume Bernard
>>>>> >
>>>>> >
>>>>> >
>>>>> > Le vendredi 29 avril 2022 à 11:15 +0200, Guillaume Bernard a écrit :
>>>>> >> Hi all,
>>>>> >>
>>>>> >> We are experiencing (big) troubles with the running Damned Lies
>>>>> >> instance. It was first associated to database errors.
>>>>> >>
>>>>> >> The infrastructure team is currently working, as we are, on this
>>>>> >> issue.
>>>>> >>
>>>>> >> We’ll keep you updated on where the situation will return to normal.
>>>>> >> We’re sorry for the inconvenience.
>>>>> >>
>>>>> >> Regards
>>>>> >> --
>>>>> >> Guillaume Bernard
>>>>> >> ___
>>>>> >> gnome-i18n mailing list
>>>>> >> gnome-i18n@gnome.org
>>>>> >> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>>>> > ___
>>>>> > gnome-i18n mailing list
>>>>> > gnome-i18n@gnome.org
>>>>> > https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>>>> ___
>>>>> gnome-i18n mailing list
>>>>> gnome-i18n@gnome.org
>>>>> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>>>>
>>>>
>>
>> --
>> Cheers,
>> Andrea
>>
>> Principal Systems Engineer at Red Hat,
>> GNOME Infrastructure Team Coordinator,
>> Former GNOME Foundation Board of Directors Secretary,
>> GNOME Foundation Membership & Elections Committee Chairman
>>
>> Homepage: https://www.dragonsreach.it
>>
>

-- 
Cheers,
Andrea

Principal Systems Engineer at Red Hat,
GNOME Infrastructure Team Coordinator,
Former GNOME Foundation Board of Directors Secretary,
GNOME Foundation Membership & Elections Committee Chairman

Homepage: https://www.dragonsreach.it
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies is down

[John Erling Blad via gnome-i18n]

Same for Norwegian Bokmål and Norwegian Nynorsk at Gnome Authenticator.

On Sat, Apr 30, 2022 at 11:27 AM Alexander Shopov 
wrote:

> Gnome-shell now gave:
>
> An error occurred during applying your action: The commit failed. The
> error was: “[Errno 128] Command: "['git', 'fetch']", Error: Host key
> verification failed. fatal: Could not read from remote repository. Please
> make sure you have the correct access rights and the repository exists. ”
>
> To be on the safe side - I archived the actions and started again. Again
> the same mistake.
>
> The same happened with gsettings-desktop-schemas
>
> Kind regards:
>
> al_shopov
>
>
>
>
> На сб, 30.04.2022 г. в 10:50 ч. Andrea Veri  написа:
>
>> Alexander,
>>
>> thanks for reporting, it should be fixed by now, please confirm, cheers!
>>
>> On Sat, Apr 30, 2022 at 10:36 AM Alexander Shopov 
>> wrote:
>>
>>> Getting the same when trying to submit Bulgarian translation of
>>> gnome-shell, I'd presume it is a global thing still missing.
>>> Kind regards:
>>> al_shopov
>>>
>>> На сб, 30.04.2022 г. в 10:25 ч. Alexander Shopov 
>>> написа:
>>>
>>>> I tried uploading the Bulgarian translation of
>>>> gsettings-desktop-schemas, but I got this error:
>>>>
>>>> An error occurred during applying your action: The commit failed. The
>>>> error was: “[Errno 128] Command: "['git', 'fetch']", Error: Warning:
>>>> Permanently added 'gitlab.gnome.org' (ED25519) to the list of known
>>>> hosts. no such identity: /home/l10n/.ssh/ssh-privatekey: No such file or
>>>> directory g...@gitlab.gnome.org: Permission denied
>>>> (publickey,gssapi-keyex,gssapi-with-mic). fatal: Could not read from remote
>>>> repository. Please make sure you have the correct access rights and the
>>>> repository exists. ”
>>>>
>>>> Kind regards:
>>>>
>>>> al_shopov
>>>>
>>>> На сб, 30.04.2022 г. в 9:50 ч. 
>>>> написа:
>>>>
>>>>> And last update :-).
>>>>>
>>>>> The service has been restored as it should at around 1am UTC+2. You
>>>>> can
>>>>> use the app normally now.
>>>>>
>>>>> Le 29/04/2022 22:26, Guillaume Bernard a écrit :
>>>>> > Hi,
>>>>> >
>>>>> > Evening update (from Paris Time :-)). We first had issues with the
>>>>> > database service which was unable to serve incoming connections from
>>>>> > Damned Lies. Next, we had another issue with the deployment of the
>>>>> > application.
>>>>> >
>>>>> > I point out that this is not associated to yesterday runtime update
>>>>> you
>>>>> > may had followed on this mailing list.
>>>>> >
>>>>> > As some of you have seen, two other issues remain: the data storage
>>>>> is
>>>>> > missing. I do not expect any data loss from this side (because the
>>>>> > storage is still visible and appears okay on the cloud interface). We
>>>>> > also use an old snapshot of Damned Lies that was dumped two years
>>>>> ago.
>>>>> > This is probably the one we use for the staging instance. We should
>>>>> not
>>>>> > have lost any data as well.
>>>>> >
>>>>> > Thanks for your patience all,
>>>>> > Have a nice week-end, we keep you updated.
>>>>> > --
>>>>> > Guillaume Bernard
>>>>> >
>>>>> >
>>>>> >
>>>>> > Le vendredi 29 avril 2022 à 11:15 +0200, Guillaume Bernard a écrit :
>>>>> >> Hi all,
>>>>> >>
>>>>> >> We are experiencing (big) troubles with the running Damned Lies
>>>>> >> instance. It was first associated to database errors.
>>>>> >>
>>>>> >> The infrastructure team is currently working, as we are, on this
>>>>> >> issue.
>>>>> >>
>>>>> >> We’ll keep you updated on where the situation will return to normal.
>>>>> >> We’re sorry for the inconvenience.
>>>>> >>
>>>>> >> Regards
>>>>> >> --
>>>>> >> Guillaume Bernard
>>>>> >> ___
>>>>> >> gnome-i18n mailing list
>>>>> >> gnome-i18n@gnome.org
>>>>> >> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>>>> > ___
>>>>> > gnome-i18n mailing list
>>>>> > gnome-i18n@gnome.org
>>>>> > https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>>>> ___
>>>>> gnome-i18n mailing list
>>>>> gnome-i18n@gnome.org
>>>>> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>>>>
>>>>
>>
>> --
>> Cheers,
>> Andrea
>>
>> Principal Systems Engineer at Red Hat,
>> GNOME Infrastructure Team Coordinator,
>> Former GNOME Foundation Board of Directors Secretary,
>> GNOME Foundation Membership & Elections Committee Chairman
>>
>> Homepage: https://www.dragonsreach.it
>>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies is down

[Alexander Shopov]

Gnome-shell now gave:

An error occurred during applying your action: The commit failed. The error
was: “[Errno 128] Command: "['git', 'fetch']", Error: Host key verification
failed. fatal: Could not read from remote repository. Please make sure you
have the correct access rights and the repository exists. ”

To be on the safe side - I archived the actions and started again. Again
the same mistake.

The same happened with gsettings-desktop-schemas

Kind regards:

al_shopov




На сб, 30.04.2022 г. в 10:50 ч. Andrea Veri  написа:

> Alexander,
>
> thanks for reporting, it should be fixed by now, please confirm, cheers!
>
> On Sat, Apr 30, 2022 at 10:36 AM Alexander Shopov 
> wrote:
>
>> Getting the same when trying to submit Bulgarian translation of
>> gnome-shell, I'd presume it is a global thing still missing.
>> Kind regards:
>> al_shopov
>>
>> На сб, 30.04.2022 г. в 10:25 ч. Alexander Shopov 
>> написа:
>>
>>> I tried uploading the Bulgarian translation of
>>> gsettings-desktop-schemas, but I got this error:
>>>
>>> An error occurred during applying your action: The commit failed. The
>>> error was: “[Errno 128] Command: "['git', 'fetch']", Error: Warning:
>>> Permanently added 'gitlab.gnome.org' (ED25519) to the list of known
>>> hosts. no such identity: /home/l10n/.ssh/ssh-privatekey: No such file or
>>> directory g...@gitlab.gnome.org: Permission denied
>>> (publickey,gssapi-keyex,gssapi-with-mic). fatal: Could not read from remote
>>> repository. Please make sure you have the correct access rights and the
>>> repository exists. ”
>>>
>>> Kind regards:
>>>
>>> al_shopov
>>>
>>> На сб, 30.04.2022 г. в 9:50 ч. 
>>> написа:
>>>
>>>> And last update :-).
>>>>
>>>> The service has been restored as it should at around 1am UTC+2. You can
>>>> use the app normally now.
>>>>
>>>> Le 29/04/2022 22:26, Guillaume Bernard a écrit :
>>>> > Hi,
>>>> >
>>>> > Evening update (from Paris Time :-)). We first had issues with the
>>>> > database service which was unable to serve incoming connections from
>>>> > Damned Lies. Next, we had another issue with the deployment of the
>>>> > application.
>>>> >
>>>> > I point out that this is not associated to yesterday runtime update
>>>> you
>>>> > may had followed on this mailing list.
>>>> >
>>>> > As some of you have seen, two other issues remain: the data storage is
>>>> > missing. I do not expect any data loss from this side (because the
>>>> > storage is still visible and appears okay on the cloud interface). We
>>>> > also use an old snapshot of Damned Lies that was dumped two years ago.
>>>> > This is probably the one we use for the staging instance. We should
>>>> not
>>>> > have lost any data as well.
>>>> >
>>>> > Thanks for your patience all,
>>>> > Have a nice week-end, we keep you updated.
>>>> > --
>>>> > Guillaume Bernard
>>>> >
>>>> >
>>>> >
>>>> > Le vendredi 29 avril 2022 à 11:15 +0200, Guillaume Bernard a écrit :
>>>> >> Hi all,
>>>> >>
>>>> >> We are experiencing (big) troubles with the running Damned Lies
>>>> >> instance. It was first associated to database errors.
>>>> >>
>>>> >> The infrastructure team is currently working, as we are, on this
>>>> >> issue.
>>>> >>
>>>> >> We’ll keep you updated on where the situation will return to normal.
>>>> >> We’re sorry for the inconvenience.
>>>> >>
>>>> >> Regards
>>>> >> --
>>>> >> Guillaume Bernard
>>>> >> ___
>>>> >> gnome-i18n mailing list
>>>> >> gnome-i18n@gnome.org
>>>> >> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>>> > ___
>>>> > gnome-i18n mailing list
>>>> > gnome-i18n@gnome.org
>>>> > https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>>> ___
>>>> gnome-i18n mailing list
>>>> gnome-i18n@gnome.org
>>>> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>>>
>>>
>
> --
> Cheers,
> Andrea
>
> Principal Systems Engineer at Red Hat,
> GNOME Infrastructure Team Coordinator,
> Former GNOME Foundation Board of Directors Secretary,
> GNOME Foundation Membership & Elections Committee Chairman
>
> Homepage: https://www.dragonsreach.it
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies is down

[Andrea Veri]

Alexander,

thanks for reporting, it should be fixed by now, please confirm, cheers!

On Sat, Apr 30, 2022 at 10:36 AM Alexander Shopov 
wrote:

> Getting the same when trying to submit Bulgarian translation of
> gnome-shell, I'd presume it is a global thing still missing.
> Kind regards:
> al_shopov
>
> На сб, 30.04.2022 г. в 10:25 ч. Alexander Shopov 
> написа:
>
>> I tried uploading the Bulgarian translation of gsettings-desktop-schemas,
>> but I got this error:
>>
>> An error occurred during applying your action: The commit failed. The
>> error was: “[Errno 128] Command: "['git', 'fetch']", Error: Warning:
>> Permanently added 'gitlab.gnome.org' (ED25519) to the list of known
>> hosts. no such identity: /home/l10n/.ssh/ssh-privatekey: No such file or
>> directory g...@gitlab.gnome.org: Permission denied
>> (publickey,gssapi-keyex,gssapi-with-mic). fatal: Could not read from remote
>> repository. Please make sure you have the correct access rights and the
>> repository exists. ”
>>
>> Kind regards:
>>
>> al_shopov
>>
>> На сб, 30.04.2022 г. в 9:50 ч. 
>> написа:
>>
>>> And last update :-).
>>>
>>> The service has been restored as it should at around 1am UTC+2. You can
>>> use the app normally now.
>>>
>>> Le 29/04/2022 22:26, Guillaume Bernard a écrit :
>>> > Hi,
>>> >
>>> > Evening update (from Paris Time :-)). We first had issues with the
>>> > database service which was unable to serve incoming connections from
>>> > Damned Lies. Next, we had another issue with the deployment of the
>>> > application.
>>> >
>>> > I point out that this is not associated to yesterday runtime update you
>>> > may had followed on this mailing list.
>>> >
>>> > As some of you have seen, two other issues remain: the data storage is
>>> > missing. I do not expect any data loss from this side (because the
>>> > storage is still visible and appears okay on the cloud interface). We
>>> > also use an old snapshot of Damned Lies that was dumped two years ago.
>>> > This is probably the one we use for the staging instance. We should not
>>> > have lost any data as well.
>>> >
>>> > Thanks for your patience all,
>>> > Have a nice week-end, we keep you updated.
>>> > --
>>> > Guillaume Bernard
>>> >
>>> >
>>> >
>>> > Le vendredi 29 avril 2022 à 11:15 +0200, Guillaume Bernard a écrit :
>>> >> Hi all,
>>> >>
>>> >> We are experiencing (big) troubles with the running Damned Lies
>>> >> instance. It was first associated to database errors.
>>> >>
>>> >> The infrastructure team is currently working, as we are, on this
>>> >> issue.
>>> >>
>>> >> We’ll keep you updated on where the situation will return to normal.
>>> >> We’re sorry for the inconvenience.
>>> >>
>>> >> Regards
>>> >> --
>>> >> Guillaume Bernard
>>> >> ___
>>> >> gnome-i18n mailing list
>>> >> gnome-i18n@gnome.org
>>> >> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>> > ___
>>> > gnome-i18n mailing list
>>> > gnome-i18n@gnome.org
>>> > https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>> ___
>>> gnome-i18n mailing list
>>> gnome-i18n@gnome.org
>>> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>>
>>

-- 
Cheers,
Andrea

Principal Systems Engineer at Red Hat,
GNOME Infrastructure Team Coordinator,
Former GNOME Foundation Board of Directors Secretary,
GNOME Foundation Membership & Elections Committee Chairman

Homepage: https://www.dragonsreach.it
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies is down

[Alexander Shopov]

Getting the same when trying to submit Bulgarian translation of
gnome-shell, I'd presume it is a global thing still missing.
Kind regards:
al_shopov

На сб, 30.04.2022 г. в 10:25 ч. Alexander Shopov 
написа:

> I tried uploading the Bulgarian translation of gsettings-desktop-schemas,
> but I got this error:
>
> An error occurred during applying your action: The commit failed. The
> error was: “[Errno 128] Command: "['git', 'fetch']", Error: Warning:
> Permanently added 'gitlab.gnome.org' (ED25519) to the list of known
> hosts. no such identity: /home/l10n/.ssh/ssh-privatekey: No such file or
> directory g...@gitlab.gnome.org: Permission denied
> (publickey,gssapi-keyex,gssapi-with-mic). fatal: Could not read from remote
> repository. Please make sure you have the correct access rights and the
> repository exists. ”
>
> Kind regards:
>
> al_shopov
>
> На сб, 30.04.2022 г. в 9:50 ч.  написа:
>
>> And last update :-).
>>
>> The service has been restored as it should at around 1am UTC+2. You can
>> use the app normally now.
>>
>> Le 29/04/2022 22:26, Guillaume Bernard a écrit :
>> > Hi,
>> >
>> > Evening update (from Paris Time :-)). We first had issues with the
>> > database service which was unable to serve incoming connections from
>> > Damned Lies. Next, we had another issue with the deployment of the
>> > application.
>> >
>> > I point out that this is not associated to yesterday runtime update you
>> > may had followed on this mailing list.
>> >
>> > As some of you have seen, two other issues remain: the data storage is
>> > missing. I do not expect any data loss from this side (because the
>> > storage is still visible and appears okay on the cloud interface). We
>> > also use an old snapshot of Damned Lies that was dumped two years ago.
>> > This is probably the one we use for the staging instance. We should not
>> > have lost any data as well.
>> >
>> > Thanks for your patience all,
>> > Have a nice week-end, we keep you updated.
>> > --
>> > Guillaume Bernard
>> >
>> >
>> >
>> > Le vendredi 29 avril 2022 à 11:15 +0200, Guillaume Bernard a écrit :
>> >> Hi all,
>> >>
>> >> We are experiencing (big) troubles with the running Damned Lies
>> >> instance. It was first associated to database errors.
>> >>
>> >> The infrastructure team is currently working, as we are, on this
>> >> issue.
>> >>
>> >> We’ll keep you updated on where the situation will return to normal.
>> >> We’re sorry for the inconvenience.
>> >>
>> >> Regards
>> >> --
>> >> Guillaume Bernard
>> >> ___
>> >> gnome-i18n mailing list
>> >> gnome-i18n@gnome.org
>> >> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>> > ___
>> > gnome-i18n mailing list
>> > gnome-i18n@gnome.org
>> > https://mail.gnome.org/mailman/listinfo/gnome-i18n
>> ___
>> gnome-i18n mailing list
>> gnome-i18n@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies is down

[Alexander Shopov]

I tried uploading the Bulgarian translation of gsettings-desktop-schemas,
but I got this error:

An error occurred during applying your action: The commit failed. The error
was: “[Errno 128] Command: "['git', 'fetch']", Error: Warning: Permanently
added 'gitlab.gnome.org' (ED25519) to the list of known hosts. no such
identity: /home/l10n/.ssh/ssh-privatekey: No such file or directory
g...@gitlab.gnome.org: Permission denied
(publickey,gssapi-keyex,gssapi-with-mic). fatal: Could not read from remote
repository. Please make sure you have the correct access rights and the
repository exists. ”

Kind regards:

al_shopov

На сб, 30.04.2022 г. в 9:50 ч.  написа:

> And last update :-).
>
> The service has been restored as it should at around 1am UTC+2. You can
> use the app normally now.
>
> Le 29/04/2022 22:26, Guillaume Bernard a écrit :
> > Hi,
> >
> > Evening update (from Paris Time :-)). We first had issues with the
> > database service which was unable to serve incoming connections from
> > Damned Lies. Next, we had another issue with the deployment of the
> > application.
> >
> > I point out that this is not associated to yesterday runtime update you
> > may had followed on this mailing list.
> >
> > As some of you have seen, two other issues remain: the data storage is
> > missing. I do not expect any data loss from this side (because the
> > storage is still visible and appears okay on the cloud interface). We
> > also use an old snapshot of Damned Lies that was dumped two years ago.
> > This is probably the one we use for the staging instance. We should not
> > have lost any data as well.
> >
> > Thanks for your patience all,
> > Have a nice week-end, we keep you updated.
> > --
> > Guillaume Bernard
> >
> >
> >
> > Le vendredi 29 avril 2022 à 11:15 +0200, Guillaume Bernard a écrit :
> >> Hi all,
> >>
> >> We are experiencing (big) troubles with the running Damned Lies
> >> instance. It was first associated to database errors.
> >>
> >> The infrastructure team is currently working, as we are, on this
> >> issue.
> >>
> >> We’ll keep you updated on where the situation will return to normal.
> >> We’re sorry for the inconvenience.
> >>
> >> Regards
> >> --
> >> Guillaume Bernard
> >> ___
> >> gnome-i18n mailing list
> >> gnome-i18n@gnome.org
> >> https://mail.gnome.org/mailman/listinfo/gnome-i18n
> > ___
> > gnome-i18n mailing list
> > gnome-i18n@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gnome-i18n
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies is down

[associations]

And last update :-).

The service has been restored as it should at around 1am UTC+2. You can 
use the app normally now.


Le 29/04/2022 22:26, Guillaume Bernard a écrit :

Hi,

Evening update (from Paris Time :-)). We first had issues with the
database service which was unable to serve incoming connections from
Damned Lies. Next, we had another issue with the deployment of the
application.

I point out that this is not associated to yesterday runtime update you
may had followed on this mailing list.

As some of you have seen, two other issues remain: the data storage is
missing. I do not expect any data loss from this side (because the
storage is still visible and appears okay on the cloud interface). We
also use an old snapshot of Damned Lies that was dumped two years ago.
This is probably the one we use for the staging instance. We should not
have lost any data as well.

Thanks for your patience all,
Have a nice week-end, we keep you updated.
--
Guillaume Bernard



Le vendredi 29 avril 2022 à 11:15 +0200, Guillaume Bernard a écrit :

Hi all,

We are experiencing (big) troubles with the running Damned Lies
instance. It was first associated to database errors.

The infrastructure team is currently working, as we are, on this
issue.

We’ll keep you updated on where the situation will return to normal.
We’re sorry for the inconvenience.

Regards
--
Guillaume Bernard
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies is down

[Guillaume Bernard]

Hi,

Evening update (from Paris Time :-)). We first had issues with the
database service which was unable to serve incoming connections from
Damned Lies. Next, we had another issue with the deployment of the
application.

I point out that this is not associated to yesterday runtime update you
may had followed on this mailing list.

As some of you have seen, two other issues remain: the data storage is
missing. I do not expect any data loss from this side (because the
storage is still visible and appears okay on the cloud interface). We
also use an old snapshot of Damned Lies that was dumped two years ago.
This is probably the one we use for the staging instance. We should not
have lost any data as well.

Thanks for your patience all,
Have a nice week-end, we keep you updated.
--
Guillaume Bernard



Le vendredi 29 avril 2022 à 11:15 +0200, Guillaume Bernard a écrit :
> Hi all,
> 
> We are experiencing (big) troubles with the running Damned Lies
> instance. It was first associated to database errors.
> 
> The infrastructure team is currently working, as we are, on this
> issue.
> 
> We’ll keep you updated on where the situation will return to normal.
> We’re sorry for the inconvenience.
> 
> Regards
> --
> Guillaume Bernard
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Damned Lies is down

[Guillaume Bernard]

Hi all,

We are experiencing (big) troubles with the running Damned Lies
instance. It was first associated to database errors.

The infrastructure team is currently working, as we are, on this issue.

We’ll keep you updated on where the situation will return to normal.
We’re sorry for the inconvenience.

Regards
--
Guillaume Bernard
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: [RFC] Guide for adding new projects on Damned Lies

[Rafael Fontenelle]

Hi all,

I'm thinking of adding it as a draft in GNOME wiki, unless someone
objects or has any other comment.

(below, Philipp's reply, which seems to mistakenly happen off-list)

Rafael

On Mon, Aug 30, 2021 at 1:46 PM Rafael Fontenelle  wrote:
>
> Hi Philipp
>
> You provided an interesting suggestion, as it would save everyone's time.
>
> However I feel that if the Translation Coordinators create (if not existent 
> already) such criteria, these should be placed in a specific page under the 
> "Localization Coordination Team" section [1], and then added a reference in 
> this guide I'm proposing.
>
>
> [1] https://wiki.gnome.org/TranslationProject/#Localization_Coordination_Team
>
>
> Em seg, 30 de ago de 2021 12:27, Philipp Kiemle  
> escreveu:
>>
>> Hello all,
>> Thank you for this good idea, Rafael! I really like the fact that the 
>> process of applying for an integration with DL becomes clearer.
>> While I am in no form qualified to decide on this, I would like to ask 
>> something:
>>
>> Is there already some place where project maintainers can find rules and 
>> criteria that their application has to meet in order to get accepted to DL?
>> If not, I'd love to see them here.
>> Two criteria that I can think of right now, for example:
>> - What kind of software do we accept (Shell extensions/standalone programs)?
>> - Does the software have to have a minimum number of users or some other 
>> relevance indicator?
>>
>> I don't want to say that letting the l18n coordinators decide by their 
>> personal opinion is necessarily a bad thing - I do trust their decision 
>> making.
>> However, I think that a "requirements checklist" could save them some time 
>> and provide guidance to developers.
>>
>> Cheers,
>> Philipp
>>
>> Rafael Fontenelle  schrieb am Mo., 30. Aug. 2021, 13:49:
>>>
>>> Hi all,
>>>
>>> I haven't found a set of instructions from the project maintainer's
>>> point of view for adding a new project for localization in Damned
>>> Lies, and everytime I feel that linking a page to the maintainer would
>>> be more inviting.
>>>
>>> Having that in mind, I drafted a page that would probably fit as an
>>> item in the "For maintainers/developers of modules" section of
>>> TranslationProject wiki page [1]. It is in Markdown, as it was easier
>>> for me to generate a HTML output, but I would reformat in MediaWiki
>>> syntax to create the wiki page.
>>>
>>> Please find attached the draft both in Markdown and HTML file formats.
>>>
>>> Any thoughts? Feedbacks?
>>>
>>> [1] 
>>> https://wiki.gnome.org/TranslationProject/#For_maintainers.2Fdevelopers_of_modules
>>>
>>> Best regards,
>>> Rafael Fontenelle
>>> ___
>>> gnome-i18n mailing list
>>> gnome-i18n@gnome.org
>>> https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Add Apostrophe to damned-lies

[Manuel via gnome-i18n]

Hi, i18 team!

Apostrophe was moved recently to the World repo, and it'd be nice to have
it in damned lies as well. The app is already translated by volunteers on
poeditor, but I'm not 100% sure on the quality of the strings for other
languages than the ones I speak

https://gitlab.gnome.org/World/apostrophe

Many thanks!

Cheers, Manuel
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies Gateway error on sending gnome-commander

[Enrico via gnome-i18n]

Greetings to all

Thank you Philipp, I will do a next try ASAP based on the new translatable
strings available at the project, so I can observe the behavior 😉

Have a nice week
Be Well and Stay Safe,
Enrico.
‐
Em sex., 10 de set. de 2021 11:37, Philipp Kiemle 
escreveu:

> ...forgot to add the link: https://gitlab.gnome.org/GNOME/gnome-commander
>
> Philipp Kiemle  schrieb am Fr., 10. Sept. 2021,
> 16:30:
>
>> Hello all,
>> I get this error too - so far only when trying to upload a translation
>> for an older release and I checked the "Cherry-pick to the main/master
>> branch if possible" checkbox.
>> So far, despite the 504 error, the translation did perfectly land in the
>> git repos every time, I assume it is only the "frontend" (website) that
>> does not receive an answer in time and then throws an error. Am I talking
>> nonsense here, or is this plausible?
>> Enrico, I'd suggest you take a look at the GitLab repo of the application
>> (in this case [1]) and check it after a couple of minutes. The translation
>> should land there despite the webpage error in my experience. However, I am
>> just a translator and have no knowledge of the inner workings of DL...
>> Have a nice weekend,
>> Philipp
>>
>> Am Do., 9. Sept. 2021 um 01:25 Uhr schrieb Enrico via gnome-i18n <
>> gnome-i18n@gnome.org>:
>>
>>> Dear folks
>>>
>>> When trying to send gnome-commander translation through Damned Lies I
>>> got the error message: "504 Gateway Time-out. The server didn't respond in
>>> time."
>>>
>>> Please, may someone check settings in order to allow us to send
>>> translation?
>>>
>>> Best regards,
>>> Enrico (pt_BR team)
>>> ___
>>> gnome-i18n mailing list
>>> gnome-i18n@gnome.org
>>> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>>
>>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies Gateway error on sending gnome-commander

[Philipp Kiemle via gnome-i18n]

...forgot to add the link: https://gitlab.gnome.org/GNOME/gnome-commander

Philipp Kiemle  schrieb am Fr., 10. Sept. 2021,
16:30:

> Hello all,
> I get this error too - so far only when trying to upload a translation for
> an older release and I checked the "Cherry-pick to the main/master branch
> if possible" checkbox.
> So far, despite the 504 error, the translation did perfectly land in the
> git repos every time, I assume it is only the "frontend" (website) that
> does not receive an answer in time and then throws an error. Am I talking
> nonsense here, or is this plausible?
> Enrico, I'd suggest you take a look at the GitLab repo of the application
> (in this case [1]) and check it after a couple of minutes. The translation
> should land there despite the webpage error in my experience. However, I am
> just a translator and have no knowledge of the inner workings of DL...
> Have a nice weekend,
> Philipp
>
> Am Do., 9. Sept. 2021 um 01:25 Uhr schrieb Enrico via gnome-i18n <
> gnome-i18n@gnome.org>:
>
>> Dear folks
>>
>> When trying to send gnome-commander translation through Damned Lies I got
>> the error message: "504 Gateway Time-out. The server didn't respond in
>> time."
>>
>> Please, may someone check settings in order to allow us to send
>> translation?
>>
>> Best regards,
>> Enrico (pt_BR team)
>> ___
>> gnome-i18n mailing list
>> gnome-i18n@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies Gateway error on sending gnome-commander

[Philipp Kiemle via gnome-i18n]

Hello all,
I get this error too - so far only when trying to upload a translation for
an older release and I checked the "Cherry-pick to the main/master branch
if possible" checkbox.
So far, despite the 504 error, the translation did perfectly land in the
git repos every time, I assume it is only the "frontend" (website) that
does not receive an answer in time and then throws an error. Am I talking
nonsense here, or is this plausible?
Enrico, I'd suggest you take a look at the GitLab repo of the application
(in this case [1]) and check it after a couple of minutes. The translation
should land there despite the webpage error in my experience. However, I am
just a translator and have no knowledge of the inner workings of DL...
Have a nice weekend,
Philipp

Am Do., 9. Sept. 2021 um 01:25 Uhr schrieb Enrico via gnome-i18n <
gnome-i18n@gnome.org>:

> Dear folks
>
> When trying to send gnome-commander translation through Damned Lies I got
> the error message: "504 Gateway Time-out. The server didn't respond in
> time."
>
> Please, may someone check settings in order to allow us to send
> translation?
>
> Best regards,
> Enrico (pt_BR team)
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Damned Lies Gateway error on sending gnome-commander

[Enrico via gnome-i18n]

Dear folks

When trying to send gnome-commander translation through Damned Lies I got
the error message: "504 Gateway Time-out. The server didn't respond in
time."

Please, may someone check settings in order to allow us to send translation?

Best regards,
Enrico (pt_BR team)
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

[RFC] Guide for adding new projects on Damned Lies

[Rafael Fontenelle]

Hi all,

I haven't found a set of instructions from the project maintainer's
point of view for adding a new project for localization in Damned
Lies, and everytime I feel that linking a page to the maintainer would
be more inviting.

Having that in mind, I drafted a page that would probably fit as an
item in the "For maintainers/developers of modules" section of
TranslationProject wiki page [1]. It is in Markdown, as it was easier
for me to generate a HTML output, but I would reformat in MediaWiki
syntax to create the wiki page.

Please find attached the draft both in Markdown and HTML file formats.

Any thoughts? Feedbacks?

[1] 
https://wiki.gnome.org/TranslationProject/#For_maintainers.2Fdevelopers_of_modules

Best regards,
Rafael Fontenelle





Checklist for adding software to Damned Lies

For source code repository hosted in GNOME GitLab:


The repository must be in a non-personal namespace (e.g. GNOME for core apps or World for circle apps). Request sysadmins to move the repository to the proper namespace.
Tidy up localization-related files:


Make sure .doap file is properly set with  and other tags, See Git/FAQ for an example.
Make sure po/POTFILES.in exists (rename po/POTFILES to it)
Make sure po/POTFILES.in is up to date with all sources files containing translatable strings. See set of instructions below.

Add @translations user as a member of your repository with Developer role
If branch protection is enabled (default), make sure to allow Developer role to push commits. See Protected branches.
Request translation coordinators in gnome-i18n mailing list to add this project to Damned Lies


For source code repository hosted in other software forges (GitHub, GitLab, etc.):


Tidy up localization-related files:


Make sure po/POTFILES.in exists (rename po/POTFILES to it)
Make sure po/POTFILES.in is up to date with all sources files containing translatable strings. See set of instructions below.

Request translation coordinators in gnome-i18n mailing list to add this project to Damned Lies


Updating POTFILES

Here is a suggestion on updating POTFILES:


First, fill in the po/POTFILES.in with all files that potentially have translatable strings. Use the negative ! -name to exclude files known to not have translatable strings, like images and stylesheets. For instance, for a Rust project:


find data/ src/ -type f ! -name '*.build' ! -name '*.svg' ! -name '*.css' ! -name 'config.rs' ! -name 'config.rs.in' > po/POTFILES.in



Then, set up your project, by using ./configure for autoconf-based projects and meson . build for Meson buildsystem-based projects. Dependencies might need to be satisfied.
Then update the .pot file. This may vary across project. On projects using Meson buildsystem, should be something like (projectname is the name set on meson.build):


ninja -C build -pot



Set po/POTFILES.in with the actually list of source files that now have translatable strings in the .pot file. For instance:


grep '^#: ' po/-pot | cut -d: -f2 | sed 's|^ ||' | sort -u > po/POTFILES.in


Now you should have a up-to-date po/POTFILES.in.







## Checklist for adding software to Damned Lies

### For source code repository hosted in [GNOME GitLab]:

1. The repository must be in a non-personal namespace (e.g. [GNOME] for core apps or [World] for [circle apps]). [Request sysadmins] to move the repository to the proper namespace.
2. Tidy up localization-related files:
- Make sure .doap file is properly set with  and other tags, See [Git/FAQ] for an example.
- Make sure po/POTFILES.in exists (rename po/POTFILES to it)
- Make sure po/POTFILES.in is up to date with all sources files containing translatable strings. See set of instructions below.
3. Add @translations user as a member of your repository with Developer role
4. If branch protection is enabled (default), make sure to allow Developer role to push commits. See [Protected branches].
5. Request translation coordinators in [gnome-i18n mailing list] to add this project to Damned Lies

### For source code repository hosted in other software forges (GitHub, GitLab, etc.):

1. Tidy up localization-related files:
- Make sure po/POTFILES.in exists (rename po/POTFILES to it)
- Make sure po/POTFILES.in is up to date with all sources files containing translatable strings. See set of instructions below.
2. Request translation coordinators in [gnome-i18n mailing list] to add this project to Damned Lies

## Updating POTFILES

Here is a suggestion on updating POTFILES:

1. First, fill in the po/POTFILES.in with all files that potentially have translatable strings. Use the negative `! -name` to exclude files known to not have translatable strings, like images and stylesheets. For instance, for a Rust project:

```
find data/ src/ -type f ! -name '*.build' ! -name '*.svg' ! -name '*.css' ! -name 'config.rs' ! -name 

Re: Fresh blood for Damned Lies

[Guillaume Bernard]

Hi everyone, dear Claude,

I will take time to introduce me and the future I foresee for Damned Lies in
future emails and blog posts, the TL;DR will remain here 😉️.

As Claude said, I proposed a few time ago (that is to say, 2 years ago for the
first time, gave up for personal reasons (PhD thesis) and since a few months
again) to contribute to Damned Lies. This desire came as I’m a Damned Lies user
and a GNOME French Team member. I met GNOME seven years ago already, when, as a
first year undergraduate student, I wished to contribute to something different.
I spent some times in secondary school contributing on Ubuntu and Mageia, for
those who may remember, often focusing on translations or help on forums.

To be frank, I started a project, two years ago, part of my master’s degree
internship to learn a bit better Django. I maintained this project for two
years, and it’s now gone, right in time to start a new adventure 🙂.

For those who may wish to ask, I’m currently preparing a PhD thesis in natural
language processing, focusing on historical digital libraries, for those who may
be interested to have a discussion about this (if you have a dataset, please
help, DO YOU have a dataset 🤣️🤯️. Private joke for PhD and former PhD students
😉️).

I proposed to Claude to focus, for this year, on some points:

- enhance communication from DL developers to the users: you and the translation
teams.
- enhance code quality measurement, find a safe contribution path, to welcome
external contribution without the risk of breaking a core part of the GNOME
ecosystem. 
- make translators and team members contribute to the development of DL. No
coding knowledge is required (even if welcomed), but I hope you will be often
solicited in order to give your opinion about interfaces, work flow (not
Vertimus, but browsing into the app I mean).

I opened a new blog recently: https://blogs.gnome.org/gbernard/ and I intend to
work with Claude in order to communicate about this amazing project! Empty for
the moment, content is about to come.

Thanks a lot everyone, and thank you Claude for this sign of trust,

NB: I’m available of Matrix too, otherwise, for 🍻️, send me a private message
😉️ (I do not reimburse train or plane tickets).
-- 
Guillaume Bernard


> Date: Fri, 18 Jun 2021 08:28:03 +0200
> From: Claude Paroz 
> To: gnome-i18n 
> Subject: Fresh blood for Damned Lies
> Message-ID: <502b4f8d-55ce-2d2e-6480-eaf897e5e...@2xlibre.net>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Dear team,
> 
> I'd like to announce that Guillaume Bernard kindly approached me to 
> propose his help regarding Damned Lies evolution and maintenance. He has 
> a good experience in the Python/Django world and already pushed some 
> interesting patches.
> 
> I'll let him present his plans on this list. This does not mean I will 
> suddenly disappear, but I will probably be a bit less present as I don't 
> want to be a hurdle for fresh ideas and progresses.
> 
> Kind regards,
> 
> Claude


signature.asc
Description: This is a digitally signed message part
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Fresh blood for Damned Lies

[Claude Paroz]

Dear team,

I'd like to announce that Guillaume Bernard kindly approached me to 
propose his help regarding Damned Lies evolution and maintenance. He has 
a good experience in the Python/Django world and already pushed some 
interesting patches.


I'll let him present his plans on this list. This does not mean I will 
suddenly disappear, but I will probably be a bit less present as I don't 
want to be a hurdle for fresh ideas and progresses.


Kind regards,

Claude
--
www.2xlibre.net
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Adding gnome-remote-desktop to Damned Lies

[Piotr Drąg via gnome-i18n]

śr., 16 cze 2021 o 20:31 Jonas Ådahl via gnome-i18n
 napisał(a):
>
> Hi,
>
> gnome-remote-desktop is the remote desktop service of GNOME. It supports
> the VNC and RDP, allowing you to share your desktop, currently managed
> via Settings.
>
> You can find it here:
> https://gitlab.gnome.org/GNOME/gnome-remote-desktop
>
> It has a few translatable strings; thus I'd like to see it being added
> to the GNOME translation infrastructure.
>
> How would I go about doing that?
>

Hi,

Posting here is one of the options (an issue against
Infrastructure/damned-lies is another), so here it is:

https://l10n.gnome.org/module/gnome-remote-desktop/

Best regards,

-- 
Piotr Drąg
https://piotrdrag.fedorapeople.org
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Minor problems on Damned Lies

[Yuri Chornoivan via gnome-i18n]

17 червня 2021, 10:14:20, від "Mart Raudsepp" :

> Ühel kenal päeval, K, 16.06.2021 kell 19:46, kirjutas Yuri Chornoivan
> via gnome-i18n:
> > 2. It is impossible to commit the updated translation for Planner.
> > 
> > https://l10n.gnome.org/vertimus/planner/master/po/uk/
> > 
> > DL shows the following message:
> > 
> > [Errno 128] Command: "['git', 'push', 'origin', 'master']", Error:
> > Warning: 
> > Permanently added 'gitlab.gnome.org,172.31.2.39' (ECDSA) to the list
> > of known 
> > hosts. remote: remote: 
> > remote: remote: You are not allowed to push code to this project.
> > remote: 
> > remote: 
> > remote: fatal: Could not read from remote repository. Please make
> > sure you 
> > have the correct access rights and the repository exists.
> > 
> > Thanks in advance for helping to fix these issues.
> 
> Planner was moved from GNOME namespace to World before I became its
> maintainer, this probably made DL not have default access to it
> anymore.
> I have tried to restore its access on the example of what some other
> World projects are doing with permissions for a @translations user -
> please give it a try whether it works now.
> 
> 
> Mart

Works like a charm. Many thanks for your work.

Best regards,
Yuri
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Minor problems on Damned Lies

[Mart Raudsepp via gnome-i18n]

Ühel kenal päeval, K, 16.06.2021 kell 19:46, kirjutas Yuri Chornoivan
via gnome-i18n:
> 2. It is impossible to commit the updated translation for Planner.
> 
> https://l10n.gnome.org/vertimus/planner/master/po/uk/
> 
> DL shows the following message:
> 
> [Errno 128] Command: "['git', 'push', 'origin', 'master']", Error:
> Warning: 
> Permanently added 'gitlab.gnome.org,172.31.2.39' (ECDSA) to the list
> of known 
> hosts. remote: remote: 
> remote: remote: You are not allowed to push code to this project.
> remote: 
> remote: 
> remote: fatal: Could not read from remote repository. Please make
> sure you 
> have the correct access rights and the repository exists.
> 
> Thanks in advance for helping to fix these issues.

Planner was moved from GNOME namespace to World before I became its
maintainer, this probably made DL not have default access to it
anymore.
I have tried to restore its access on the example of what some other
World projects are doing with permissions for a @translations user -
please give it a try whether it works now.


Mart


signature.asc
Description: This is a digitally signed message part
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Adding gnome-remote-desktop to Damned Lies

[Jonas Ådahl via gnome-i18n]

Hi,

gnome-remote-desktop is the remote desktop service of GNOME. It supports
the VNC and RDP, allowing you to share your desktop, currently managed
via Settings.

You can find it here:
https://gitlab.gnome.org/GNOME/gnome-remote-desktop

It has a few translatable strings; thus I'd like to see it being added
to the GNOME translation infrastructure.

How would I go about doing that?


Jonas
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Minor problems on Damned Lies

[Yuri Chornoivan via gnome-i18n]

Hi,

1. Documentation checks do not work. Pushing the validity check button just 
spits

"Sorry, the server was not able to run the quality checks on this file ([Errno 
2] No such file or directory: 'pofilter')"

2. It is impossible to commit the updated translation for Planner.

https://l10n.gnome.org/vertimus/planner/master/po/uk/

DL shows the following message:

[Errno 128] Command: "['git', 'push', 'origin', 'master']", Error: Warning: 
Permanently added 'gitlab.gnome.org,172.31.2.39' (ECDSA) to the list of known 
hosts. remote: remote: 
 
remote: remote: You are not allowed to push code to this project. remote: 
remote: 
 
remote: fatal: Could not read from remote repository. Please make sure you 
have the correct access rights and the repository exists.

Thanks in advance for helping to fix these issues.

Best regards,
Yuri


___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Can't commit to simple-scan master via Damned Lies

[Alexandre Franke]

On Sun, Dec 27, 2020 at 11:54 AM Daniel Șerbănescu  wrote:
> Hello,

Hi,

> We at the Romanian team have been trying to commit the translation for
> simple-scan (master branch) via Damned Lies but the process fails every
> time.

It has already been reported a few days ago:
https://gitlab.gnome.org/GNOME/simple-scan/-/issues/218

Subscribe to the issue to know when it is solved.

-- 
Alexandre Franke
GNOME Hacker
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Can't commit to simple-scan master via Damned Lies

[Daniel Șerbănescu]

Hello,

We at the Romanian team have been trying to commit the translation for
simple-scan (master branch) via Damned Lies but the process fails every
time.

Error message:



A apărut o eroare în timpul aplicării acțiunii: Comiterea nu a reușit.
Eroarea a fost: „[Errno 1] Command: "['git', 'push', 'origin',
'master']", Error: Warning: Permanently added
'gitlab.gnome.org,172.31.2.39' (ECDSA) to the list of known hosts.
remote: GitLab: You are not allowed to push code to protected branches
on this project.To g...@gitlab.gnome.org:GNOME/simple-scan.git ! [remote
rejected] master -> master (pre-receive hook declined) error: failed to
push some refs to 'g...@gitlab.gnome.org:GNOME/simple-scan.git' ”



First line says: There's been an error while applying action: Commit
failed. The error was „[Errno 1] Command ...


Can anyone take a look into this.
Thanks

Daniel

___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Add libdazzle to Damned Lies

[Sophie Herold]

Dear i18n list,

libdazzle should be ready for translations, but it's missing in DL.

https://gitlab.gnome.org/GNOME/libdazzle.git

Please add libdazzle to DL, maintainer agrees

https://gitlab.gnome.org/GNOME/libdazzle/-/issues/1#note_963992

Best,
Sophie
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Add Pika Backup to Damned Lies

[Sophie Herold]

Dear i18n list,

I prepared Pika Backup for translation and want to ask for it to be
included into Damned Lies.

https://gitlab.gnome.org/World/pika-backup

Version v0.2 is under development and will hopefully be released this
year. However, there is no string freeze for v0.2 yet.

Best,
Sophie
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Unable to login in Damned Lies

[Alexandre Franke]

On Tue, Sep 1, 2020 at 11:47 AM Fran Dieguez  wrote:
> Hi,

Hi,

> I'm trying to login in Damned Lies l10n.gnome.org, I'm unable to log in.
>
> I have checked by resetting my password, and all the process went well, but 
> if I try to log in with my new password the same message keeps showing up 
> "Login unsuccessful. Please verify your username and password."
>
> And if I try to log in with my "GNOME account" the next messages shows: 
> "OpenID discovery error: Error fetching XRDS document:"
>
> Anyone can give a hand?

Please use gitlab for support.
https://gitlab.gnome.org/Infrastructure/damned-lies/-/issues

-- 
Alexandre Franke
GNOME Hacker
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Unable to login in Damned Lies

[Fran Dieguez]

Hi,

I'm trying to login in Damned Lies l10n.gnome.org, I'm unable to log in.

I have checked by resetting my password, and all the process went well, but
if I try to log in with my new password the same message keeps showing up
"Login unsuccessful. Please verify your username and password."

And if I try to log in with my "GNOME account" the next messages shows:
"OpenID discovery error: Error fetching XRDS document:"

Anyone can give a hand?

Cheers,
Fran
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Problems commiting damned-lies package

[Claude Paroz]

Le 23.06.20 à 19:44, Emmanuele Bassi via gnome-i18n a écrit :
> 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.

Wow, didn't know that. Thanks Emmanuele for pointing us to that Gitlab
functionality. I'll try to experiment with that idea in coming days.

Claude
-- 
www.2xlibre.net
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Problems commiting damned-lies package

[Emmanuele Bassi via gnome-i18n]

Hi Alexandre;

thanks for the reply.

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

Re: Problems commiting damned-lies package

[Alexandre Franke]

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.

On Mon, Jun 22, 2020 at 1:13 PM Emmanuele Bassi via gnome-i18n
 wrote:
> DL can, at least, centralise the place where tests are executed to ensure 
> that things don't utterly break.
> Of course, it's not really a solution: now that we use GitLab, we already 
> have a centralised place to run
> builds and tests.

Yep.

> 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?

> Your script is your own script. Unless everybody uses your script—in which 
> case, it should be
> moved to a remote environment so that people don't have to have Git 
> access—then it's pointless.

Yes, we frown upon that too.

> We even have API in GitLab to:
>
>  - automatically create a merge request
>  - set the target branch
>  - automatically merge code once the CI pipeline passes
>  - automatically remove the source branch when merged
>
> when pushing to the remote repository: 
> https://docs.gitlab.com/ee/user/project/push_options.html
>
> I do hope your script uses it. I'd hope for DL to do the same.

Yeah, as I described above I share the same hope.

> 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.

> 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).

> Ciao,
>  Emmanuele.

Thank you for your contribution to this conversation, Emmanuele.


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.

-- 
Alexandre Franke
GNOME i18n coordinator
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Problems commiting damned-lies package

[Ask Hjorth Larsen via gnome-i18n]

Dear Fòram, and all,

Am Mo., 22. Juni 2020 um 16:39 Uhr schrieb Fòram na Gàidhlig
:
> IMO the optimum workflow would be to pull weblate translations with a
> scheduled GitLab CI job and let the CI commit them into a branch when
> they're green. The master branch should be protected and nobody should
> be allowed to push there directly. Even skilled and experienced project
> maintainers will make mistakes, because nobody is perfect.

What about this similar model:

 * We (translators) always commit to a fork of the central repo.  D-L
runs on top of this fork rather than the projects directly.
Committers/coordinators have push access to all those forks.
 * Projects merge from this fork in some manner which is controlled by
maintainers -- subject to CI pipelines etc.

I suggest this because it might solve the most important immediate
problems while it looks (to me) as a relatively small step.
Introducing weblate could be an additional step.

Best regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Problems commiting damned-lies package

[Kukuh Syafaat via gnome-i18n]

 the proper way or even help with a tool or a patch for DL. I made
> > a bash script  because I don't know Python. I'm a translator, not a
> > developer, sorry.
> >
> > I'm leaving here the discussion/thread, but thanks for your comments
> > and your point of view.
> >
> > Regards
> >
> > El lun., 22 jun. 2020 a las 13:13, Emmanuele Bassi
> > (mailto:eba...@gmail.com>>) escribió:
> >
> > On Mon, 22 Jun 2020 at 11:44, Daniel Mustieles García
> > mailto:daniel.mustie...@gmail.com>>
> > wrote:
> >
> > Hi Emmanuele,
> >
> > Just a quick question: which is the difference between
> > commiting directly into Git and commiting through DL?
> >
> >
> > DL can, at least, centralise the place where tests are executed
> > to ensure that things don't utterly break. Of course, it's not
> > really a solution: now that we use GitLab, we already have a
> > centralised place to run builds and tests.
> >
> > The fact that DL pushes to the main development branch *also*
> > irks me to no end; at least DL acts as a filter, and ensures
> > that *some* validation is actually performed.
> >
> >
> > PO file checks are the same (or should be), so commiting
> > directly is not more dangerous than using DL. the same
> > checks DL makes into a PO file are done in my script, for
> > example. If a PO file breaks your module's building it
> > doesn't matter if I committed it directly into git or usind
> DL.
> >
> >
> > Your script is your own script. Unless everybody uses your
> > script—in which case, it should be moved to a remote environment
> > so that people don't have to have Git access—then it's pointless.
> >
> > But my point is that I don't want translators to have "scripts".
> > I don't want translators to do anything more than translating.
> > We have infrastructure to verify that things pushed to the
> > repository do not break the main development branch of a
> > project: it's called the continuous integration pipeline, and we
> > have a process for it to run on topic branches. We even have API
> > in GitLab to:
> >
> >  - automatically create a merge request
> >  - set the target branch
> >  - automatically merge code once the CI pipeline passes
> >  - automatically remove the source branch when merged
> >
> > when pushing to the remote repository:
> > https://docs.gitlab.com/ee/user/project/push_options.html
> >
> > I do hope your script uses it. I'd hope for DL to do the same.
> >
> >
> > Also, note that not all translators will have commit rights:
> > only a reduced group of them. Breaking things in git is
> > possible for both translators and developers: that's one of
> > the reasons we use Git, to be able to revert commits and
> > even revoke commit access to a person who breaks things
> > several times.
> >
> >
> > I don't want to manually revert stuff that's broken and got
> > pushed to the main development branch. I don't want broken stuff
> > to land *in the first place*.
> >
> > Git having easy revert operations is good for things that are
> > *discovered* to be broken later on; that doesn't mean people
> > should push broken localisations of the application
> > documentation, with broken tags that do not close properly, and
> > get only discovered when trying to release something. That's
> > sacrificing maintenance time—*my* time—because you want to save
> > your time. Your time isn't any more precious than mine.
> >
> > Additionally, we have whole run times that get built every day;
> > if a translation breaks a library, or an application, the whole
> > pipeline gets stalled until the problem is solved. The amount of
> > lost person time is staggering.
> >
> > This is not a question of being 20 years o 20 days in the
> > project: this is a question of helping us with our work,
> > because that work is as valid as yours, and we all ar

Re: Problems commiting damned-lies package

[Fòram na Gàidhlig]

> commiting directly into Git and commiting through DL?
> 
> 
> DL can, at least, centralise the place where tests are executed
> to ensure that things don't utterly break. Of course, it's not
> really a solution: now that we use GitLab, we already have a
> centralised place to run builds and tests.
> 
> The fact that DL pushes to the main development branch *also*
> irks me to no end; at least DL acts as a filter, and ensures
> that *some* validation is actually performed.
>  
> 
> PO file checks are the same (or should be), so commiting
> directly is not more dangerous than using DL. the same
> checks DL makes into a PO file are done in my script, for
> example. If a PO file breaks your module's building it
> doesn't matter if I committed it directly into git or usind DL.
> 
> 
> Your script is your own script. Unless everybody uses your
> script—in which case, it should be moved to a remote environment
> so that people don't have to have Git access—then it's pointless.
> 
> But my point is that I don't want translators to have "scripts".
> I don't want translators to do anything more than translating.
> We have infrastructure to verify that things pushed to the
> repository do not break the main development branch of a
> project: it's called the continuous integration pipeline, and we
> have a process for it to run on topic branches. We even have API
> in GitLab to:
> 
>  - automatically create a merge request
>  - set the target branch
>  - automatically merge code once the CI pipeline passes
>  - automatically remove the source branch when merged
> 
> when pushing to the remote repository:
> https://docs.gitlab.com/ee/user/project/push_options.html
> 
> I do hope your script uses it. I'd hope for DL to do the same.
>  
> 
> Also, note that not all translators will have commit rights:
> only a reduced group of them. Breaking things in git is
> possible for both translators and developers: that's one of
> the reasons we use Git, to be able to revert commits and
> even revoke commit access to a person who breaks things
> several times.
> 
> 
> I don't want to manually revert stuff that's broken and got
> pushed to the main development branch. I don't want broken stuff
> to land *in the first place*.
> 
> Git having easy revert operations is good for things that are
> *discovered* to be broken later on; that doesn't mean people
> should push broken localisations of the application
> documentation, with broken tags that do not close properly, and
> get only discovered when trying to release something. That's
> sacrificing maintenance time—*my* time—because you want to save
> your time. Your time isn't any more precious than mine.
> 
> Additionally, we have whole run times that get built every day;
> if a translation breaks a library, or an application, the whole
> pipeline gets stalled until the problem is solved. The amount of
> lost person time is staggering.
> 
> This is not a question of being 20 years o 20 days in the
> project: this is a question of helping us with our work,
> because that work is as valid as yours, and we all are
> responsible with it. pre-commit hooks can be implemented
> (they are already, but we could study if are enough or not)
> to avoid breaking things, but its really discouraging to
> follow DL's workflow to commit a 1-modified string in a PO
> file. Multiply it by 20...
> 
> 
> If people spent time improving Damned Lies instead of working
> around it with their own scripts, we would probably have a
> better tool already.
> 
> Or, maybe, a better tool already exists, and we should move to it.
> 
> In any case, my point is that even people that can commit to Git
> *should not* push to the main development branch. *Ever*. The
> mere fact that you reference "commit hooks" makes me think
> you're basically thinking that we're using Git by itself, like
> this is still 2009. We don't. We switched to GitLab because it
> offers us a lot more tools that "hooks&

Re: Problems commiting damned-lies package

[Baurzhan Muftakhidinov via gnome-i18n]

 me to no 
>>> end; at least DL acts as a filter, and ensures that *some* validation is 
>>> actually performed.
>>>
>>>>
>>>> PO file checks are the same (or should be), so commiting directly is not 
>>>> more dangerous than using DL. the same checks DL makes into a PO file are 
>>>> done in my script, for example. If a PO file breaks your module's building 
>>>> it doesn't matter if I committed it directly into git or usind DL.
>>>
>>>
>>> Your script is your own script. Unless everybody uses your script—in which 
>>> case, it should be moved to a remote environment so that people don't have 
>>> to have Git access—then it's pointless.
>>>
>>> But my point is that I don't want translators to have "scripts". I don't 
>>> want translators to do anything more than translating. We have 
>>> infrastructure to verify that things pushed to the repository do not break 
>>> the main development branch of a project: it's called the continuous 
>>> integration pipeline, and we have a process for it to run on topic 
>>> branches. We even have API in GitLab to:
>>>
>>>  - automatically create a merge request
>>>  - set the target branch
>>>  - automatically merge code once the CI pipeline passes
>>>  - automatically remove the source branch when merged
>>>
>>> when pushing to the remote repository: 
>>> https://docs.gitlab.com/ee/user/project/push_options.html
>>>
>>> I do hope your script uses it. I'd hope for DL to do the same.
>>>
>>>>
>>>> Also, note that not all translators will have commit rights: only a 
>>>> reduced group of them. Breaking things in git is possible for both 
>>>> translators and developers: that's one of the reasons we use Git, to be 
>>>> able to revert commits and even revoke commit access to a person who 
>>>> breaks things several times.
>>>
>>>
>>> I don't want to manually revert stuff that's broken and got pushed to the 
>>> main development branch. I don't want broken stuff to land *in the first 
>>> place*.
>>>
>>> Git having easy revert operations is good for things that are *discovered* 
>>> to be broken later on; that doesn't mean people should push broken 
>>> localisations of the application documentation, with broken tags that do 
>>> not close properly, and get only discovered when trying to release 
>>> something. That's sacrificing maintenance time—*my* time—because you want 
>>> to save your time. Your time isn't any more precious than mine.
>>>
>>> Additionally, we have whole run times that get built every day; if a 
>>> translation breaks a library, or an application, the whole pipeline gets 
>>> stalled until the problem is solved. The amount of lost person time is 
>>> staggering.
>>>
>>>> This is not a question of being 20 years o 20 days in the project: this is 
>>>> a question of helping us with our work, because that work is as valid as 
>>>> yours, and we all are responsible with it. pre-commit hooks can be 
>>>> implemented (they are already, but we could study if are enough or not) to 
>>>> avoid breaking things, but its really discouraging to follow DL's workflow 
>>>> to commit a 1-modified string in a PO file. Multiply it by 20...
>>>
>>>
>>> If people spent time improving Damned Lies instead of working around it 
>>> with their own scripts, we would probably have a better tool already.
>>>
>>> Or, maybe, a better tool already exists, and we should move to it.
>>>
>>> In any case, my point is that even people that can commit to Git *should 
>>> not* push to the main development branch. *Ever*. The mere fact that you 
>>> reference "commit hooks" makes me think you're basically thinking that 
>>> we're using Git by itself, like this is still 2009. We don't. We switched 
>>> to GitLab because it offers us a lot more tools that "hooks". We have CI 
>>> pipelines that run on branches; merge requests; an entire API to construct 
>>> tools on top of our infrastructure.
>>>
>>>> We don't want special snowflakes, we just want to be able to do our work 
>>>> in the best way.
>>>
>>>
>>> Your "best way" has a high chance to make me waste my time, when we have 
>

Re: Problems commiting damned-lies package

[Carlos Soriano]

infrastructure to verify that things pushed to the repository do not break
>> the main development branch of a project: it's called the continuous
>> integration pipeline, and we have a process for it to run on topic
>> branches. We even have API in GitLab to:
>>
>>  - automatically create a merge request
>>  - set the target branch
>>  - automatically merge code once the CI pipeline passes
>>  - automatically remove the source branch when merged
>>
>> when pushing to the remote repository:
>> https://docs.gitlab.com/ee/user/project/push_options.html
>>
>> I do hope your script uses it. I'd hope for DL to do the same.
>>
>>
>>> Also, note that not all translators will have commit rights: only a
>>> reduced group of them. Breaking things in git is possible for both
>>> translators and developers: that's one of the reasons we use Git, to be
>>> able to revert commits and even revoke commit access to a person who breaks
>>> things several times.
>>>
>>
>> I don't want to manually revert stuff that's broken and got pushed to the
>> main development branch. I don't want broken stuff to land *in the first
>> place*.
>>
>> Git having easy revert operations is good for things that are
>> *discovered* to be broken later on; that doesn't mean people should push
>> broken localisations of the application documentation, with broken tags
>> that do not close properly, and get only discovered when trying to release
>> something. That's sacrificing maintenance time—*my* time—because you want
>> to save your time. Your time isn't any more precious than mine.
>>
>> Additionally, we have whole run times that get built every day; if a
>> translation breaks a library, or an application, the whole pipeline gets
>> stalled until the problem is solved. The amount of lost person time is
>> staggering.
>>
>> This is not a question of being 20 years o 20 days in the project: this
>>> is a question of helping us with our work, because that work is as valid as
>>> yours, and we all are responsible with it. pre-commit hooks can be
>>> implemented (they are already, but we could study if are enough or not) to
>>> avoid breaking things, but its really discouraging to follow DL's workflow
>>> to commit a 1-modified string in a PO file. Multiply it by 20...
>>>
>>
>> If people spent time improving Damned Lies instead of working around it
>> with their own scripts, we would probably have a better tool already.
>>
>> Or, maybe, a better tool already exists, and we should move to it.
>>
>> In any case, my point is that even people that can commit to Git *should
>> not* push to the main development branch. *Ever*. The mere fact that you
>> reference "commit hooks" makes me think you're basically thinking that
>> we're using Git by itself, like this is still 2009. We don't. We switched
>> to GitLab because it offers us a lot more tools that "hooks". We have CI
>> pipelines that run on branches; merge requests; an entire API to construct
>> tools on top of our infrastructure.
>>
>> We don't want special snowflakes, we just want to be able to do our work
>>> in the best way.
>>>
>>
>> Your "best way" has a high chance to make me waste my time, when we have
>> perfectly functional tools to avoid that.
>>
>> I'm grateful for the work done by localisation teams; lowering the bar of
>> contribution makes it better for everyone, but that should never come at
>> the cost of the stability of the platform.
>>
>> The solution to making GNOME software better is not to make everyone
>> expert developers, but to make sure our infrastructure is automated and
>> safe to contribute to—and "safe" doesn't mean "I can revert broken stuff
>> after the fact". That principle has been one of the driving force of a lot
>> of the changes in our infrastructure over the years.
>>
>> Ciao,
>>  Emmanuele.
>>
>> Regards
>>>
>>> El lun., 22 jun. 2020 a las 12:30, Emmanuele Bassi ()
>>> escribió:
>>>
>>>> Hi;
>>>>
>>>> to be brutally honest, as a maintainer I don't want any translator to
>>>> commit directly to Git—unless it's done to a separate branch and/or through
>>>> merge requests.
>>>>
>>>> Translators do not build the projects they translate, and they don't
>>>> (or cannot) know when the

Re: Problems commiting damned-lies package

[Daniel Mustieles García via gnome-i18n]

Again this is David against Goliat, and I'm tired of fighting...

I have no skills to improve DL, I only developed a script and made it
available to everyone who wants use/read/whatever with it. If if can be a
start point to improve DL great! but I'm not going to keep fighting against
something that I cannot change.

I don't know which features Gitlab offers, sorry if I still think like in
2009. Maybe someone with better knowledge than me could show us the proper
way or even help with a tool or a patch for DL. I made a bash script
because I don't know Python. I'm a translator, not a developer, sorry.

I'm leaving here the discussion/thread, but thanks for your comments and
your point of view.

Regards

El lun., 22 jun. 2020 a las 13:13, Emmanuele Bassi ()
escribió:

> On Mon, 22 Jun 2020 at 11:44, Daniel Mustieles García <
> daniel.mustie...@gmail.com> wrote:
>
>> Hi Emmanuele,
>>
>> Just a quick question: which is the difference between commiting directly
>> into Git and commiting through DL?
>>
>
> DL can, at least, centralise the place where tests are executed to ensure
> that things don't utterly break. Of course, it's not really a solution: now
> that we use GitLab, we already have a centralised place to run builds and
> tests.
>
> The fact that DL pushes to the main development branch *also* irks me to
> no end; at least DL acts as a filter, and ensures that *some* validation is
> actually performed.
>
>
>> PO file checks are the same (or should be), so commiting directly is not
>> more dangerous than using DL. the same checks DL makes into a PO file are
>> done in my script, for example. If a PO file breaks your module's building
>> it doesn't matter if I committed it directly into git or usind DL.
>>
>
> Your script is your own script. Unless everybody uses your script—in which
> case, it should be moved to a remote environment so that people don't have
> to have Git access—then it's pointless.
>
> But my point is that I don't want translators to have "scripts". I don't
> want translators to do anything more than translating. We have
> infrastructure to verify that things pushed to the repository do not break
> the main development branch of a project: it's called the continuous
> integration pipeline, and we have a process for it to run on topic
> branches. We even have API in GitLab to:
>
>  - automatically create a merge request
>  - set the target branch
>  - automatically merge code once the CI pipeline passes
>  - automatically remove the source branch when merged
>
> when pushing to the remote repository:
> https://docs.gitlab.com/ee/user/project/push_options.html
>
> I do hope your script uses it. I'd hope for DL to do the same.
>
>
>> Also, note that not all translators will have commit rights: only a
>> reduced group of them. Breaking things in git is possible for both
>> translators and developers: that's one of the reasons we use Git, to be
>> able to revert commits and even revoke commit access to a person who breaks
>> things several times.
>>
>
> I don't want to manually revert stuff that's broken and got pushed to the
> main development branch. I don't want broken stuff to land *in the first
> place*.
>
> Git having easy revert operations is good for things that are *discovered*
> to be broken later on; that doesn't mean people should push broken
> localisations of the application documentation, with broken tags that do
> not close properly, and get only discovered when trying to release
> something. That's sacrificing maintenance time—*my* time—because you want
> to save your time. Your time isn't any more precious than mine.
>
> Additionally, we have whole run times that get built every day; if a
> translation breaks a library, or an application, the whole pipeline gets
> stalled until the problem is solved. The amount of lost person time is
> staggering.
>
> This is not a question of being 20 years o 20 days in the project: this is
>> a question of helping us with our work, because that work is as valid as
>> yours, and we all are responsible with it. pre-commit hooks can be
>> implemented (they are already, but we could study if are enough or not) to
>> avoid breaking things, but its really discouraging to follow DL's workflow
>> to commit a 1-modified string in a PO file. Multiply it by 20...
>>
>
> If people spent time improving Damned Lies instead of working around it
> with their own scripts, we would probably have a better tool already.
>
> Or, maybe, a better tool already exists, and we should move to it.
>
> In any case, my 

Re: Problems commiting damned-lies package

[Emmanuele Bassi via gnome-i18n]

On Mon, 22 Jun 2020 at 11:44, Daniel Mustieles García <
daniel.mustie...@gmail.com> wrote:

> Hi Emmanuele,
>
> Just a quick question: which is the difference between commiting directly
> into Git and commiting through DL?
>

DL can, at least, centralise the place where tests are executed to ensure
that things don't utterly break. Of course, it's not really a solution: now
that we use GitLab, we already have a centralised place to run builds and
tests.

The fact that DL pushes to the main development branch *also* irks me to no
end; at least DL acts as a filter, and ensures that *some* validation is
actually performed.


> PO file checks are the same (or should be), so commiting directly is not
> more dangerous than using DL. the same checks DL makes into a PO file are
> done in my script, for example. If a PO file breaks your module's building
> it doesn't matter if I committed it directly into git or usind DL.
>

Your script is your own script. Unless everybody uses your script—in which
case, it should be moved to a remote environment so that people don't have
to have Git access—then it's pointless.

But my point is that I don't want translators to have "scripts". I don't
want translators to do anything more than translating. We have
infrastructure to verify that things pushed to the repository do not break
the main development branch of a project: it's called the continuous
integration pipeline, and we have a process for it to run on topic
branches. We even have API in GitLab to:

 - automatically create a merge request
 - set the target branch
 - automatically merge code once the CI pipeline passes
 - automatically remove the source branch when merged

when pushing to the remote repository:
https://docs.gitlab.com/ee/user/project/push_options.html

I do hope your script uses it. I'd hope for DL to do the same.


> Also, note that not all translators will have commit rights: only a
> reduced group of them. Breaking things in git is possible for both
> translators and developers: that's one of the reasons we use Git, to be
> able to revert commits and even revoke commit access to a person who breaks
> things several times.
>

I don't want to manually revert stuff that's broken and got pushed to the
main development branch. I don't want broken stuff to land *in the first
place*.

Git having easy revert operations is good for things that are *discovered*
to be broken later on; that doesn't mean people should push broken
localisations of the application documentation, with broken tags that do
not close properly, and get only discovered when trying to release
something. That's sacrificing maintenance time—*my* time—because you want
to save your time. Your time isn't any more precious than mine.

Additionally, we have whole run times that get built every day; if a
translation breaks a library, or an application, the whole pipeline gets
stalled until the problem is solved. The amount of lost person time is
staggering.

This is not a question of being 20 years o 20 days in the project: this is
> a question of helping us with our work, because that work is as valid as
> yours, and we all are responsible with it. pre-commit hooks can be
> implemented (they are already, but we could study if are enough or not) to
> avoid breaking things, but its really discouraging to follow DL's workflow
> to commit a 1-modified string in a PO file. Multiply it by 20...
>

If people spent time improving Damned Lies instead of working around it
with their own scripts, we would probably have a better tool already.

Or, maybe, a better tool already exists, and we should move to it.

In any case, my point is that even people that can commit to Git *should
not* push to the main development branch. *Ever*. The mere fact that you
reference "commit hooks" makes me think you're basically thinking that
we're using Git by itself, like this is still 2009. We don't. We switched
to GitLab because it offers us a lot more tools that "hooks". We have CI
pipelines that run on branches; merge requests; an entire API to construct
tools on top of our infrastructure.

We don't want special snowflakes, we just want to be able to do our work in
> the best way.
>

Your "best way" has a high chance to make me waste my time, when we have
perfectly functional tools to avoid that.

I'm grateful for the work done by localisation teams; lowering the bar of
contribution makes it better for everyone, but that should never come at
the cost of the stability of the platform.

The solution to making GNOME software better is not to make everyone expert
developers, but to make sure our infrastructure is automated and safe to
contribute to—and "safe" doesn't mean "I can revert broken stuff after the
fact". That p

Re: Problems commiting damned-lies package

[Daniel Mustieles García via gnome-i18n]

Hi Emmanuele,

Just a quick question: which is the difference between commiting directly
into Git and commiting through DL? PO file checks are the same (or should
be), so commiting directly is not more dangerous than using DL. the same
checks DL makes into a PO file are done in my script, for example. If a PO
file breaks your module's building it doesn't matter if I committed it
directly into git or usind DL.

Also, note that not all translators will have commit rights: only a reduced
group of them. Breaking things in git is possible for both translators and
developers: that's one of the reasons we use Git, to be able to revert
commits and even revoke commit access to a person who breaks things several
times.

Of course, having a tool or a feature in DL to upload a bunch of PO files
and commit them directly would be the best option, but we currently don no
have it.

This is not a question of being 20 years o 20 days in the project: this is
a question of helping us with our work, because that work is as valid as
yours, and we all are responsible with it. pre-commit hooks can be
implemented (they are already, but we could study if are enough or not) to
avoid breaking things, but its really discouraging to follow DL's workflow
to commit a 1-modified string in a PO file. Multiply it by 20...

We don't want special snowflakes, we just want to be able to do our work in
the best way.

Regards

El lun., 22 jun. 2020 a las 12:30, Emmanuele Bassi ()
escribió:

> Hi;
>
> to be brutally honest, as a maintainer I don't want any translator to
> commit directly to Git—unless it's done to a separate branch and/or through
> merge requests.
>
> Translators do not build the projects they translate, and they don't (or
> cannot) know when they break things. The only way maintainers know that a
> broken translation happened is that suddenly the CI mails us, and then we
> have to hunt down what happened behind out backs. This is even worse when
> you realise something has broken a long time ago because the release
> process is now impossible.
>
> I'd rather have an automated, web UI tool that pushed changes to a branch
> and opened a merge request that ran the CI pipeline (and maybe the dist
> process), than allowing translators to commit to Git directly. I don't
> really care if some translator is an old hand that was around when GNOME
> used CVS and scripted their way to push to dozens of repositories at once;
> we started using a lot of tooling to ensure things don't break, and even
> developers have started pushing things to development branches instead of
> committing directly to master. I don't see why translators have to be the
> special snowflakes of the whole GNOME project, and break stuff for everyone
> else just because of their 20 years old workflow.
>
> Ciao,
>  Emmanuele.
>
> On Mon, 22 Jun 2020 at 11:03, Daniel Mustieles García via gnome-i18n <
> gnome-i18n@gnome.org> wrote:
>
>> Some time ago I talked about this with +Carlos Soriano
>>  . I asked him about the possibility of creating a
>> user's group in Gitlab, formed by some team coordinators, which will have
>> commit rights to be able to commit a bunch of translations due to the heavy
>> clickwork must be done in DL. Still waiting...
>>
>> Me (and some other team coordinators) got Git access before migration to
>> Gitlab, and it was not a problem. Having such rights will help us a lot to
>> be more agile maintaining and commiting translations. Yes, I currently have
>> those rights and can use an automated script [1] to ease my life, but I
>> don't have commit rights in some new modules (app-icon-preview,
>> shortwave...). I'd like to formerly request this feature/rigths. If we
>> found any problem with a wrong commit or something like that is quick and
>> easy to revert that commit; if a user with rights uses them for other
>> things that translations is quick and easy to revoke those privileges.
>> Advantages for us to maintain and keep translations up-to-date are huge.
>>
>> Please consider this request and let's work together to make it possible
>> in the best way.
>>
>> Best regards.
>>
>> [1]https://github.com/dmustieles/gnome_scripts/blob/master/gttk.sh
>>
>> El dom., 21 jun. 2020 a las 20:43, Matej Urban via gnome-i18n (<
>> gnome-i18n@gnome.org>) escribió:
>>
>>> Hello,
>>> some time ago I complained about inability to commit damned-lies package
>>> due to wrong access rights. Ok, I can live with that, but lately I get this
>>> error on many, many packages, especially new ones, like:
>>>
>>> app-icon-preview, authenticator, fractal, fragments, gnome-keys

Re: Problems commiting damned-lies package

[Emmanuele Bassi via gnome-i18n]

Hi;

to be brutally honest, as a maintainer I don't want any translator to
commit directly to Git—unless it's done to a separate branch and/or through
merge requests.

Translators do not build the projects they translate, and they don't (or
cannot) know when they break things. The only way maintainers know that a
broken translation happened is that suddenly the CI mails us, and then we
have to hunt down what happened behind out backs. This is even worse when
you realise something has broken a long time ago because the release
process is now impossible.

I'd rather have an automated, web UI tool that pushed changes to a branch
and opened a merge request that ran the CI pipeline (and maybe the dist
process), than allowing translators to commit to Git directly. I don't
really care if some translator is an old hand that was around when GNOME
used CVS and scripted their way to push to dozens of repositories at once;
we started using a lot of tooling to ensure things don't break, and even
developers have started pushing things to development branches instead of
committing directly to master. I don't see why translators have to be the
special snowflakes of the whole GNOME project, and break stuff for everyone
else just because of their 20 years old workflow.

Ciao,
 Emmanuele.

On Mon, 22 Jun 2020 at 11:03, Daniel Mustieles García via gnome-i18n <
gnome-i18n@gnome.org> wrote:

> Some time ago I talked about this with +Carlos Soriano
>  . I asked him about the possibility of creating a
> user's group in Gitlab, formed by some team coordinators, which will have
> commit rights to be able to commit a bunch of translations due to the heavy
> clickwork must be done in DL. Still waiting...
>
> Me (and some other team coordinators) got Git access before migration to
> Gitlab, and it was not a problem. Having such rights will help us a lot to
> be more agile maintaining and commiting translations. Yes, I currently have
> those rights and can use an automated script [1] to ease my life, but I
> don't have commit rights in some new modules (app-icon-preview,
> shortwave...). I'd like to formerly request this feature/rigths. If we
> found any problem with a wrong commit or something like that is quick and
> easy to revert that commit; if a user with rights uses them for other
> things that translations is quick and easy to revoke those privileges.
> Advantages for us to maintain and keep translations up-to-date are huge.
>
> Please consider this request and let's work together to make it possible
> in the best way.
>
> Best regards.
>
> [1]https://github.com/dmustieles/gnome_scripts/blob/master/gttk.sh
>
> El dom., 21 jun. 2020 a las 20:43, Matej Urban via gnome-i18n (<
> gnome-i18n@gnome.org>) escribió:
>
>> Hello,
>> some time ago I complained about inability to commit damned-lies package
>> due to wrong access rights. Ok, I can live with that, but lately I get this
>> error on many, many packages, especially new ones, like:
>>
>> app-icon-preview, authenticator, fractal, fragments, gnome-keysign,
>> obfuscate, shortwave ... list goes on
>>
>> Is there any special reason why not even coordinators are able to do that
>> the usual way? Yes, I know, there is another way to do it, but it is
>> cumbersome and takes a lot, lot, lot time to do it and what is more
>> important, each project has some specifics. For this reasons I do not push
>> these ...
>>
>> Please advise or better, please bend at least for coordinators these
>> rules.
>>
>> Thank you,
>> Matej
>>
>>
>> ___
>> gnome-i18n mailing list
>> gnome-i18n@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>


-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Problems commiting damned-lies package

[Daniel Mustieles García via gnome-i18n]

Some time ago I talked about this with +Carlos Soriano 
. I asked him about the possibility of creating a user's group in Gitlab,
formed by some team coordinators, which will have commit rights to be able
to commit a bunch of translations due to the heavy clickwork must be done
in DL. Still waiting...

Me (and some other team coordinators) got Git access before migration to
Gitlab, and it was not a problem. Having such rights will help us a lot to
be more agile maintaining and commiting translations. Yes, I currently have
those rights and can use an automated script [1] to ease my life, but I
don't have commit rights in some new modules (app-icon-preview,
shortwave...). I'd like to formerly request this feature/rigths. If we
found any problem with a wrong commit or something like that is quick and
easy to revert that commit; if a user with rights uses them for other
things that translations is quick and easy to revoke those privileges.
Advantages for us to maintain and keep translations up-to-date are huge.

Please consider this request and let's work together to make it possible in
the best way.

Best regards.

[1]https://github.com/dmustieles/gnome_scripts/blob/master/gttk.sh

El dom., 21 jun. 2020 a las 20:43, Matej Urban via gnome-i18n (<
gnome-i18n@gnome.org>) escribió:

> Hello,
> some time ago I complained about inability to commit damned-lies package
> due to wrong access rights. Ok, I can live with that, but lately I get this
> error on many, many packages, especially new ones, like:
>
> app-icon-preview, authenticator, fractal, fragments, gnome-keysign,
> obfuscate, shortwave ... list goes on
>
> Is there any special reason why not even coordinators are able to do that
> the usual way? Yes, I know, there is another way to do it, but it is
> cumbersome and takes a lot, lot, lot time to do it and what is more
> important, each project has some specifics. For this reasons I do not push
> these ...
>
> Please advise or better, please bend at least for coordinators these rules.
>
> Thank you,
> Matej
>
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Problems commiting damned-lies package

[Matej Urban via gnome-i18n]

U,
I have absolutely NO IDEA, what you're asking me ;).

I will get into it.
M!

On Sun, Jun 21, 2020 at 9:12 PM Rafael Fontenelle 
wrote:

> Hello Matej,
>
> Em dom., 21 de jun. de 2020 às 15:43, Matej Urban via gnome-i18n
>  escreveu:
> >
> > Hello,
> > some time ago I complained about inability to commit damned-lies package
> due to wrong access rights. Ok, I can live with that, but lately I get this
> error on many, many packages, especially new ones, like:
> >
> > app-icon-preview, authenticator, fractal, fragments, gnome-keysign,
> obfuscate, shortwave ... list goes on
> >
> > Is there any special reason why not even coordinators are able to do
> that the usual way? Yes, I know, there is another way to do it, but it is
> cumbersome and takes a lot, lot, lot time to do it and what is more
> important, each project has some specifics. For this reasons I do not push
> these ...
> >
> > Please advise or better, please bend at least for coordinators these
> rules.
> >
> > Thank you,
> > Matej
> >
>
> Are all the modules that report wrong access rights from the "World"
> namespace in GNOME GitLab?  Asking this because those who are members
> of the default namespace "GNOME" not necessarily are members in
> "GNOME" as well.
>
> By the way, by namespace I mean the "World" in
> https://gitlab.gnome.org/World/Authenticator
>
> Regards,
> Rafael Fontenelle
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Problems commiting damned-lies package

[Rafael Fontenelle]

Hello Matej,

Em dom., 21 de jun. de 2020 às 15:43, Matej Urban via gnome-i18n
 escreveu:
>
> Hello,
> some time ago I complained about inability to commit damned-lies package due 
> to wrong access rights. Ok, I can live with that, but lately I get this error 
> on many, many packages, especially new ones, like:
>
> app-icon-preview, authenticator, fractal, fragments, gnome-keysign, 
> obfuscate, shortwave ... list goes on
>
> Is there any special reason why not even coordinators are able to do that the 
> usual way? Yes, I know, there is another way to do it, but it is cumbersome 
> and takes a lot, lot, lot time to do it and what is more important, each 
> project has some specifics. For this reasons I do not push these ...
>
> Please advise or better, please bend at least for coordinators these rules.
>
> Thank you,
> Matej
>

Are all the modules that report wrong access rights from the "World"
namespace in GNOME GitLab?  Asking this because those who are members
of the default namespace "GNOME" not necessarily are members in
"GNOME" as well.

By the way, by namespace I mean the "World" in
https://gitlab.gnome.org/World/Authenticator

Regards,
Rafael Fontenelle
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Problems commiting damned-lies package

[Matej Urban via gnome-i18n]

Hello,
some time ago I complained about inability to commit damned-lies package
due to wrong access rights. Ok, I can live with that, but lately I get this
error on many, many packages, especially new ones, like:

app-icon-preview, authenticator, fractal, fragments, gnome-keysign,
obfuscate, shortwave ... list goes on

Is there any special reason why not even coordinators are able to do that
the usual way? Yes, I know, there is another way to do it, but it is
cumbersome and takes a lot, lot, lot time to do it and what is more
important, each project has some specifics. For this reasons I do not push
these ...

Please advise or better, please bend at least for coordinators these rules.

Thank you,
Matej
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Add libhandy to Damned Lies

[Andre Klapper]

On Thu, 2020-06-11 at 18:05 -0300, Rafael Fontenelle wrote:
> It seems that libhandy is now on Damned Lies[1]. So yay!
>
> I'm trying to figure out the context of some strings, can you please
> tell me how I can see libhandy's strings? I opened Glade and looked
> around, but I'm not very familiar with it.

FYI I ran "intltool-update --pot" in the "po" folder of a git checkout
and created https://gitlab.gnome.org/GNOME/libhandy/-/issues/292 for
strings which might welcome improvements / clarification, as I don't
expect translators to open stuff in Glade but look at strings only.

Cheers,
andre
--
Andre Klapper  |  ak...@gmx.net
https://blogs.gnome.org/aklapper/


___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Add libhandy to Damned Lies

[Rafael Fontenelle]

Hey Adrien,

It seems that libhandy is now on Damned Lies[1]. So yay!

I'm trying to figure out the context of some strings, can you please
tell me how I can see libhandy's strings? I opened Glade and looked
around, but I'm not very familiar with it.

[1] https://l10n.gnome.org/module/libhandy/

Best regards,
Rafael Fontenelle

Em seg., 8 de jun. de 2020 às 05:29, Adrien Plazas via gnome-i18n
 escreveu:
>
> Hi i18n team!
>
> libhandy migrated to GNOME's GitLab two weeks ago, the library is (I
> suppose) correctly internationalized, but not localized.
>
> https://gitlab.gnome.org/GNOME/libhandy
>
> It would be nice to have it on Damned Lies to localize the dev-facing
> strings, especially as it got pretty popular.
>
> Cheers,
> Adrien Plazas
>
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Add libhandy to Damned Lies

[Adrien Plazas via gnome-i18n]

Hi i18n team!

libhandy migrated to GNOME's GitLab two weeks ago, the library is (I 
suppose) correctly internationalized, but not localized.


https://gitlab.gnome.org/GNOME/libhandy

It would be nice to have it on Damned Lies to localize the dev-facing 
strings, especially as it got pretty popular.


Cheers,
Adrien Plazas


___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Adding Python GTK+ 3 Tutorial to Damned Lies

[Claude Paroz]

Le 05.04.20 à 11:18, Sebastian Pölsterl a écrit :
> Hi Claude,
> 
> the text isn't changing very often these days, so having a .pot file
> added would be no problem.
> 
> Once I added the .pot file, what would be required for integrating it
> into Damned Lies?

Nothing more, I guess.

> Can the project remain on github or should it be moved
> git GNOME's gitlab?

It can remain on github, the downside being that D-L cannot push
translations, so coordinators have to manually create pull requests.

Claude


> Am 21.03.20 um 23:06 schrieb Claude Paroz:
>> Hi Sebastian,
>>
>> Le 20.03.20 à 12:06, Sebastian Pölsterl a écrit :
>>> Dear translation team,
>>>
>>> I'm the author of The Python GTK+ 3 Tutorial
>>> (https://python-gtk-3-tutorial.readthedocs.io/) and recently was asked
>>> whether an integration with Damned Lies is possible (see
>>> https://github.com/sebp/PyGObject-Tutorial/issues/160). I never worked
>>> in translation before, therefore I'm not sure what would be required to
>>> make this happen.
>>>
>>> The tutorial is written in reStructered text using Sphinx. While Sphinx
>>> has support for i18n, I'm not sure whether integration into Damned Lies
>>> is possible at all.
>>
>> It is surely possible, but Damned Lies doesn't currently support the
>> sphinx i18n toolchain, so you'd have to provide the pot files in the
>> source code (and update them regularly).
>>
>>> Any suggestions on what be the best way forward to make it easy for
>>> translators to contribute would highly welcome.
>>
>> The sphinx toolchain is creating a po file for each subdocument, which
>> is good when you have big documents, less when you have smaller
>> documents, as this means more manipulations by translators and
>> coordinators. This is also taking much more space in the D-L interface.
>>
>> One solution would be to merge all pot files into one, then re-splitting
>> the translated po files into multiple po files through msgmerge. This
>> would certainly require more work at Makefile level...
>> See https://stackoverflow.com/questions/15408348
>>
>> Claude
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Adding Python GTK+ 3 Tutorial to Damned Lies

[Sebastian Pölsterl]

Hi Claude,

the text isn't changing very often these days, so having a .pot file 
added would be no problem.


Once I added the .pot file, what would be required for integrating it 
into Damned Lies? Can the project remain on github or should it be moved 
git GNOME's gitlab?


Thanks for your help.

Sebastian


Am 21.03.20 um 23:06 schrieb Claude Paroz:

Hi Sebastian,

Le 20.03.20 à 12:06, Sebastian Pölsterl a écrit :

Dear translation team,

I'm the author of The Python GTK+ 3 Tutorial
(https://python-gtk-3-tutorial.readthedocs.io/) and recently was asked
whether an integration with Damned Lies is possible (see
https://github.com/sebp/PyGObject-Tutorial/issues/160). I never worked
in translation before, therefore I'm not sure what would be required to
make this happen.

The tutorial is written in reStructered text using Sphinx. While Sphinx
has support for i18n, I'm not sure whether integration into Damned Lies
is possible at all.


It is surely possible, but Damned Lies doesn't currently support the
sphinx i18n toolchain, so you'd have to provide the pot files in the
source code (and update them regularly).


Any suggestions on what be the best way forward to make it easy for
translators to contribute would highly welcome.


The sphinx toolchain is creating a po file for each subdocument, which
is good when you have big documents, less when you have smaller
documents, as this means more manipulations by translators and
coordinators. This is also taking much more space in the D-L interface.

One solution would be to merge all pot files into one, then re-splitting
the translated po files into multiple po files through msgmerge. This
would certainly require more work at Makefile level...
See https://stackoverflow.com/questions/15408348

Claude


___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Adding Python GTK+ 3 Tutorial to Damned Lies

[Claude Paroz]

Hi Sebastian,

Le 20.03.20 à 12:06, Sebastian Pölsterl a écrit :
> Dear translation team,
> 
> I'm the author of The Python GTK+ 3 Tutorial
> (https://python-gtk-3-tutorial.readthedocs.io/) and recently was asked
> whether an integration with Damned Lies is possible (see
> https://github.com/sebp/PyGObject-Tutorial/issues/160). I never worked
> in translation before, therefore I'm not sure what would be required to
> make this happen.
> 
> The tutorial is written in reStructered text using Sphinx. While Sphinx
> has support for i18n, I'm not sure whether integration into Damned Lies
> is possible at all.

It is surely possible, but Damned Lies doesn't currently support the
sphinx i18n toolchain, so you'd have to provide the pot files in the
source code (and update them regularly).

> Any suggestions on what be the best way forward to make it easy for
> translators to contribute would highly welcome.

The sphinx toolchain is creating a po file for each subdocument, which
is good when you have big documents, less when you have smaller
documents, as this means more manipulations by translators and
coordinators. This is also taking much more space in the D-L interface.

One solution would be to merge all pot files into one, then re-splitting
the translated po files into multiple po files through msgmerge. This
would certainly require more work at Makefile level...
See https://stackoverflow.com/questions/15408348

Claude
-- 
www.2xlibre.net
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Adding Python GTK+ 3 Tutorial to Damned Lies

[Sebastian Pölsterl]

Dear translation team,

I'm the author of The Python GTK+ 3 Tutorial 
(https://python-gtk-3-tutorial.readthedocs.io/) and recently was asked 
whether an integration with Damned Lies is possible (see 
https://github.com/sebp/PyGObject-Tutorial/issues/160). I never worked 
in translation before, therefore I'm not sure what would be required to 
make this happen.


The tutorial is written in reStructered text using Sphinx. While Sphinx 
has support for i18n, I'm not sure whether integration into Damned Lies 
is possible at all.


Any suggestions on what be the best way forward to make it easy for 
translators to contribute would highly welcome.



Best regards,
Sebastian
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Translating Tau using Damned Lies

[Rasmus Thomsen]

Hello list,

Would it be possible for Tau to be translated using Damned Lies?
It's a fast text editor written in Rust. It's currently being
translated using Weblate with 8 actively supported languages, see

https://hosted.weblate.org/projects/Tau/translation/#translations

I've made an issue for migration to D-L over on GNOME's Gitlab, to
track changes that may need to be done to Tau in order to work with D-
L:

https://gitlab.gnome.org/World/Tau/issues/369

Thank you very much,

Rasmus Thomsen



signature.asc
Description: PGP signature
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Changing the pt_BR translated name of Damned Lies back to English

[Rafael Fontenelle]

Hello,

The Brazilian Portuguese language team is considering changing the
translated name of Damned Lies.

A long time ago, its name was translated to "Mentiras Cabeludas",
which is a very close translation, but we find ourselves saying in
Portuguese "D-L" or "Damned Lies (Mentiras Cabeludas)". One
contributor reported that did not know the existence of the translated
name.

However, changing the name has a funny impact under the title label
(in the web browser tab) "Damned Lies about GNOME". If I change the
name back to English, I would not be able to keep this sentence or it
would not make sense when reading in Portuguese.  Reason why I'm
considering to translate "Damned Lies about GNOME" to only "Damned
Lies", and that's what would show up in title tab.

Does Claude or any other i18n Coordinator have any objection on me
changing the translation "Mentiras Cabeludas" back to "Damned Lies"?

Best regards,
Rafael Fontenelle
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Damned-Lies API

[Claude Paroz]

Hi all,

I just put in production the beta version of a real REST API on:
https://l10n.gnome.org/api/v1/

It is meant to replace at due time the existing XML interfaces 
documented on https://wiki.gnome.org/DamnedLies#XML_interfaces


As I said, we are at beta stage, so I'm totally open to fixes and 
improvements. Please open tickets on 
https://gitlab.gnome.org/Infrastructure/damned-lies/issues if you have 
anything to contribute.


And please, don't count on the current version to be stable yet.

Claude
--
www.2xlibre.net
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Wrong stats in Damned Lies

[Daniel Mustieles García via gnome-i18n]

Thanks!

El mar., 4 sept. 2018 18:09, Piotr Drąg  escribió:

> 2018-09-04 8:20 GMT+02:00 Daniel Mustieles García <
> daniel.mustie...@gmail.com>:
> > Ok, I will fix manually those lines.
> >
> > What (GNOME-specific) alternatives do we have to Gtranslator?
> >
>
> I don’t think we have anything in GNOME for this purpose. I hear good
> things about Poedit, and it’s actively maintained.
>
> Best regards,
>
> --
> Piotr Drąg
> https://piotrdrag.fedorapeople.org
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Wrong stats in Damned Lies

[Piotr Drąg via gnome-i18n]

2018-09-04 8:20 GMT+02:00 Daniel Mustieles García :
> Ok, I will fix manually those lines.
>
> What (GNOME-specific) alternatives do we have to Gtranslator?
>

I don’t think we have anything in GNOME for this purpose. I hear good
things about Poedit, and it’s actively maintained.

Best regards,

-- 
Piotr Drąg
https://piotrdrag.fedorapeople.org
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Wrong stats in Damned Lies

[Daniel Mustieles García via gnome-i18n]

Ok, I will fix manually those lines.

What (GNOME-specific) alternatives do we have to Gtranslator?

Regards

2018-09-03 18:22 GMT+02:00 Piotr Drąg :

> 2018-09-03 18:11 GMT+02:00 Claude Paroz :
> > Le 03. 09. 18 à 17:09, Piotr Drąg via gnome-i18n a écrit :
> >>
> >> 2018-09-03 10:31 GMT+02:00 Daniel Mustieles García via gnome-i18n
> >> :
> >>>
> >>> Hi guys,
> >>>
> >>> I've detected a wrong behaviour in Spanish Damned Lies' page. There are
> >>> several modules showing a 0% strings translated, and 0% strings
> >>> available...
> >>> stats bar appears in gray color. Here is an example:
> >>> https://l10n.gnome.org/languages/es/gnome-gimp/doc/ (this page seems
> to
> >>> be
> >>> OK for DE language)
> >>>
> >>> Maybe something is not upating stast properly?
> >>>
> >>
> >> It looks like a bug in gimp-help or damned-lies. You should report it.
> >
> >
> > After a quick debug session, it looks like that some unfortunate line
> breaks
> > in some file headers are disturbing the translate-toolkit po parsing we
> are
> > using for calculating file stats.
> > For example:
> >
> > #
> > # Daniel Mustieles , 2011, 2015.
> > , 2017, 2018.
> > #
> > ...
> >
> > It doesn't seem to be unvalid syntax as of msgfmt -vc, however I think it
> > will be easier to fix those lines instead of waiting for a
> translate-toolkit
> > update.
> >
>
> This is https://bugzilla.gnome.org/show_bug.cgi?id=673655. We should
> advertise that using gtranslator is not recommended.
>
> Best regards,
>
> --
> Piotr Drąg
> https://piotrdrag.fedorapeople.org
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Wrong stats in Damned Lies

[Piotr Drąg via gnome-i18n]

2018-09-03 18:11 GMT+02:00 Claude Paroz :
> Le 03. 09. 18 à 17:09, Piotr Drąg via gnome-i18n a écrit :
>>
>> 2018-09-03 10:31 GMT+02:00 Daniel Mustieles García via gnome-i18n
>> :
>>>
>>> Hi guys,
>>>
>>> I've detected a wrong behaviour in Spanish Damned Lies' page. There are
>>> several modules showing a 0% strings translated, and 0% strings
>>> available...
>>> stats bar appears in gray color. Here is an example:
>>> https://l10n.gnome.org/languages/es/gnome-gimp/doc/ (this page seems to
>>> be
>>> OK for DE language)
>>>
>>> Maybe something is not upating stast properly?
>>>
>>
>> It looks like a bug in gimp-help or damned-lies. You should report it.
>
>
> After a quick debug session, it looks like that some unfortunate line breaks
> in some file headers are disturbing the translate-toolkit po parsing we are
> using for calculating file stats.
> For example:
>
> #
> # Daniel Mustieles , 2011, 2015.
> , 2017, 2018.
> #
> ...
>
> It doesn't seem to be unvalid syntax as of msgfmt -vc, however I think it
> will be easier to fix those lines instead of waiting for a translate-toolkit
> update.
>

This is https://bugzilla.gnome.org/show_bug.cgi?id=673655. We should
advertise that using gtranslator is not recommended.

Best regards,

-- 
Piotr Drąg
https://piotrdrag.fedorapeople.org
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Wrong stats in Damned Lies

[Claude Paroz]

Le 03. 09. 18 à 17:09, Piotr Drąg via gnome-i18n a écrit :

2018-09-03 10:31 GMT+02:00 Daniel Mustieles García via gnome-i18n
:

Hi guys,

I've detected a wrong behaviour in Spanish Damned Lies' page. There are
several modules showing a 0% strings translated, and 0% strings available...
stats bar appears in gray color. Here is an example:
https://l10n.gnome.org/languages/es/gnome-gimp/doc/ (this page seems to be
OK for DE language)

Maybe something is not upating stast properly?



It looks like a bug in gimp-help or damned-lies. You should report it.


After a quick debug session, it looks like that some unfortunate line 
breaks in some file headers are disturbing the translate-toolkit po 
parsing we are using for calculating file stats.

For example:

#
# Daniel Mustieles , 2011, 2015.
, 2017, 2018.
#
...

It doesn't seem to be unvalid syntax as of msgfmt -vc, however I think 
it will be easier to fix those lines instead of waiting for a 
translate-toolkit update.


Claude
--
www.2xlibre.net
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Wrong stats in Damned Lies

[Piotr Drąg via gnome-i18n]

2018-09-03 10:31 GMT+02:00 Daniel Mustieles García via gnome-i18n
:
> Hi guys,
>
> I've detected a wrong behaviour in Spanish Damned Lies' page. There are
> several modules showing a 0% strings translated, and 0% strings available...
> stats bar appears in gray color. Here is an example:
> https://l10n.gnome.org/languages/es/gnome-gimp/doc/ (this page seems to be
> OK for DE language)
>
> Maybe something is not upating stast properly?
>

It looks like a bug in gimp-help or damned-lies. You should report it.

Best regards,

-- 
Piotr Drąg
https://piotrdrag.fedorapeople.org
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Wrong stats in Damned Lies

[Daniel Mustieles García via gnome-i18n]

Hi guys,

I've detected a wrong behaviour in Spanish Damned Lies' page. There are
several modules showing a 0% strings translated, and 0% strings
available... stats bar appears in gray color. Here is an example:
https://l10n.gnome.org/languages/es/gnome-gimp/doc/ (this page seems to be
OK for DE language)

Maybe something is not upating stast properly?

Thanks in advance
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: modernising Geary's translation system and Damned Lies

[Michael Gratton]

On Tue, Oct 24, 2017 at 2:44 AM, Piotr Drąg  
wrote:


Currently I monitor git and make changes to Damned Lies as soon as I 
notice them. If and when I don’t have that amount of free time 
anymore, we’ll have to figure out something more formal. But for 
now you don’t have to worry about it. I’m looking forward to 
Geary ditching intltool!




Okay, cool. As you mentioned on the bug I'll look into adding a 
po/Makevars, and work out a stop-gap solution for generating 
po/geary.pot and get it landed.




Also, what's the current best tooling for translating Mallard help 
docs? Is it possible to use gettext's ITS support, or is yelp-tools 
really required?
I don’t think gettext is designed for that use-case. It’s best to 
ask on gnome-doc-list, though.


Thanks, will do!

//Mike

--
⊨ Michael Gratton, Percept Wrangler.
⚙ <http://mjog.vee.net/>


___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: modernising Geary's translation system and Damned Lies

[Piotr Drąg]

2017-10-23 11:28 GMT+02:00 Michael Gratton :
> Hi all,
>
> We're planning on modernising Geary's translation and build systems for the
> next release, and I wanted to get some feedback on what's the best way to do
> this from the perspective of Damned Lies.
>
> The plan is currently:
>
> - Switch UI from intltool to gettext in the next week or so
> - Switch the general build to Meson once its ready in a few months
> - Switch Help from xml2po to itstool or maybe gettext (maybe later?)
>
> Do any of these require configuration updates in Damned Lies, or should it
> just pick up the chances from the repo automatically? If the former, what's
> the process for getting Damned Lies' config updated? An email here? A ticket
> in b.g.o?
>

Currently I monitor git and make changes to Damned Lies as soon as I
notice them. If and when I don’t have that amount of free time
anymore, we’ll have to figure out something more formal. But for now
you don’t have to worry about it.

I’m looking forward to Geary ditching intltool!

> Also, what's the current best tooling for translating Mallard help docs? Is
> it possible to use gettext's ITS support, or is yelp-tools really required?
>

I don’t think gettext is designed for that use-case. It’s best to ask
on gnome-doc-list, though.

Best regards,

-- 
Piotr Drąg
https://piotrdrag.fedorapeople.org
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

modernising Geary's translation system and Damned Lies

[Michael Gratton]

Hi all,

We're planning on modernising Geary's translation and build systems for 
the next release, and I wanted to get some feedback on what's the best 
way to do this from the perspective of Damned Lies.


The plan is currently:

- Switch UI from intltool to gettext in the next week or so
- Switch the general build to Meson once its ready in a few months
- Switch Help from xml2po to itstool or maybe gettext (maybe later?)

Do any of these require configuration updates in Damned Lies, or should 
it just pick up the chances from the repo automatically? If the former, 
what's the process for getting Damned Lies' config updated? An email 
here? A ticket in b.g.o?


Also, what's the current best tooling for translating Mallard help 
docs? Is it possible to use gettext's ITS support, or is yelp-tools 
really required?


Cheers!
//Mike

--
⊨ Michael Gratton, Percept Wrangler.
⚙ <http://mjog.vee.net/>


___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Two damned lies urls for the same module

[Daniel]

Hello, it seems that damned lies created two different pages for the
translation of the same module, namely gnome-software.
Please check the last links from here: https://l10n.gnome.org/users/cyb
errider/
They are https://l10n.gnome.org/vertimus/1608/903/33 and https://l10n.g
nome.org/vertimus/1608/1050/33 and they both point to the master branch
of gnome-software.
Is this an issue with the platform?

Kindly regards, Daniel___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: damned lies

[Claude Paroz]

Le 01. 05. 17 à 14:12, Fabio Tomat a écrit :

Greetings
I'm the coordinator of friulian.
Today I realized that in damned lies, at the user settings, when I look
at the languages available for the web site, they are all written in the
native language, except for "Friulian" which should be "Furlan".

Where can I fix that problem?


Hi Fabio,

The localized names are taken from a Django structure:
https://github.com/django/django/blob/master/django/conf/locale/__init__.py 
(See the 'name_local key).


In the long term, providing a Friulian translation to Django could be nice.
Meanwhile, it shouldn't be too hard to adapt the code with some 
hardcoded names here:

https://git.gnome.org/browse/damned-lies/tree/people/views.py#n39

Claude
--
www.2xlibre.net
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

damned lies

[Fabio Tomat]

Greetings
I'm the coordinator of friulian.
Today I realized that in damned lies, at the user settings, when I look at
the languages available for the web site, they are all written in the
native language, except for "Friulian" which should be "Furlan".

Where can I fix that problem?

thank you
Best regards

Fabio T.
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies vs git statistic

[Claude Paroz]

Le 21. 03. 17 à 16:23, Danylo Korostil a écrit :
(...)

> I used to have few commands to handle my workflow,approximately I
> update 100 modules during string freeze period. Some of them is really
> small (update few strings), so, git pull&&intltool-update&&gedit&&git
> commit&&git push was really fast. 

Note that you should be able to keep your workflow and replace
"intltool-update" by "wget -O po/language.po
https://l10n.gnome.org/POT/module.branch/module.branch.language.po";.
It is more verbose, but you could make some alias. Unfortunately, it
would be a bit more complicated to replace the merge functionaliy of
intltool-update (in the case you already modified your po file).

As the one who have to adapt DL code for various po creation/update
methods, I also agree having a common method would be simpler.

However, the "intltool to pure gettext" current transition is probably
unavoidable, as intltool is mostly unmaintained these days and gettext
made real progress wrt extracting strings from various formats.

Claude
-- 
www.2xlibre.net
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies vs git statistic

[Daniel Mustieles García]

Maybe you would like to take a look into mi repo, where you can find some
useful scripts to handle Po files against DL:

https://github.com/dmustieles/gnome_scripts

untranslated2.sh donwloads all untranslated Po files from an specific
moduleset, allowing yo to set an unstranlated strings limit if you want so.

gttk.sh is a complete script to commit and push transtions into git: just
set the variables to match your local folders and go ahead!

My 2 cents ;)

P.S. gedit as a translation tool? really??

2017-03-21 16:23 GMT+01:00 Danylo Korostil :

> On 21.03.17 15:48, Piotr Drąg wrote:
>
> You could adapt https://git.gnome.org/browse/gtk+/tree/make-pot (all
> you need is set GETTEXT_PACKAGE in line 39 to e.g. gnome-shell) to
> generate a .pot file locally or even deal with make and friends, but I
> would advise against it. Some modules use the ITS feature of gettext
> to extract, among many others, polkit’s .policy files, and the rules
> for that are not yet in any released version of polkit. Using
> damned-lies avoids this problem and ensures that you have every string
> in your translation.
>
> If you’re interested in how damned-lies works in this regard, take a
> look at <https://git.gnome.org/browse/damned-lies/log/?qt=grep&q=gettext> 
> <https://git.gnome.org/browse/damned-lies/log/?qt=grep&q=gettext>,
> specifically commits from 2015 onwards.
>
> Best regards,
>
> Thanks for your answer!
>
> But I have to agree with Ask. Now I have to spend more time to translate
> GNOME. I used to have few commands to handle my workflow, approximately I
> update 100 modules during string freeze period. Some of them is really
> small (update few strings), so, git pull&&intltool-update&&gedit&&git
> commit&&git push was really fast. I used DL only to monitor unfinished
> modules. Since this release I have to download everything from browser,
> which isn't cool. It means I have to spend more time on downloading and
> less on translating.
>
> I won't stop translating, but this is an issue for me since I do it in my
> spare time. We have to convert DL into Gnome Pootle-like service or provide
> common translators workflow for every gnome module.
>
>
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies vs git statistic

[Danylo Korostil]

On 21.03.17 15:48, Piotr Drąg wrote:

You could adapthttps://git.gnome.org/browse/gtk+/tree/make-pot  (all
you need is set GETTEXT_PACKAGE in line 39 to e.g. gnome-shell) to
generate a .pot file locally or even deal with make and friends, but I
would advise against it. Some modules use the ITS feature of gettext
to extract, among many others, polkit’s .policy files, and the rules
for that are not yet in any released version of polkit. Using
damned-lies avoids this problem and ensures that you have every string
in your translation.

If you’re interested in how damned-lies works in this regard, take a
look at<https://git.gnome.org/browse/damned-lies/log/?qt=grep&q=gettext>,
specifically commits from 2015 onwards.

Best regards,


Thanks for your answer!

But I have to agree with Ask. Now I have to spend more time to translate 
GNOME. I used to have few commands to handle my workflow,approximately I 
update 100 modules during string freeze period. Some of them is really 
small (update few strings), so, git pull&&intltool-update&&gedit&&git 
commit&&git push was really fast. I used DL only to monitor unfinished 
modules. Since this release I have to download everything from browser, 
which isn't cool. It means I have to spend more time on downloading and 
less on translating.


I won't stop translating, but this is an issue for me since I do it in 
my spare time. We have to convert DL into Gnome Pootle-like service or 
provide common translators workflow for every gnome module.



___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies vs git statistic

[Piotr Drąg]

2017-03-21 14:29 GMT+01:00 Danylo Korostil :
> On 21.03.17 15:12, Piotr Drąg wrote:
>>
>> Hi Danylo,
>>
>> gnome-shell is indeed one of the modules that don’t use intltool
>> anymore. You should download the .po file from damned-lies and don’t
>> run intltool-update on it, otherwise some parts may end up
>> untranslated. One unscientific method to check if a module is
>> gettext-exclusive is looking at the file paths in the .po file.
>> Intltool uses relative paths, so file names start with “../”, while
>> gettext uses absolute paths.
>>
>> Hope this helps,
>
>
> Hey Piotr,
>
> Thanks for your explanation!
>
> I'm wondering what DL uses to retrieve these strings? Is it possible to get
> them without DL?
>

You could adapt https://git.gnome.org/browse/gtk+/tree/make-pot (all
you need is set GETTEXT_PACKAGE in line 39 to e.g. gnome-shell) to
generate a .pot file locally or even deal with make and friends, but I
would advise against it. Some modules use the ITS feature of gettext
to extract, among many others, polkit’s .policy files, and the rules
for that are not yet in any released version of polkit. Using
damned-lies avoids this problem and ensures that you have every string
in your translation.

If you’re interested in how damned-lies works in this regard, take a
look at <https://git.gnome.org/browse/damned-lies/log/?qt=grep&q=gettext>,
specifically commits from 2015 onwards.

Best regards,

-- 
Piotr Drąg
https://piotrdrag.fedorapeople.org
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies vs git statistic

[Ask Hjorth Larsen]

Hi

2017-03-21 14:12 GMT+01:00 Piotr Drąg :
> 2017-03-21 9:38 GMT+01:00 Danylo Korostil :
>> Hello,
>>
>> I'm translating Gnome and check the completeness against DL, but statistic
>> is mismatched:
>>
>> See: http://i.imgur.com/nZO4m2D.png
>>
>> Is it a DL bug or intltool-update deprecation?
>>
>
> Hi Danylo,
>
> gnome-shell is indeed one of the modules that don’t use intltool
> anymore. You should download the .po file from damned-lies and don’t
> run intltool-update on it, otherwise some parts may end up
> untranslated. One unscientific method to check if a module is
> gettext-exclusive is looking at the file paths in the .po file.
> Intltool uses relative paths, so file names start with “../”, while
> gettext uses absolute paths.
>
> Hope this helps,
>

It seems like a big step backwards that we can no longer use a single
procedure to merge/verify translations offline.  How could it come to
this?  (This is both a rhetorical question and not)

Would it not be possible to include the merge functionality with the
individual projects?  E.g. a single script present in all projects' po
folders, update-po , and it either just calls intltool or
does something else.  The damned lies backend would also be simpler,
perhaps, if each project has uniform code to update its own
translations.

Best regards
Ask
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies vs git statistic

[Danylo Korostil]

On 21.03.17 15:12, Piotr Drąg wrote:

Hi Danylo,

gnome-shell is indeed one of the modules that don’t use intltool
anymore. You should download the .po file from damned-lies and don’t
run intltool-update on it, otherwise some parts may end up
untranslated. One unscientific method to check if a module is
gettext-exclusive is looking at the file paths in the .po file.
Intltool uses relative paths, so file names start with “../”, while
gettext uses absolute paths.

Hope this helps,


Hey Piotr,

Thanks for your explanation!

I'm wondering what DL uses to retrieve these strings? Is it possible to 
get them without DL?


___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies vs git statistic

[Piotr Drąg]

2017-03-21 9:38 GMT+01:00 Danylo Korostil :
> Hello,
>
> I'm translating Gnome and check the completeness against DL, but statistic
> is mismatched:
>
> See: http://i.imgur.com/nZO4m2D.png
>
> Is it a DL bug or intltool-update deprecation?
>

Hi Danylo,

gnome-shell is indeed one of the modules that don’t use intltool
anymore. You should download the .po file from damned-lies and don’t
run intltool-update on it, otherwise some parts may end up
untranslated. One unscientific method to check if a module is
gettext-exclusive is looking at the file paths in the .po file.
Intltool uses relative paths, so file names start with “../”, while
gettext uses absolute paths.

Hope this helps,

-- 
Piotr Drąg
https://piotrdrag.fedorapeople.org
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies vs git statistic

[Danylo Korostil]

On 21.03.17 12:40, Andre Klapper wrote:

On Tue, 2017-03-21 at 12:26 +0200, Danylo Korostil wrote:

On 21.03.17 11:58, Andre Klapper wrote:

On Tue, 2017-03-21 at 10:38 +0200, Danylo Korostil wrote:

I'm translating Gnome and check the completeness against DL, but
statistic is mismatched:

See: http://i.imgur.com/nZO4m2D.png

Is it a DL bug or intltool-update deprecation?

Hard to say without any version information. :)

What do you mean? Version of what?

Your local version of intltool-update.

andre


intltool-update --version
intltool-update (intltool) 0.51.0

If it's a case.

___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies vs git statistic

[Andre Klapper]

On Tue, 2017-03-21 at 12:26 +0200, Danylo Korostil wrote:
> On 21.03.17 11:58, Andre Klapper wrote:
> > On Tue, 2017-03-21 at 10:38 +0200, Danylo Korostil wrote:
> > > I'm translating Gnome and check the completeness against DL, but
> > > statistic is mismatched:
> > > 
> > > See: http://i.imgur.com/nZO4m2D.png
> > > 
> > > Is it a DL bug or intltool-update deprecation?
> > 
> > Hard to say without any version information. :)
> 
> What do you mean? Version of what?

Your local version of intltool-update.

andre
-- 
Andre Klapper  |  ak...@gmx.net
http://blogs.gnome.org/aklapper/
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies vs git statistic

[Danylo Korostil]

On 21.03.17 11:58, Andre Klapper wrote:

On Tue, 2017-03-21 at 10:38 +0200, Danylo Korostil wrote:

I'm translating Gnome and check the completeness against DL, but
statistic is mismatched:

See: http://i.imgur.com/nZO4m2D.png

Is it a DL bug or intltool-update deprecation?

Hard to say without any version information. :)

andre


What do you mean? Version of what?

___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies vs git statistic

[Andre Klapper]

On Tue, 2017-03-21 at 10:38 +0200, Danylo Korostil wrote:
> I'm translating Gnome and check the completeness against DL, but 
> statistic is mismatched:
> 
> See: http://i.imgur.com/nZO4m2D.png
> 
> Is it a DL bug or intltool-update deprecation?

Hard to say without any version information. :)

andre
-- 
Andre Klapper  |  ak...@gmx.net
http://blogs.gnome.org/aklapper/
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Damned Lies vs git statistic

[Danylo Korostil]

Hello,

I'm translating Gnome and check the completeness against DL, but 
statistic is mismatched:


See: http://i.imgur.com/nZO4m2D.png

Is it a DL bug or intltool-update deprecation?


___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: damned lies stucked

[Rafael Fontenelle]

Fábio,

Please try again, as it could be fixed already. See
https://bugzilla.gnome.org/show_bug.cgi?id=774672

Best Regards,
Rafael Fontenelle

Em 18/11/2016 11:15, "Fabio Tomat"  escreveu:

> to whom it may concern,
> I'm trying to upload some translations of evolution to the repo, but
> when i send the request damned lies gets stuck there, what's wrong?
> Regards
> Fabio
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

damned lies stucked

[Fabio Tomat]

to whom it may concern,
I'm trying to upload some translations of evolution to the repo, but
when i send the request damned lies gets stuck there, what's wrong?
Regards
Fabio
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Error submitting gnome322 subtitles via Damned Lies

[Rafael Fontenelle]

Now it is working just fine. Thanks a lot!

2016-09-22 11:48 GMT-03:00 Andrea Veri :

> Now?
>
> 2016-09-22 16:20 GMT+02:00 Gabor Kelemen :
> > Hi
> >
> > Still not happening:
> >
> > „[Errno 1] remote: translations user cannot modify
> > 'video-subtitles/gnome322/po/hu.po' To
> > ssh://git.gnome.org/git/video-subtitles ! [remote rejected] master ->
> master
> > (pre-receive hook declined) error: failed to push some refs to
> > 'ssh://git.gnome.org/git/video-subtitles' ”
> >
> > Thanks for your help!
> > Gabor
> >
> > 2016-09-22 15:53 GMT+02:00 Andrea Veri :
> >>
> >> Typo on my side, please give it another try.
> >>
> >> cheers,
> >>
> >> 2016-09-22 15:04 GMT+02:00 Rafael Fontenelle :
> >> >
> >> > 2016-09-22 8:38 GMT-03:00 Andrea Veri :
> >> >>
> >> >> Added the paths, please confirm it's working now.
> >> >>
> >> >
> >> > I tried again, but it still fails with same error message.
> >> >
> >> > Rafael Fontenelle
> >>
> >>
> >>
> >> --
> >> Cheers,
> >>
> >> Andrea
> >>
> >> Debian Developer,
> >> Fedora / EPEL packager,
> >> GNOME Infrastructure Team Coordinator,
> >> GNOME Foundation Board of Directors Secretary,
> >> GNOME Foundation Membership & Elections Committee Chairman
> >>
> >> Homepage: http://www.gnome.org/~av
> >> ___
> >> gnome-i18n mailing list
> >> gnome-i18n@gnome.org
> >> https://mail.gnome.org/mailman/listinfo/gnome-i18n
> >
> >
>
>
>
> --
> Cheers,
>
> Andrea
>
> Debian Developer,
> Fedora / EPEL packager,
> GNOME Infrastructure Team Coordinator,
> GNOME Foundation Board of Directors Secretary,
> GNOME Foundation Membership & Elections Committee Chairman
>
> Homepage: http://www.gnome.org/~av
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Error submitting gnome322 subtitles via Damned Lies

[Gabor Kelemen]

Hi

Still not happening:

„[Errno 1] remote: translations user cannot modify
'video-subtitles/gnome322/po/hu.po' To ssh://git.gnome.org/git/video-
subtitles ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'ssh://git.gnome.org/git/video-subtitles'
”

Thanks for your help!
Gabor

2016-09-22 15:53 GMT+02:00 Andrea Veri :

> Typo on my side, please give it another try.
>
> cheers,
>
> 2016-09-22 15:04 GMT+02:00 Rafael Fontenelle :
> >
> > 2016-09-22 8:38 GMT-03:00 Andrea Veri :
> >>
> >> Added the paths, please confirm it's working now.
> >>
> >
> > I tried again, but it still fails with same error message.
> >
> > Rafael Fontenelle
>
>
>
> --
> Cheers,
>
> Andrea
>
> Debian Developer,
> Fedora / EPEL packager,
> GNOME Infrastructure Team Coordinator,
> GNOME Foundation Board of Directors Secretary,
> GNOME Foundation Membership & Elections Committee Chairman
>
> Homepage: http://www.gnome.org/~av
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Error submitting gnome322 subtitles via Damned Lies

[Andrea Veri]

Typo on my side, please give it another try.

cheers,

2016-09-22 15:04 GMT+02:00 Rafael Fontenelle :
>
> 2016-09-22 8:38 GMT-03:00 Andrea Veri :
>>
>> Added the paths, please confirm it's working now.
>>
>
> I tried again, but it still fails with same error message.
>
> Rafael Fontenelle



-- 
Cheers,

Andrea

Debian Developer,
Fedora / EPEL packager,
GNOME Infrastructure Team Coordinator,
GNOME Foundation Board of Directors Secretary,
GNOME Foundation Membership & Elections Committee Chairman

Homepage: http://www.gnome.org/~av
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Fwd: Re: Error submitting gnome322 subtitles via Damned Lies

[Claude Paroz]

 Message transféré 
Sujet : Re: Error submitting gnome322 subtitles via Damned Lies
Date : Thu, 22 Sep 2016 09:53:12 +0200
De : Andrea Veri 
Pour : Claude Paroz 

Paths added, please confirm it is working as expected.

cheers,

2016-09-22 9:37 GMT+02:00 Claude Paroz :

Le 22. 09. 16 à 01:12, Rafael Fontenelle a écrit :


Hi there.

When running "Send to repository" action in D-L web interface for
the translation of GNOME 3.22 video's subtitle, I get the following
error message:

[Errno 1] remote: translations user cannot modify
'video-subtitles/gnome322/po/pt_BR.po' To
ssh://git.gnome.org/git/video-subtitles
<http://git.gnome.org/git/video-subtitles> ! [remote rejected] master ->
master (pre-receive hook declined) error: failed to push some refs to
'ssh://git.gnome.org/git/video-subtitles
<http://git.gnome.org/git/video-subtitles>

Is it planned to allow such action?



See
https://git.gnome.org/browse/sysadmin-bin/tree/git/pre-receive-check-translations#n46

Some GNOME Git hero should be able to update the "hooks.po-directories"
variable on the server for this repo. Probably a sysadmin task again?


___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Error submitting gnome322 subtitles via Damned Lies

[Rafael Fontenelle]

2016-09-22 8:38 GMT-03:00 Andrea Veri :

> Added the paths, please confirm it's working now.
>
>
I tried again, but it still fails with same error message.

Rafael Fontenelle
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Error submitting gnome322 subtitles via Damned Lies

[Andrea Veri]

Added the paths, please confirm it's working now.

2016-09-22 13:19 GMT+02:00 Daniel Mustieles García :
> +Sysadmins ;)
>
> 2016-09-22 9:37 GMT+02:00 Claude Paroz :
>>
>> Le 22. 09. 16 à 01:12, Rafael Fontenelle a écrit :
>>>
>>> Hi there.
>>>
>>> When running "Send to repository" action in D-L web interface for
>>> the translation of GNOME 3.22 video's subtitle, I get the following
>>> error message:
>>>
>>> [Errno 1] remote: translations user cannot modify
>>> 'video-subtitles/gnome322/po/pt_BR.po' To
>>> ssh://git.gnome.org/git/video-subtitles
>>>  ! [remote rejected] master ->
>>> master (pre-receive hook declined) error: failed to push some refs to
>>> 'ssh://git.gnome.org/git/video-subtitles
>>> 
>>>
>>> Is it planned to allow such action?
>>
>>
>> See
>> https://git.gnome.org/browse/sysadmin-bin/tree/git/pre-receive-check-translations#n46
>>
>> Some GNOME Git hero should be able to update the "hooks.po-directories"
>> variable on the server for this repo. Probably a sysadmin task again?
>>
>>
>> Claude
>> --
>> www.2xlibre.net
>> ___
>> gnome-i18n mailing list
>> gnome-i18n@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
>
>
> ___
> gnome-infrastructure mailing list
> gnome-infrastruct...@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-infrastructure



-- 
Cheers,

Andrea

Debian Developer,
Fedora / EPEL packager,
GNOME Infrastructure Team Coordinator,
GNOME Foundation Board of Directors Secretary,
GNOME Foundation Membership & Elections Committee Chairman

Homepage: http://www.gnome.org/~av
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Error submitting gnome322 subtitles via Damned Lies

[Daniel Mustieles García]

+Sysadmins ;)

2016-09-22 9:37 GMT+02:00 Claude Paroz :

> Le 22. 09. 16 à 01:12, Rafael Fontenelle a écrit :
>
>> Hi there.
>>
>> When running "Send to repository" action in D-L web interface for
>> the translation of GNOME 3.22 video's subtitle, I get the following
>> error message:
>>
>> [Errno 1] remote: translations user cannot modify
>> 'video-subtitles/gnome322/po/pt_BR.po' To
>> ssh://git.gnome.org/git/video-subtitles
>>  ! [remote rejected] master ->
>> master (pre-receive hook declined) error: failed to push some refs to
>> 'ssh://git.gnome.org/git/video-subtitles
>> 
>>
>> Is it planned to allow such action?
>>
>
> See https://git.gnome.org/browse/sysadmin-bin/tree/git/pre-recei
> ve-check-translations#n46
>
> Some GNOME Git hero should be able to update the "hooks.po-directories"
> variable on the server for this repo. Probably a sysadmin task again?
>
> Claude
> --
> www.2xlibre.net
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Error submitting gnome322 subtitles via Damned Lies

[Claude Paroz]

Le 22. 09. 16 à 01:12, Rafael Fontenelle a écrit :

Hi there.

When running "Send to repository" action in D-L web interface for
the translation of GNOME 3.22 video's subtitle, I get the following
error message:

[Errno 1] remote: translations user cannot modify
'video-subtitles/gnome322/po/pt_BR.po' To
ssh://git.gnome.org/git/video-subtitles
 ! [remote rejected] master ->
master (pre-receive hook declined) error: failed to push some refs to
'ssh://git.gnome.org/git/video-subtitles


Is it planned to allow such action?


See 
https://git.gnome.org/browse/sysadmin-bin/tree/git/pre-receive-check-translations#n46


Some GNOME Git hero should be able to update the "hooks.po-directories" 
variable on the server for this repo. Probably a sysadmin task again?


Claude
--
www.2xlibre.net
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

RE: Error submitting gnome322 subtitles via Damned Lies

[Saikeo Kavhanxay]

Hi all,

I have got the same error. Can’t submit to repository.

//snip//

An error occurred during applying your action: The commit failed. The error 
was: '[Errno 1] remote: translations user cannot modify 
'video-subtitles/gnome322/po/LINGUAS' To 
ssh://git.gnome.org/git/video-subtitles ! [remote rejected] master -> master 
(pre-receive hook declined) error: failed to push some refs to 
'ssh://git.gnome.org/git/video-subtitles' '

//snip//

Thank you.
Best regards,
Saikeo

From: gnome-i18n [mailto:gnome-i18n-boun...@gnome.org] On Behalf Of Rafael 
Fontenelle
Sent: Thursday, September 22, 2016 6:13 AM
To: GNOME i18n list 
Subject: Error submitting gnome322 subtitles via Damned Lies

Hi there.

When running "Send to repository" action in D-L web interface for the 
translation of GNOME 3.22 video's subtitle, I get the following error message:

[Errno 1] remote: translations user cannot modify 
'video-subtitles/gnome322/po/pt_BR.po' To 
ssh://git.gnome.org/git/video-subtitles<http://git.gnome.org/git/video-subtitles>
 ! [remote rejected] master -> master (pre-receive hook declined) error: failed 
to push some refs to 
'ssh://git.gnome.org/git/video-subtitles<http://git.gnome.org/git/video-subtitles>

Is it planned to allow such action?

Thanks.

Best regards,
Rafael Fontenelle
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Error submitting gnome322 subtitles via Damned Lies

[Rafael Fontenelle]

Hi there.

When running "Send to repository" action in D-L web interface for
the translation of GNOME 3.22 video's subtitle, I get the following error
message:

[Errno 1] remote: translations user cannot modify
'video-subtitles/gnome322/po/pt_BR.po' To ssh://
git.gnome.org/git/video-subtitles ! [remote rejected] master -> master
(pre-receive hook declined) error: failed to push some refs to 'ssh://
git.gnome.org/git/video-subtitles

Is it planned to allow such action?

Thanks.

Best regards,
Rafael Fontenelle
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies don't update

[dooteo]

Thanks a lot to both Claude and Andrea :)


Jatorrizko mezua: az., 2016-09-21 20:01 +0200, egilea: Claude Paroz
> Le 21. 09. 16 à 14:36, Claude Paroz a écrit :
> > 
> > Le 21. 09. 16 à 11:10, Claude Paroz a écrit :
> > > 
> > > Apparently, the l10n.gnome.org server is not receiving all commit
> > > mail
> > > (which trigger statistics update).
> > > 
> > > We'll have to contact sysadmins...
> > 
> > Our beloved sysadmin Andrea repaired the messaging issues.
> > I'll trigger a global update of statistics later, should hopefully
> > be
> > up-to-date again after that.
> 
> All master and gnome-3-22 branches have been updated.
> If other branches need an update, just ping me.
> 
> Claude
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies don't update

[Claude Paroz]

Le 21. 09. 16 à 14:36, Claude Paroz a écrit :

Le 21. 09. 16 à 11:10, Claude Paroz a écrit :

Apparently, the l10n.gnome.org server is not receiving all commit mail
(which trigger statistics update).

We'll have to contact sysadmins...


Our beloved sysadmin Andrea repaired the messaging issues.
I'll trigger a global update of statistics later, should hopefully be
up-to-date again after that.


All master and gnome-3-22 branches have been updated.
If other branches need an update, just ping me.

Claude
--
www.2xlibre.net
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies don't update

[Claude Paroz]

Le 21. 09. 16 à 11:10, Claude Paroz a écrit :

Le 21. 09. 16 à 10:45, dooteo a écrit :

Hi all,

Jatorrizko mezua: az., 2016-09-21 10:34 +0200, egilea: Claude Paroz

Le 21. 09. 16 à 09:58, Marek Černocký a écrit :


Hi,

Damned Lies don't update statistics and templates (or at least for
Czech
language).


Could you be a bit more specific, for example telling us a specific
package which has not been updated?



Same for Basque lang:

https://l10n.gnome.org/languages/eu/gnome-3-22/ui/

For example, gsettings-desktop-schemas module's UI should be appear as
%100 translalated.


I just updated that module manually.

But there is indeed an issue.

Apparently, the l10n.gnome.org server is not receiving all commit mail
(which trigger statistics update).

We'll have to contact sysadmins...


Our beloved sysadmin Andrea repaired the messaging issues.
I'll trigger a global update of statistics later, should hopefully be 
up-to-date again after that.


Claude
--
www.2xlibre.net
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies don't update

[Marek Černocký]

For Czech e.g. (all mentioend shoud be 100%):

gnome-builder  master pushed 2016-09-19 22:02:22

gnome-commander help   gcmd-1-4   pushed 2016-09-19 22:08:09

gimp script-fu master, gimp-2-8   pushed 2016-09-21 08:18:27



Dne 21.9.2016 10:34, Claude Paroz napsal:

Le 21. 09. 16 à 09:58, Marek Černocký a écrit :

Hi,

Damned Lies don't update statistics and templates (or at least for 
Czech

language).


Could you be a bit more specific, for example telling us a specific
package which has not been updated?

Claude

___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies don't update

[Claude Paroz]

Le 21. 09. 16 à 10:45, dooteo a écrit :

Hi all,

Jatorrizko mezua: az., 2016-09-21 10:34 +0200, egilea: Claude Paroz

Le 21. 09. 16 à 09:58, Marek Černocký a écrit :


Hi,

Damned Lies don't update statistics and templates (or at least for
Czech
language).


Could you be a bit more specific, for example telling us a specific
package which has not been updated?



Same for Basque lang:

https://l10n.gnome.org/languages/eu/gnome-3-22/ui/

For example, gsettings-desktop-schemas module's UI should be appear as
%100 translalated.


I just updated that module manually.

But there is indeed an issue.

Apparently, the l10n.gnome.org server is not receiving all commit mail 
(which trigger statistics update).


We'll have to contact sysadmins...

Claude
--
www.2xlibre.net
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Damned Lies don't update

[dooteo]

Hi all,

Jatorrizko mezua: az., 2016-09-21 10:34 +0200, egilea: Claude Paroz
> Le 21. 09. 16 à 09:58, Marek Černocký a écrit :
> > 
> > Hi,
> > 
> > Damned Lies don't update statistics and templates (or at least for
> > Czech
> > language).
> 
> Could you be a bit more specific, for example telling us a specific 
> package which has not been updated?


Same for Basque lang:

https://l10n.gnome.org/languages/eu/gnome-3-22/ui/

For example, gsettings-desktop-schemas module's UI should be appear as
%100 translalated.


Best regards, 

Dooteo
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n