Re: DL no updating properly

2018-06-29 Thread Daniel Mustieles García via gnome-i18n
Many thanks!

El vie., 29 jun. 2018 14:56, Andrea Veri  escribió:

> Should be fixed and queue flushed.
>
> cheers,
>
> 2018-06-29 13:29 GMT+02:00 Claude Paroz :
> > Looks like the l10n server has not received any new commit mail since the
> > mass server reboot of this morning.
> > Andrea?
> >
> >
> > Le 29. 06. 18 à 12:34, Daniel Mustieles García via gnome-i18n a écrit :
> >>
> >> Sure
> >>
> >> https://l10n.gnome.org/vertimus/gnome-games/master/po/es/
> >>
> >>
> https://gitlab.gnome.org/GNOME/gnome-games/commit/ab89e81f7b1a4b94fc55db4b5ffc8d1101cd336e
> >>
> >> https://l10n.gnome.org/vertimus/pitivi/master/po/es/
> >>
> >>
> https://gitlab.gnome.org/GNOME/pitivi/commit/173b72450c937756ae7348f1f76cf39537b31462
> >>
> >>
> >> Thanks!
> >>
> >>
> >> 2018-06-29 12:04 GMT+02:00 Andre Klapper  >> <mailto:ak...@gmx.net>>:
> >>
> >> On Fri, 2018-06-29 at 12:01 +0200, Daniel Mustieles García wrote:
> >> > I've just pushed some translations into git, but DL still shows
> >> > incomplete status for those modules. Could you please review
> what's
> >> > happening?
> >>
> >> Can you please provide links so it is easier for others to check?
> >>
> >> andre
> >> -- Andre Klapper  | ak...@gmx.net <mailto:ak...@gmx.net>
> >> https://blogs.gnome.org/aklapper/ <
> https://blogs.gnome.org/aklapper/>
>
>
>
> --
> Cheers,
>
> Andrea
>
> Red Hatter,
> Fedora / EPEL packager,
> GNOME Infrastructure Team Coordinator,
> Former 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: [dconf-editor] String freeze break request

2018-08-17 Thread Daniel Mustieles García via gnome-i18n
2/2 from i18n.

Regards

El jue., 16 ago. 2018 10:28, Claude Paroz  escribió:

> Le 16. 08. 18 à 10:05, Arnaud Bonatti via gnome-i18n a écrit :
> > Hello everybody!
> >
> > There’s a string freeze running, but I’ve spotted a mistake of my own
> > in the dconf-editor module I maintain. There’s a new information about
> > “forced range,” as the range of a numeral key can be forced or not,
> > and I’ve used an already existing translation for the “forced or not
> > forced” (“True” / “False”) info. But, this existing translation was
> > from a completely different context, and the result looks stupid in
> > some translations (Chinese where I’ve spotted the bug, but that is
> > probably not specific).
> >
> > I’d like to correct that by pushing to new strings, “Yes” and “No,”
> > that would be even better in English and that would solve the
> > contextual translations problems. Is that doable?
>
> Fine with me at this stage. i18n approval 1 of 2.
>
> 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: Git access for translators

2018-09-04 Thread Daniel Mustieles García via gnome-i18n
Ok so just to clear things and not to start a flame-war, I just want to use
my script to commit a bunch of translations, only that. If i have to commit
20 PO files with just one string modified throught DL I will simply ignore
them because all the click-work needed to do it it's not worth for me.

I only aim to work in translations and make my work as efficient as
possible. Dont mind I have Git access or web access, but if I have to spend
more time doing the commits manually than translating maybe we are doing
something wrong. I agree we have always tried to reduce git access, but I
think this case is more than justified to have it. And if you try the
script to commit translations you will problably want to have git access to
use it and not waste your time.

Can you provide this features in DL today? API seems not be able to do
that, so sorry for disagreeing again with you but currently DL is not
usable for us to cover our needs.

Regards

2018-09-04 20:42 GMT+02:00 Alexandre Franke :

> On Tue, Sep 4, 2018 at 8:10 PM Daniel Mustieles García <
> daniel.mustie...@gmail.com> wrote:
>
>> El mar., 4 sept. 2018 17:50, Alexandre Franke 
>> escribió:
>>
>>> On Tue, Sep 4, 2018 at 9:30 AM Daniel Mustieles García via gnome-i18n <
>>> gnome-i18n@gnome.org> wrote:
>>> Damned lies has an API and your script could use it. If the API is not
>>> enough, we can extend it.
>>>
>>
>> Where is it documented?
>>
>
> https://wiki.gnome.org/DamnedLies#XML_interfaces
>
> It doesn’t have any workflow actions exposed yet (so no commit), but that
> can probably be added.
>
>
>> Is it compatible with bash scripts?
>>
>
> It is a Web API. From bash you can use e.g. curl to make the calls.
>
>
>> I've been using this script for several years without any problem, also
>> mi Git access, and never received any disclaim about it, but thanks if I
>> fixed a wrong string in docs... if game rules have changed due to gitlab
>> migration maybe someone should explain them clearly...
>>
>
> Don’t act as if we never said anything about trying to reduce direct
> repository access. We have always been trying to avoid giving access unless
> really necessary, and done everything we could to reduce cases where it was
> necessary.
>
> Rules have not changed, we just now have betters tools to enforce them.
>
>
>> and then I could explain why this script is very useful for translators
>> :-)
>>
>
> I’m not claiming it is useless, but it is not the right way to do it.
>
> --
> Alexandre Franke
> GNOME Hacker
>
> ___
> 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: Wrong stats in Damned Lies

2018-09-04 Thread 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: Git access for translators

2018-09-04 Thread Daniel Mustieles García via gnome-i18n
El mar., 4 sept. 2018 17:50, Alexandre Franke  escribió:

> On Tue, Sep 4, 2018 at 9:30 AM Daniel Mustieles García via gnome-i18n <
> gnome-i18n@gnome.org> wrote:
>
>> Yes, translators are encouraged to use Damned Lies instead of accesing
>> Git directly, but some translators (me, for example) might use an automated
>> script (1) to push a bunch of translations instead of doing it one by one
>> in Damned Lies, which implies so much click-work to upload and commit a PO
>> file into a single module.
>>
>
> Damned lies has an API and your script could use it. If the API is not
> enough, we can extend it.
>

Where is it documented? Is it compatible with bash scripts? I've been using
this script for several years without any problem, also mi Git access, and
never received any disclaim about it, but thanks if I fixed a wrong string
in docs... if game rules have changed due to gitlab migration maybe someone
should explain them clearly... and then I could explain why this script is
very useful for translators :-)

>
> In my personal case I've also fixed wrong strings in documentation or
>> commited patches into several modules, so I needed Git access.
>>
>
> No, you don’t. For those you can do a Merge request just like anyone else
> would.
>
> --
> Alexandre Franke
> GNOME Hacker
> ___
> 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: Git access for translators

2018-09-06 Thread Daniel Mustieles García via gnome-i18n
Note that not only LINGUAS file is a pain to add new languages... Makefile
file for documentation is even more difficult to parse as it's not always
in the same way, and it's needed to add a new language for documentation.

This case should be also considered

Cheers!

2018-09-06 10:00 GMT+02:00 Carlos Soriano :

> Of course, if there is any problem with a translation commit you can
>> always ask this list and we will help you ;-)
>
> Right, the goal is to not break on pre-merge though. But since this seems
> quite rare to happen... it's probably not a big deal.
> To add more weigh into this, recently I also had another problem in
> Nautilus, a translator committed using a quite old "merge commit" and the
> commit was actually wrong, that really made reverting that commit very
> complex. This kind of errors are prevented by GitLab MR + CI too.
>
>
>> I thought the git hooks we had that run msgfmt -c on translations
>> during push are still working in GitLab?
>>
> Yes they are, I think this happened before GitLab, like a year ago or so.
> What kind of breakages does msgfmt catch?
>
> Also, another thing I'm taking into account here is that there is a strong
> desire by some maintainers to prevent any commit to go directly to master
> by using GitLab's protected branches feature (not because of translators,
> but generally). This is currently on hold due to blocking translators using
> scripts.
>
> So I have been thinking on this and this is what I think we could do,
> kinda in order:
> - Push harder to make all projects have LINGUAS file for the main
> projects, and if missing and want to commit something, implement LINGUAS
> file first to overcome the issue (how hard is that?).
> - Only have one or two people from the i18n team have developer access to
> overcome Dammed Lies missing features such as uploading images from DL when
> needed.
> - Implementing mass commit in DL, so translators used to commit by script
> can use it.
> - Use GitLab API from Dammed Lies to create MRs and set the "merge
> automatically when CI pipeline passes". From my experience, this is a
> matter of 20 lines of Python code and I could help here.
> - Maintainers will start protecting the master branch, translators will
> use only DL. Trranslators with developer access will use MRs for e.g.
> uploading pictures or other rarely used needs.
>
> Now, this depends on how doable you think modifying DL to implement those
> is. If that's not doable, we can give up entirely and create a GitLab group
> called "translation team" and maintainers could give developer permissions
> to those to their projects.
>
> What do you think?
>
> Cheers
>
> On Tue, 4 Sep 2018 at 18:13, Piotr Drąg  wrote:
>
>> 2018-09-04 9:45 GMT+02:00 Carlos Soriano :
>> > Yeah... on the other hand I think most of FOSS projects do it this way
>> > nowadays, at least in things like GitHub, etc. Another thing to
>> consider is
>> > that translationa can break the code, maybe a good option is that
>> > translations need to pass CI before being committed? In that case MR
>> could
>> > be the best way to do that.
>> > Most probably this is a longer discussion to have though...
>> >
>>
>> I thought the git hooks we had that run msgfmt -c on translations
>> during push are still working in GitLab?
>>
>> 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: 3.30 release notes ready for translation

2018-08-31 Thread Daniel Mustieles García via gnome-i18n
Hi Alexandre,

I agree with you but marking those strings as translated doesn't reflect
the an accurate status but the frustration is not the main reason to do
that. Note that leaving those strings untranslated don't allow us to know
if the module has been updated with new strings needing attention or not,
so if I leave a module at 99% with some image strings not translated I will
revisit that module to check if that 99% is due to new translatable strings
or due to the untranslated images.

So I'm sorry for disagreeing but in muy case I will keep translating those
strings to avoid wasting time re-checking modules again and again until we
can reach a better solution for that.

Regards

2018-08-31 9:16 GMT+02:00 Alexandre Franke :

> Hi fellow translators,
>
> On Tue, Aug 28, 2018 at 4:20 PM Link Dupont  wrote:
>
>> They are now done and ready for translation! The notes can be found in
>> the gnome-3-30 branch of the release-notes repository. I will be adding
>> images this week.
>>
>
> While looking into details of the 3.28 translations, I found out that many
> teams mark screenshots as “translated but uses the original”. Please don’t
> do that. I understand that seeing something not at 100% is frustrating but
> this is not a good reason to do it. If you don’t have the time or if it is
> too difficult to reproduce, then just leave the screenshot untranslated.
> The result will be the same for readers (original screenshot will be shown)
> but at least we get an accurate representation of the state.
>
> This of course doesn’t apply to logos and other such images that indeed
> can be used as is in the localized version.
>
> Cheers,
>
> --
> Alexandre Franke
> GNOME Hacker
>
> ___
> 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


DL no updating properly

2018-06-29 Thread Daniel Mustieles García via gnome-i18n
Hi all!

I've just pushed some translations into git, but DL still shows incomplete
status for those modules. Could you please review what's happening?

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


Re: DL no updating properly

2018-06-29 Thread Daniel Mustieles García via gnome-i18n
Sure

https://l10n.gnome.org/vertimus/gnome-games/master/po/es/
https://gitlab.gnome.org/GNOME/gnome-games/commit/ab89e81f7b1a4b94fc55db4b5ffc8d1101cd336e

https://l10n.gnome.org/vertimus/pitivi/master/po/es/
https://gitlab.gnome.org/GNOME/pitivi/commit/173b72450c937756ae7348f1f76cf39537b31462


Thanks!


2018-06-29 12:04 GMT+02:00 Andre Klapper :

> On Fri, 2018-06-29 at 12:01 +0200, Daniel Mustieles García wrote:
> > I've just pushed some translations into git, but DL still shows
> > incomplete status for those modules. Could you please review what's
> > happening?
>
> Can you please provide links so it is easier for others to check?
>
> 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
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: D-L does not commit translations for Basque language

2018-11-03 Thread Daniel Mustieles García via gnome-i18n
If you have commit access you can use my scritp (with appropiate
modifcations to adapt it to your language) to autimatically commit a bunch
of PO files without having to do all that click-work in DL.

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

Hope it help you!

El vie., 2 nov. 2018 19:57, dooteo  escribió:

> Hi Rafael,
>
> Mm… I see. First I have to reserve it to translate myself, then upload
> translation, after set as “ready to submit” and finally “Send to repo”. It
> is too many steps to make a simple upload and commit step.
>
> I think there should be a faster way for commiters who are translating
> too. Just another option: “upload and commit translation”
>
> Could be it possible?
>
> Thanks and best regards,
>
> Dooteo
>
>
>
>
> On Nov 2, 2018, at 12:49 PM, Rafael Fontenelle  wrote:
>
> Hi dooteo,
>
> The action "Inform for submission" is just an information in D-L
> interface, as well as archiving the current translation.
>
> In order to upload the translation to the source code you have to use
> "Send to repository" after it is ready for submission.
>
> Best regards,
> Rafael Fontenelle
>
> Em sex, 2 de nov de 2018 08:40, dooteo 
>> Hi all,
>>
>> I’m the coordinator for Basque language, and I’m trying to commit
>> translated PO files (epiphany, gym, and others) to GNOME 3.30. Even I set
>> them as “Inform for submission”, Damned Lies does not commit them to Git
>> system.
>>
>> How can I commit them?
>>
>> Thanks and best regards,
>>
>> Iñaki Larrañaga
>> ___
>> 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: D-L does not commit translations for Basque language

2018-11-05 Thread Daniel Mustieles García via gnome-i18n
Oh, that's a problem, but now we are ready to relese the new Gtranslator we
can think about integrating it with DL, so this kind of problems should go
away.


El dom., 4 nov. 2018 a las 18:12, dooteo () escribió:

> Hi Daniel,
>
> Thanks for sharing your script. I’ve got my own scripts too to upload to
> Git. Unfortunately, I lost access grant once GNOME was migrated to GitLab.
> I asked for access permission, but sysadmin replied if safer to avoid
> translators to access whole source code.
>
> That’s why I’ve gotta upload by D-L.
>
> Thanks and best regards,
>
> Dooteo
>
>
> On Nov 3, 2018, at 8:30 PM, Daniel Mustieles García <
> daniel.mustie...@gmail.com> wrote:
>
> If you have commit access you can use my scritp (with appropiate
> modifcations to adapt it to your language) to autimatically commit a bunch
> of PO files without having to do all that click-work in DL.
>
> https://github.com/dmustieles/gnome_scripts/blob/master/gttk.sh
>
> Hope it help you!
>
> El vie., 2 nov. 2018 19:57, dooteo  escribió:
>
>> Hi Rafael,
>>
>> Mm… I see. First I have to reserve it to translate myself, then
>> upload translation, after set as “ready to submit” and finally “Send to
>> repo”. It is too many steps to make a simple upload and commit step.
>>
>> I think there should be a faster way for commiters who are translating
>> too. Just another option: “upload and commit translation”
>>
>> Could be it possible?
>>
>> Thanks and best regards,
>>
>> Dooteo
>>
>>
>>
>>
>> On Nov 2, 2018, at 12:49 PM, Rafael Fontenelle 
>> wrote:
>>
>> Hi dooteo,
>>
>> The action "Inform for submission" is just an information in D-L
>> interface, as well as archiving the current translation.
>>
>> In order to upload the translation to the source code you have to use
>> "Send to repository" after it is ready for submission.
>>
>> Best regards,
>> Rafael Fontenelle
>>
>> Em sex, 2 de nov de 2018 08:40, dooteo >
>>> Hi all,
>>>
>>> I’m the coordinator for Basque language, and I’m trying to commit
>>> translated PO files (epiphany, gym, and others) to GNOME 3.30. Even I set
>>> them as “Inform for submission”, Damned Lies does not commit them to Git
>>> system.
>>>
>>> How can I commit them?
>>>
>>> Thanks and best regards,
>>>
>>> Iñaki Larrañaga
>>> ___
>>> 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: l10n.gnome.org login with GNOME account

2018-11-05 Thread Daniel Mustieles García via gnome-i18n
It also works OK for me Claude.

Just an OT question... I've noticed fuzzy strings are now represented by a
blue bar instead of the orange one. When (and why) was this changed? I'd
vote for leaving it in orange as many translation programs use that color
to identify fuzzy strings.

Regards

El dom., 4 nov. 2018 a las 20:51, Claude Paroz ()
escribió:

> Le 04.11.18 à 04:55, Rafael Fontenelle a écrit :
> > Hello, Claude
> >
> > Em sáb, 3 de nov de 2018 às 17:41, Claude Paroz 
> escreveu:
> >>
> >> Hi,
> >>
> >> I've committed experimental support to DL for login with a GNOME
> account.
> >> https://gitlab.gnome.org/Infrastructure/damned-lies/issues/73
> >>
> >> Currently, the link is only available from the login page and not from
> >> the login menu.
> >> https://l10n.gnome.org/login/
> >>
> >> I'd appreciate some testing bevore adding the link to the pop-up login
> menu.
> >>
> >> Claude
> >> --
> >> www.2xlibre.net
> >
> > Thanks for implementing this feature! I tested here and looks good. I
> > used the web interface just like any other user, after joining and
> > setting role.
> >
> > Just to remind that if the intention is to use GNOME account instead
> > of DL login, the roles will need to be migrated too.
>
> I tried to configure the auth system to reuse the existing account if
> the email addresses match.
> It seemed to work with my account, but not with yours :-( I cannot
> explain that currently. (for Tom and Abderrahim who also tested the
> functionality, the email addresses are different, which explains the
> duplicate accounts)
>
> I can add an admin functionality to be able to rejoin the accounts if
> the system didn't achieve to match the existing account. I'm not yet
> sure if it's possible to develop a secure system to allow that "joining"
> feature for users themselves.
>
> 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: fuzzy color

2018-11-05 Thread Daniel Mustieles García via gnome-i18n
Maybe I dind't see it before or i didn't remember it... it's not a problem
for me, just thought it was a recent change.

Maybe we should take it into account in the new Gtranslator interface to
match colors with DL stats.

Thanks!

El lun., 5 nov. 2018 a las 11:55, Claude Paroz ()
escribió:

> Le 05.11.18 à 10:23, Daniel Mustieles García a écrit :
> > Just an OT question... I've noticed fuzzy strings are now represented by
> > a blue bar instead of the orange one. When (and why) was this changed?
> > I'd vote for leaving it in orange as many translation programs use that
> > color to identify fuzzy strings.
>
> Dear Daniel,
>
> Looks like it's the case for at least the six last years. It might be so
> because of contrast issues between red an orange.
> If you really want that change, I'd suggest you open a GitLab ticket and
> request comments for other translators. I probably won't change that
> color if you are the only one pushing for it.
>
> Claude
> --
> www.2xlibre.net
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Wrong stats in Damned Lies

2018-09-03 Thread 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: Git access for translators

2018-09-04 Thread Daniel Mustieles García via gnome-i18n
Hi Carlos,

Yes, translators are encouraged to use Damned Lies instead of accesing Git
directly, but some translators (me, for example) might use an automated
script (1) to push a bunch of translations instead of doing it one by one
in Damned Lies, which implies so much click-work to upload and commit a PO
file into a single module.

Of course this is a very isolated case, since not all translators use this
kind od tools nor need access to git. In my personal case I've also fixed
wrong strings in documentation or commited patches into several modules, so
I needed Git access.

About merge requests I don't know exactly how it works, but I don't
consider it be neccesary for translations. It could also generate a
high-traffic for maintainers and delay translators daily work.

Best regards

(1) - https://github.com/dmustieles/gnome_scripts/blob/master/gttk.sh

2018-09-04 9:18 GMT+02:00 Carlos Soriano :

> Also, it would be good to know if merge requests would be appropriate for
> this, instead of pure git access.
>
> On Tue, 4 Sep 2018 at 09:16, Carlos Soriano  wrote:
>
>> Hello all,
>>
>> Recently we had a bit of scramble with the release notes and some
>> translators not having git access to it.
>>
>> If I remember correctly translators are encouraged to not push directly
>> and use Dammed Lies instead, if I remember correctly doing otherwise is
>> unsupported.
>>
>> However, some translators mentioned they usually do it this way and they
>> usually get access.
>>
>> I would need some clarification on this so we know what project/group
>> permission set up is fit for translators. Can someone explain the current
>> situation?
>>
>> Thanks!
>> Carlos Soriano
>>
>
> ___
> 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: Git access for translators

2018-09-04 Thread Daniel Mustieles García via gnome-i18n
2018-09-04 9:45 GMT+02:00 Carlos Soriano :

> Thanks for the answers!
>
> > LINGUAS is often a variable inside a Mafefile or a configure.ac file
> Indeed. One option for that is to have one or two people from i18n have
> access to some projects to fix that.
>
> > Note that there are more and more modules also using LINGUAS files for
> docs, so this issue should be less important in the future
> That's good to hear!
>
> > but some translators (me, for example) might use an automated script (1)
> to push a bunch of translations instead of doing it one by one in Damned
> Lies, which implies so much click-work to upload and commit a PO file into
> a single module.
> Is it possible for the script to interact directly with Dammed Lies
> instead of directly git?
>

No AFAIK... another possible solution would be implement the mass-commit
feature in Damned Lies, but dont know hoy difficult would it be

>
> > About merge requests I don't know exactly how it works, but I don't
> consider it be necessary for translations. It could also generate a
> high-traffic for maintainers and delay translators daily work.
> Yeah... on the other hand I think most of FOSS projects do it this way
> nowadays, at least in things like GitHub, etc. Another thing to consider is
> that translationa can break the code, maybe a good option is that
> translations need to pass CI before being committed? In that case MR could
> be the best way to do that.
> Most probably this is a longer discussion to have though...
>

Damned Lies ald my script does such tests, but the case we have had with
GIMP headers has not been detected... maybe test tools don't consider it a
wrong line, when they should

>
> Another option is to create a translation team and giving that team
> developer access to some modules. Ideally this translation team would be
> only the people that really needs git access and others would use Dammed
> Lies.
>
> On Tue, 4 Sep 2018 at 09:30, Daniel Mustieles García <
> daniel.mustie...@gmail.com> wrote:
>
>> Hi Carlos,
>>
>> Yes, translators are encouraged to use Damned Lies instead of accesing
>> Git directly, but some translators (me, for example) might use an automated
>> script (1) to push a bunch of translations instead of doing it one by one
>> in Damned Lies, which implies so much click-work to upload and commit a PO
>> file into a single module.
>>
>> Of course this is a very isolated case, since not all translators use
>> this kind od tools nor need access to git. In my personal case I've also
>> fixed wrong strings in documentation or commited patches into several
>> modules, so I needed Git access.
>>
>> About merge requests I don't know exactly how it works, but I don't
>> consider it be neccesary for translations. It could also generate a
>> high-traffic for maintainers and delay translators daily work.
>>
>> Best regards
>>
>> (1) - https://github.com/dmustieles/gnome_scripts/blob/master/gttk.sh
>>
>> 2018-09-04 9:18 GMT+02:00 Carlos Soriano :
>>
>>> Also, it would be good to know if merge requests would be appropriate
>>> for this, instead of pure git access.
>>>
>>> On Tue, 4 Sep 2018 at 09:16, Carlos Soriano  wrote:
>>>
 Hello all,

 Recently we had a bit of scramble with the release notes and some
 translators not having git access to it.

 If I remember correctly translators are encouraged to not push directly
 and use Dammed Lies instead, if I remember correctly doing otherwise is
 unsupported.

 However, some translators mentioned they usually do it this way and
 they usually get access.

 I would need some clarification on this so we know what project/group
 permission set up is fit for translators. Can someone explain the current
 situation?

 Thanks!
 Carlos Soriano

>>>
>>> ___
>>> 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: Wrong stats in Damned Lies

2018-09-04 Thread 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: Git access for translators

2018-09-04 Thread Daniel Mustieles García via gnome-i18n
I use gtxml and msgfmt for checking PO files, but I disabled the gtxml
check temporary because it returned false positives in the
"translator-credits" line, but it detects wrong tags in documentation that
might cause a crash when compiling the module.

Of course, if there is any problem with a translation commit you can always
ask this list and we will help you ;-)

2018-09-04 10:02 GMT+02:00 Carlos Soriano :

> Damned Lies ald my script does such tests, but the case we have had with
>> GIMP headers has not been detected... maybe test tools don't consider it a
>> wrong line, when they should
>>
> Interesting... what kind of tests are passed? We had an issue with
> Nautilus one year ago or so with a translation commit.
>
> On Tue, 4 Sep 2018 at 09:57, Daniel Mustieles García <
> daniel.mustie...@gmail.com> wrote:
>
>>
>>
>> 2018-09-04 9:45 GMT+02:00 Carlos Soriano :
>>
>>> Thanks for the answers!
>>>
>>> > LINGUAS is often a variable inside a Mafefile or a configure.ac file
>>> Indeed. One option for that is to have one or two people from i18n have
>>> access to some projects to fix that.
>>>
>>> > Note that there are more and more modules also using LINGUAS files for
>>> docs, so this issue should be less important in the future
>>> That's good to hear!
>>>
>>> > but some translators (me, for example) might use an automated script
>>> (1) to push a bunch of translations instead of doing it one by one in
>>> Damned Lies, which implies so much click-work to upload and commit a PO
>>> file into a single module.
>>> Is it possible for the script to interact directly with Dammed Lies
>>> instead of directly git?
>>>
>>
>> No AFAIK... another possible solution would be implement the mass-commit
>> feature in Damned Lies, but dont know hoy difficult would it be
>>
>>>
>>> > About merge requests I don't know exactly how it works, but I don't
>>> consider it be necessary for translations. It could also generate a
>>> high-traffic for maintainers and delay translators daily work.
>>> Yeah... on the other hand I think most of FOSS projects do it this way
>>> nowadays, at least in things like GitHub, etc. Another thing to consider is
>>> that translationa can break the code, maybe a good option is that
>>> translations need to pass CI before being committed? In that case MR could
>>> be the best way to do that.
>>> Most probably this is a longer discussion to have though...
>>>
>>
>> Damned Lies ald my script does such tests, but the case we have had with
>> GIMP headers has not been detected... maybe test tools don't consider it a
>> wrong line, when they should
>>
>>>
>>> Another option is to create a translation team and giving that team
>>> developer access to some modules. Ideally this translation team would be
>>> only the people that really needs git access and others would use Dammed
>>> Lies.
>>>
>>> On Tue, 4 Sep 2018 at 09:30, Daniel Mustieles García <
>>> daniel.mustie...@gmail.com> wrote:
>>>
 Hi Carlos,

 Yes, translators are encouraged to use Damned Lies instead of accesing
 Git directly, but some translators (me, for example) might use an automated
 script (1) to push a bunch of translations instead of doing it one by one
 in Damned Lies, which implies so much click-work to upload and commit a PO
 file into a single module.

 Of course this is a very isolated case, since not all translators use
 this kind od tools nor need access to git. In my personal case I've also
 fixed wrong strings in documentation or commited patches into several
 modules, so I needed Git access.

 About merge requests I don't know exactly how it works, but I don't
 consider it be neccesary for translations. It could also generate a
 high-traffic for maintainers and delay translators daily work.

 Best regards

 (1) - https://github.com/dmustieles/gnome_scripts/blob/master/gttk.sh

 2018-09-04 9:18 GMT+02:00 Carlos Soriano :

> Also, it would be good to know if merge requests would be appropriate
> for this, instead of pure git access.
>
> On Tue, 4 Sep 2018 at 09:16, Carlos Soriano 
> wrote:
>
>> Hello all,
>>
>> Recently we had a bit of scramble with the release notes and some
>> translators not having git access to it.
>>
>> If I remember correctly translators are encouraged to not push
>> directly and use Dammed Lies instead, if I remember correctly doing
>> otherwise is unsupported.
>>
>> However, some translators mentioned they usually do it this way and
>> they usually get access.
>>
>> I would need some clarification on this so we know what project/group
>> permission set up is fit for translators. Can someone explain the current
>> situation?
>>
>> Thanks!
>> Carlos Soriano
>>
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> 

Re: [DL] String additions to 'gnome-software.gnome-3-30'

2018-09-14 Thread Daniel Mustieles García via gnome-i18n
Cool, thanks!

El vie., 14 sept. 2018 19:15, Piotr Drąg  escribió:

> 2018-09-14 19:10 GMT+02:00 Daniel Mustieles García <
> daniel.mustie...@gmail.com>:
> > Yes he has... I did it ;-)
> >
>
> Your message didn’t show up for whatever reason, but I see it in
> Kalev’s response, so everything’s fine. :)
>
> --
> Piotr Drąg
> https://piotrdrag.fedorapeople.org
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: [DL] String additions to 'gnome-software.gnome-3-30'

2018-09-14 Thread Daniel Mustieles García via gnome-i18n
Yes he has... I did it ;-)

El vie., 14 sept. 2018 18:52, Piotr Drąg via gnome-i18n <
gnome-i18n@gnome.org> escribió:

> 2018-09-14 18:49 GMT+02:00 GNOME Status Pages :
> > This is an automatic notification from status generation scripts on:
> > https://l10n.gnome.org.
> >
> > There have been following string additions to module
> 'gnome-software.gnome-3-30':
> >
> > + "%s and %s have been updated."
> > + "%s has been updated."
> > + "%u Application Updated — Restart Required"/"%u Applications
> Updated — Restart Required"
> > + "%u application requires a restart."/"%u applications require a
> restart."
> > + "Includes %s, %s and %s."
> > + "Please restart the application."
> >
>
> Hi Kalev,
>
> It looks like you jumped the gun a bit — you don’t have the second
> approval from i18n yet. :/
>
> 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
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: Experimental docs build

2018-09-17 Thread Daniel Mustieles García via gnome-i18n
Thanks Claude!

Regarding the XML syntax errors we could use gtxml (from PyG3t) to check
it. It works great and is written in Python, so should not be difficult to
nintegrate it in DL's code.

https://github.com/pyg3t/pyg3t

2018-09-17 10:13 GMT+02:00 Claude Paroz :

> Hi all,
>
> I just committed an experimental functionality in Damned Lies to be able
> to build the translated documentation with uploaded po files.
> You'll find a new button you can use to generate a build from a po file,
> just below the link to download it.
> Hopefully useful for reviewing translations. We'll see if we can use it to
> also prevent XML syntax errors from being committed.
>
> Thanks Andrea for the sysadmin support.
>
> Blessings,
>
> 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: gnome-software string freeze break request for 3.30

2019-02-26 Thread Daniel Mustieles García via gnome-i18n
It's OK for me to apply it in 3.30, so 1/2 from i18n.

Thanks!

El mar., 26 feb. 2019 a las 9:43, Kalev Lember via gnome-i18n (<
gnome-i18n@gnome.org>) escribió:

>
> Hi,
>
> I'd like to backport a few new error messages to gnome-software 3.30.x
> and looking for feedback whether to do this upstream or just backport it
> downstream in Fedora.
>
> This would fix a long standing issue where gnome-software shows 'Unable
> to update "(null)"' as an error. The fix is to split a bunch of error
> messages into two, e.g.:
>
> "Unable to update %s" would be replaced with "Unable to update %s" +
> "Unable to install updates" so that we can show the latter if we don't
> have the data to fill in %s.
>
> If I counted it right then it's 9 error strings changed along those lines.
>
> Would it be OK to backport this to 3.30 or should I do it downstream
> instead?
>
> Thanks,
> Kalev
> ___
> 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: Mass commit of GNOME modules

2019-02-28 Thread Daniel Mustieles García via gnome-i18n
Sure :-)

Here it is: https://github.com/dmustieles/gnome_scripts/blob/master/gttk.sh

Just need to change some variables at the beginning and commit message and
it will do the magic

Hope it helps you!

El jue., 28 feb. 2019 a las 16:38, Rafael Fontenelle ()
escribió:

> Hello all,
>
> I'm working on fixing issues (e.g. inconsistent translations) in many
> .po files of my language in many modules available in D-L, but doing
> click-n-submit for more than a hundred of modules would take too much
> time.
>
> Does someone have a tool/script/hint doing mass Git commit to GNOME
> modules that could share?
>
> Thanks in advance.
>
> 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


Re: [evolution-data-server] UI/string freeze break approval request

2019-03-01 Thread Daniel Mustieles García via gnome-i18n
Anyway they both are very simple strings, and in most of cases they wont
require more translation than copy the original string in the translated
one, so you've got the first vote from i18n ;-)

Thanks for the clarification!

El vie., 1 mar. 2019 a las 11:39, Milan Crha () escribió:

> On Fri, 2019-03-01 at 11:32 +0100, Daniel Mustieles García wrote:
> > Is it just an copy-paste URL in a single string? If so, 1/2 from i18n
> >
> > ...
> > > URL: [ https://accounts.google.com/signin/   ]
> > ...
>
> Hi,
> the above are two widgets, a label containing "URL:", which is also
> marked for localization, and an entry showing actual URL being used in
> the WebKitWebView below it, aka the URL itself, in the entry, is
> changing during the process of the authentication and is not localized.
>
> I wanted to re-use an existing string for the label, but there was none
> suitable in the sources.
> Bye,
> Milan
>
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: [evolution-data-server] UI/string freeze break approval request

2019-03-01 Thread Daniel Mustieles García via gnome-i18n
Is it just an copy-paste URL in a single string? If so, 1/2 from i18n

Thanks!

El vie., 1 mar. 2019 a las 10:13, Milan Crha via gnome-i18n (<
gnome-i18n@gnome.org>) escribió:

> Hello,
> I know this is awfully late, but I also believe this has a very limited
> impact to all interested parties, including translators, documentation
> and users itself.
>
> I'd like to break the UI Freeze in evolution-data-server's
> authentication dialog when using OAuth2, by adding URL line into
> it [1]. It's only the
>
> URL: [ https://accounts.google.com/signin/   ]
>
> line in [1], which had been added. It's added, because Google requires
> it to be there, which kind of makes sense, even for native
> applications, though it makes the dialog uglier. The "URL:" text is
> marked for localization, but I guess it's no big deal. Neither I think
> this dialog is shown anywhere in the documentation (though I can be
> wrong).
>
> I do not think it's really necessary to have this done for 3.32.0, the
> same as I agree that the timing, even for such small change, is really
> bad, but I think it would be nice to have in the 3.32.0. I'd not ask
> for it not being of the Google's requirement for it.
>
> Thanks for consideration.
>
> Bye,
> Milan
>
> [1] https://people.gnome.org/~mcrha/google-login.png
>
> ___
> 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: String freeze break request for gnome-software

2019-03-01 Thread Daniel Mustieles García via gnome-i18n
2/2 from i18n

Cheers

El vie., 1 mar. 2019 a las 18:17, Piotr Drąg via gnome-i18n (<
gnome-i18n@gnome.org>) escribió:

> pt., 1 mar 2019 o 14:13 Kalev Lember via gnome-i18n
>  napisał(a):
> >
> > Hi,
> >
> > We accidentally left in two "..." placeholders for new flatpak
> permission strings. I'd like to ask for a string freeze break to fix those:
> >
> > https://gitlab.gnome.org/GNOME/gnome-software/merge_requests/182
> >
>
> Ouch. 1/2 from i18n.
>
> 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
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: Seahorse - String freeze break

2019-02-20 Thread Daniel Mustieles García via gnome-i18n
2/2 from i18n

Thanks!

El mié., 20 feb. 2019 22:31,  escribió:

>
> Oops! +1 / 2 release 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


Errors in documentation

2019-03-05 Thread Daniel Mustieles García via gnome-i18n
Hi all,

I've made a report with some typos or errors in XML tags in documentation.
I've attatched a file with the typos found, sorted by language. Here is the
list of the affected languages:

ca
cs
de
el
es
fi
fr
hu
it
ja
pt_BR
sv
zh_CN

Please consider to fix them before the new release, to avoid problems when
compiling the affected modules.

Thanks for your attention and happy translating :)


gtxml-doc-reports.tar.gz
Description: application/gzip
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: Strings in display panel marked for translation and added context in g-c-c

2019-02-26 Thread Daniel Mustieles García via gnome-i18n
2/2 from i18n

Thanks!

El mar., 26 feb. 2019 20:17, Piotr Drąg via gnome-i18n 
escribió:

> wt., 26 lut 2019 o 19:56 Benjamin Berg 
> napisał(a):
> >
> > Hi,
> >
> > during the port of the display panel to use UI files and the new
> > libhandy widgets, a few strings were not marked as translatable. Also,
> > these strings and the printer panel strings need more context.
> >
> > The requested changes are:
> >  * Mark display setting strings as translatable (regression)
> >  * Add context to the above strings (#393, not a regression)
> >  * Add context to printer options (#394, not a regression)
> >
> > See
> >   https://gitlab.gnome.org/GNOME/gnome-control-center/merge_requests/414
> >
> > Benjamin
> >
> > PS: The regression probably happened due to glade not allowing
> > translation of the libhandy widget, upstream fix for this is:
> > https://source.puri.sm/Librem5/libhandy/merge_requests/236
>
> 1/2 from i18n.
>
> 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
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: [DL] String additions to 'gnome-builder.master'

2019-03-15 Thread Daniel Mustieles García via gnome-i18n
Hi,

Due to this Goal
 we
are trying to revome markup in translatable strings, so adding new ones
with tags is not a good idea.

Could you please consider the ability of supressing the markup?

Thanks in advance

El jue., 14 mar. 2019 a las 19:19, GNOME Status Pages ()
escribió:

> This is an automatic notification from status generation scripts on:
> https://l10n.gnome.org.
>
> There have been following string additions to module
> 'gnome-builder.master':
>
> + "Missing"
>
> Note that this doesn't directly indicate a string freeze break, but it
> might be worth investigating.
> https://gitlab.gnome.org/GNOME/gnome-builder/commits/master
> ___
> 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: Wrong context in 2 strings

2019-02-07 Thread Daniel Mustieles García via gnome-i18n
It is because of changing message context will cause DL to mark that string
as fuzzy. This is why he is asking to apply the change directly into the PO
files. These PO should be modified by developers, but in this case it is
harmless because translated strings are not affected ;-)

Cheers!

El jue., 7 feb. 2019 a las 16:44, Snehalata Shirude via gnome-i18n (<
gnome-i18n@gnome.org>) escribió:

> Hi,
>
> If the meaning does not change, i think it can be directly changed using
> find and replace. So it should not be directly related to the translation
> process as such.
>
> Thanks
>
> Snehalata Shirude
> Translator, for Marathi,
> India
>
> On Thu 7 Feb, 2019, 8:42 PM Jehan Pagès via gnome-i18n, <
> gnome-i18n@gnome.org> wrote:
>
>> Hi!
>>
>> In GIMP, we had a small bug in 2 strings: "Grow lighter areas of the
>> image" and "Grow darker areas of the image".
>>
>> Basically in our code, we declared the strings with "drawable-action"
>> context (hence that was the msgctx registered in po files) but called the
>> translation with "filters-action" context so they were not translated.
>> I fixed the code to use "filters-action" everywhere (the other was
>> wrong), but the wrong context is now in various po/*.po files (43 files).
>>
>> Do you mind if I just do a massive search-and-replace for these 2
>> context/strings to fix them? I mean, I actually already did it locally
>> (took 20 secs), and I think that it is simpler than having everyone just
>> edit manually for what was basically just a code bug. The actual context is
>> the same (these strings are filter descriptions, same place in the GUI as
>> what they were, nothing changed GUI-wise). So that looks harmless to me.
>>
>> Yet I have been told we should not touch the po files ourselves, if
>> possible.
>>
>> So 2 questions:
>> 1/ Is it ok if I just push this change?
>>
>> 2/ In the future, what should be our process as developers when we just
>> see these kinds of code issues affecting the po files? Can we just push
>> (making our own decision that this is not a translation issue) or we must
>> ask case by case?
>>
>> Thanks for the awesome work, all!
>>
>> Jehan
>>
>> --
>> ZeMarmot open animation film
>> http://film.zemarmot.net
>> Liberapay: https://liberapay.com/ZeMarmot/
>> Patreon: https://patreon.com/zemarmot
>> Tipeee: https://www.tipeee.com/zemarmot
>> ___
>> 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: Wrong context in 2 strings

2019-02-07 Thread Daniel Mustieles García via gnome-i18n
If the original string doesn't change and indeed it doesn't implies a
change in the translated one (and avoids translators to review a fuzzy
string) it's ok for me to apply the change directly in PO files.

Maybe other coordinators will disagree, but you have the OK to do it in the
Spanish PO file ;-)

About the second question... don't know how often this issues are, but I
would ask here before commiting, just to ensure you have the OK from the
i18n community.

Thanks!

El jue., 7 feb. 2019 a las 16:12, Jehan Pagès via gnome-i18n (<
gnome-i18n@gnome.org>) escribió:

> Hi!
>
> In GIMP, we had a small bug in 2 strings: "Grow lighter areas of the
> image" and "Grow darker areas of the image".
>
> Basically in our code, we declared the strings with "drawable-action"
> context (hence that was the msgctx registered in po files) but called the
> translation with "filters-action" context so they were not translated.
> I fixed the code to use "filters-action" everywhere (the other was wrong),
> but the wrong context is now in various po/*.po files (43 files).
>
> Do you mind if I just do a massive search-and-replace for these 2
> context/strings to fix them? I mean, I actually already did it locally
> (took 20 secs), and I think that it is simpler than having everyone just
> edit manually for what was basically just a code bug. The actual context is
> the same (these strings are filter descriptions, same place in the GUI as
> what they were, nothing changed GUI-wise). So that looks harmless to me.
>
> Yet I have been told we should not touch the po files ourselves, if
> possible.
>
> So 2 questions:
> 1/ Is it ok if I just push this change?
>
> 2/ In the future, what should be our process as developers when we just
> see these kinds of code issues affecting the po files? Can we just push
> (making our own decision that this is not a translation issue) or we must
> ask case by case?
>
> Thanks for the awesome work, all!
>
> Jehan
>
> --
> ZeMarmot open animation film
> http://film.zemarmot.net
> Liberapay: https://liberapay.com/ZeMarmot/
> Patreon: https://patreon.com/zemarmot
> Tipeee: https://www.tipeee.com/zemarmot
> ___
> 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: GNOME Music freeze break request

2019-02-08 Thread Daniel Mustieles García via gnome-i18n
Early in the freeze, so 1/2 from i18n.

Thanks!

El vie., 8 feb. 2019 a las 11:40, Jean Felder ()
escribió:

> Hi,
>
> I would like to ask for a freeze break request to introduce a new empty
> view when Tracker is not available [1].
> This is a long standing issue for newcomers who want to contribute to
> Music using flatpak without tracker installed (for example, Tracker is not
> installed by default on Ubuntu).
> Without this view, these users will see an "music library not avaiable"
> message, which is quite misleading.
> Besides, Photos introduced a similar view [2] during this cycle. So, this
> would provide some consistency between two core applications.
>
> This feature has not been introduced before the freeze because of some
> lack of avaibility of both maintainers (Marinus Schraal and myself).
> Finally, it introduces two new strings.
>
>
> [1] https://gitlab.gnome.org/GNOME/gnome-music/merge_requests/335
> [2] https://gitlab.gnome.org/GNOME/gnome-photos/merge_requests/85
>
> Regards,
> Jean
> ___
> release-t...@gnome.org
> https://mail.gnome.org/mailman/listinfo/release-team
> Release-team lurker? Do NOT participate in discussions.
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: Korean translation of GIMP

2019-02-18 Thread Daniel Mustieles García via gnome-i18n
+Changwoo Ryu (Korean team coordinator)

Team coordinator should decide what to do in this case. I've not been able
to find commiter's email so I've not added it to the Cc of this email.

I don't remember any question about Korean translations for GIMP, but don't
trust blindly mi memory ;-)

El lun., 18 feb. 2019 a las 15:19, Jehan Pagès via gnome-i18n (<
gnome-i18n@gnome.org>) escribió:

> Hi Korean team (and everyone else)!
>
> Someone did what looks like a huge job of translating GIMP in Korean,
> which was indeed a bit falling behind these years, and proposed it as merge
> requests:
>
> For gimp-2-10: https://gitlab.gnome.org/GNOME/gimp/merge_requests/51
> For master: https://gitlab.gnome.org/GNOME/gimp/merge_requests/54
>
> We told this person on gitlab to not do merge requests, but instead get in
> touch with the GNOME Korean team, giving links, etc. We never had any
> answer (so I wonder if this person receives the notification or read the
> opened request thread at all; we even tried a message in Korean!).
>
> Still, has this person contacted anyone in the GNOME i18n community, and
> in particular the Korean team?
>
> If this goes on without contact, we are not sure what we should do in such
> case. On one hand, we want Korean localization (currently around 50% if I
> read the stats correctly), but we are not going to just merge these commits
> like this obviously.
> Do you have any advice to go forward?
> Because right now these 2 merge requests are just sitting there, and we
> have no idea what to do with them (we only leave them opened so that it
> stays on sight).
>
> Thanks all!
>
> Jehan
>
> --
> ZeMarmot open animation film
> http://film.zemarmot.net
> Liberapay: https://liberapay.com/ZeMarmot/
> Patreon: https://patreon.com/zemarmot
> Tipeee: https://www.tipeee.com/zemarmot
> ___
> 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: geary string freeze and upcoming release

2019-02-11 Thread Daniel Mustieles García via gnome-i18n
Sure, here is the second +1 from i18n ;-)

Thanks!


El mar., 12 feb. 2019 a las 8:22, Alexandre Franke ()
escribió:

> On Mon, Feb 11, 2019 at 11:45 PM Michael Gratton  wrote:
> > Sure thing. Per the original email in this thread, the plan is to
> > release 0.13 later this week. This is a feature release and will become
> > the new stable release, replacing 0.12 as such.
> >
> > Going forward, I plan to then quickly do a "UI refresh" release and
> > switch over to the GNOME release numbering, around the same time or
> > shortly after GNOME 3.32 comes out next month. This will have an
> > updated icon and app menu moved into the main window so as to match
> > GNOME 3.32 apps, and might be enhanced with libhandy so as to work
> > better on narrow, portrait displays, if that isn't too disruptive.
> >
> > I view this UI refresh release effectively as a point release (i.e.
> > 0.13.1), since I don't really plan on adding new features aside from
> > the above), but am bumping the version since its a noticeable change
> > from the perspective of a person using it, and it seems like a good
> > excuse as any to switch to GNOME's numbering. There will be a series
> > for point releases after that, too (i.e. 3.32.1, ...), for bug fix and
> > translation updates.
> >
> > After that I'd like to start following the GNOME release schedule
> > proper.
> >
> > Does that help?
>
> I think it does. Considering this, here’s my proposed solution:
> * we indeed consider Geary frozen and don’t make any breaking changes
> to strings in master
> * instead we stage them in a MR
> * changes that don’t break the freeze, like reusing an existing one,
> are fine for master
> * once 0.13 is released by the end of the week, we merge the staged
> fixes so they go in the next release
>
> This is similar to the situation where we have changes for GNOME
> modules right before the .0 release and we delay them to right after
> that release so they land in .1.
>
> Would that work for you, Michael?
>
> Can we have a +1 from a second i18n team member?
>
> --
> Alexandre Franke
> GNOME Hacker
> ___
> 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: New string additions

2019-06-13 Thread Daniel Mustieles García via gnome-i18n
Hi Claude,

Is due to this change that gnome-software[1] has about 600 unstranslated
new strings?

It's a very big change in just one day... there is no way to reduce it?

Thanks in advance

[1] https://l10n.gnome.org/vertimus/gnome-software/master/po/es/

El jue., 13 jun. 2019 a las 8:54, Claude Paroz ()
escribió:

> Le 12.06.19 à 22:32, GNOME Status Pages a écrit :
> > This is an automatic notification from status generation scripts on:
> > https://l10n.gnome.org.
> >
> > There have been following string additions to module
> 'seahorse.gnome-3-32':
> >
> > + "A new and contemporary icon"
> > + "Add OARS metadata, relevant to age restrictions."
> ...
>
> Hi team,
>
> We may receive a good bunch of those messages in the near future due to
> resolution of
> https://gitlab.gnome.org/Infrastructure/damned-lies/issues/149,
> which adds release note string extraction from appdata xml files.
>
> Piotr suggested on the ticket that we strip those strings from the
> reduced pot versions.
>
> 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: New string additions

2019-06-13 Thread Daniel Mustieles García via gnome-i18n
Yes, the Appdata file has release notes from very old versions... maybe
those strings could be removed/moved to another place.

@Richard: any idea about how to deal with this?

Thanks!

El jue., 13 jun. 2019 a las 14:06, scootergrisen via gnome-i18n (<
gnome-i18n@gnome.org>) escribió:

> Den 13-06-2019 kl. 11:39 skrev Daniel Mustieles García via gnome-i18n:
> > Hi Claude,
> >
> > Is due to this change that gnome-software[1] has about 600 unstranslated
> > new strings?
> >
> > It's a very big change in just one day... there is no way to reduce it?
> >
> > Thanks in advance
> >
> > [1] https://l10n.gnome.org/vertimus/gnome-software/master/po/es/
> >
>
> Seems like strings for a lot of releases going back years:
>
> https://gitlab.gnome.org/GNOME/gnome-software/blob/master/data/appdata/org.gnome.Software.appdata.xml.in
>
> Not sure if there is much point translating all those strings and users
> might not see them anyway.
>
> If i search for GNOME software in GNOME software it says version
> 3.30.6-2ubuntu4.19.04.1 but i see none of those strings. Maybe because
> the version number does not match any of the strings exactly.
>
> Seems like a wast of time translation strings for a 2014 release.
>
> When can a user ever see it?
>
> I normally prefer to have things fully translated but on SMPlayer
> website i can also translate a few new strings on each release but i
> find it a bit waste of time because in next release its already outdated.
>
> If we have to translated release changes strings like this for every
> software that would not be so much fun and the time could properly be
> spendt better on improving the software.
> ___
> 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: Easier translation interface is needed

2019-07-07 Thread Daniel Mustieles García via gnome-i18n
Hi Federico,

I could help you reviewing and completing that document.

Those options/workflows are not strictly hidden but yes,  maybe they are
not well documented or explained.

We use them so if I can help you just tell me ;-)

Cheers!

El dom., 7 jul. 2019 9:31, Federico Bruni  escribió:

>
>
> Il giorno gio 4 lug 2019 alle 8:39, Claude Paroz 
> ha scritto:
> > Le 03.07.19 à 15:02, Nikoloz Geldiashvili via gnome-i18n a écrit :
> >>  For communities to complete translations to other languages more
> >> quickly
> >>  and easily, it would be much more effective to have survey like web
> >>  based (in browser) translating app, rather than file download and
> >> upload
> >>  method. I mean interface, like Google's Crowdsource translation app
> >> has.
> >
> > Hi Nikoloz,
> >
> > This discussion comes regularly and in general the conclusions are
> > that
> > both ways have pros and cons. So for the moment we will keep the
> > method
> > by file, as it would be a huge work to convert to a Web-based platform
> > while keeping all the customizations we have programmed during the
> > years
> > for the GNOME translations.
> >
>
> Claude, there's no _user_ manual for Damned Lies, right?
> I think it would be very useful, as some features are kind of hidden
> and I "discovered" them only when experienced translators explained
> them to me. For example, if I remember correctly:
>
> - If you submit a PO file and the POT file has been updated since you
> downloaded the PO file, you'll see if your uploaded version is not
> complete (the statistics strings/fuzzy/untranslated close to the
> .merged.po file, see this¹) and you can download a file with the new
> strings merged in your last translation.
> - If you work on a PO file from a release branch of a project, you can
> submit the same file also to other branches (such as master), then get
> a new file with the merged differences and work on the remaining
> strings for that branch. So there's no need to copy if you want
> to manage translations of different branches. It's the same concept as
> above but in a different context.
>
> The wiki says that Damned Lies "offers a review workflow with different
> roles (translator, reviewer, committer and administrator)". To me this
> is limited only to comments. There's no real review tool, as in Gitlab:
> I cannot comment the diff line by line.
> Recently I made a detailed review in a comment and the translator was
> lost as he could not find some strings I was talking about. The same
> translator recently proposed to reviewers a good suggestion I've never
> thought before: instead of listing the changes in a comment, make the
> changes in the PO file and upload it, so the translator can see the
> differences in Damned Lies and use that file to decide what to accept
> or refuse. Much easier indeed.
>
> So not only hidden features, you see, but also best workflows to be
> discussed and shared.
>
>
> I'd like to contribute to a user manual or user wiki, especially if
> someone else more experienced than me can review and help.
>
> ¹ https://l10n.gnome.org/vertimus/fractal/master/po/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: Heads up: Geary mainline development branch renamed to `mainline`

2019-04-24 Thread Daniel Mustieles García via gnome-i18n
Hi Michael,

As I've already commented in https://gitlab.gnome.org/GNOME/geary/issues/403,
having a "mainline" branch instead of a "master" branch is confusing for
applications like Damned Lies, breaking for example cherry-picks from other
branches to "master" branch, as it doesn't exist.

Stable branches can be named with your own nomenclature (no need to name
them gnome-x.yy) but I would encourage you to keep the "master" branch. It
is the standard name for GNOME's development branches and helps developers
and contributors to identify where to look up the last version of the
source code.

If every GNOME's module begins naming it's "master" branch to whatever the
maintainer wants, this will be a chaos... I don't know where is the
advantage of this renaming (we don't belong to Linux kernel develpment, as
exposed in #324), but coherence across modules should be kept.

Regards.

El mié., 24 abr. 2019 a las 3:46, Michael Gratton () escribió:

> Hi all,
>
> Just a quick heads-up for people who have use git directly for
> traslating Geary: As part of
> https://gitlab.gnome.org/GNOME/geary/issues/324 The `master` branch has
> been renamed to `mainline`. Same great content (and command line
> completion prefix), snazzy new name. :)
>
> So it would be worth doing a `git fetch && git checkout mainline` ASAP,
> cherry pick any pending commits you have on the master branch, then
> deleting the old branch to avoid committing more changes to it in the
> future (`git branch --delete master && git remote prune origin`).
>
> This change happened a few weeks ago, my apologies for not letting
> everyone on the list know sooner.
>
> Cheers!
> //Mike
>
> --
> ⊨ Michael Gratton, Percept Wrangler.
> ⚙ 
>
>
> ___
> 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: Heads up: Geary mainline development branch renamed to `mainline`

2019-04-24 Thread Daniel Mustieles García via gnome-i18n
El mié., 24 abr. 2019 a las 10:33, Andre Klapper () escribió:

> On Wed, 2019-04-24 at 08:43 +0200, Daniel Mustieles García wrote:
> > I don't know where is the advantage of this renaming
>
> That is already clearly explained in
> https://gitlab.gnome.org/GNOME/geary/issues/324


Just because "master" implies an "slave" branch? Note that I'm not the only
who disagrees with the change, so maybe the reason is not really clear

>
>
> >  (we don't belong to Linux kernel develpment
>
> And nobody ever said so, so I don't know why it's brought up.
>

Yes, it's mentioned in the issue: "...several projects like Rust, Django
and the Linux kernel..."

>
> > , as exposed in #324), but coherence across modules should be kept.
>
> I agree that it would be good to consider renaming all master branches.
>

Great, but having modules with no standard name for master/trunk/whatever
branch might break applications like Damned Lies, so this rename should be
reconsidered, at least until we decide to rename the whole modulesed's
master branch to another one.

What would happen if every module maintainer decides to rename it's master
branch? It will be a mess... I just think we should keep names homogeously,
don't mind if it's called master, trunk... ;-)

>
> 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
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: Heads up: Geary mainline development branch renamed to `mainline`

2019-04-24 Thread Daniel Mustieles García via gnome-i18n
El mié., 24 abr. 2019 a las 11:25, Carmen Bianca Bakker (<
car...@carmenbianca.eu>) escribió:

> Je mer, 2019-04-24 je 10:32 +0200, Andre Klapper skribis:
> > > , as exposed in #324), but coherence across modules should be kept.
> >
> > I agree that it would be good to consider renaming all master branches.
>
> Then mightn't it be better to bring up the topic with GNOME and/or Git
> upstream?


This is exactly what I meant when said "consider".


> Because it would be a bit of a mess if every project could
> decide for themselves what to call their master/mainline branch. For
> infrastructure reasons, it seems to me that it would be best if the
> name of that branch were uniform.
>
> I would like that name to be something other than "master", which is a
> bit clunky, inaccurate, and prone to cause offence, but I'd rather have
> that than a broken infrastructure.
>

I don't think "master" causes any kind of offence, but this is just a
question of appreciation.

Of course, If we consider this topic is enough important to take into
account, we should open a new thread involving d-d-l and maybe other teams
(Releaste team, Infrastructure...). But is this thread we are just
discussing if Geary's maintainer should revert the change, at least until a
final decission has been taken.

I've exposed some arguments to revert it, the main one is that Damned Lies
is currently broken due to this name change. You can see it in the
screenshot.
In the other hand, opening the door to change the name of the master branch
in every module will result in a very big mess, broken scripts, etc.

Cheers


> With kindness,
> Carmen
>
> ___
> 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: Heads up: Geary mainline development branch renamed to `mainline`

2019-04-24 Thread Daniel Mustieles García via gnome-i18n
So hardcoding the name "mainline" to the list of branches that Damned Lies'
looks up resolves the problem for you... and tomorrow another maintainer
decides to rename it's master branch to whatever_non_offensive_name and DL
breaks again until a patch is submited... no, sorry but this is not a
solution for this.

GNOME's modules follow a standard nomenclature and it might be followed by
all GNOME's modules. If you disagree with the naming policy you should open
a thread, discuss it with the community and follow the final decission.
It'ns not right to open the door to change master branches name freely,
although Gitlab allows it (technical ability to change it doesn't give you
the right to do it).

Since this is a not only i18n-related issue I'm Ccing Release Team and
d-d-l to hear opinion from others, what I think you should have done before
appliying this change (opening an issue in Gitlab is not enough... not
every GNOME's member is subscribed to every proyect's notifications).

Really it is a big problem for you to have a branch called «master»? It's
annoying for me spending time on this instead of working on real
problems/tasks.

Regards

El mié., 24 abr. 2019 a las 13:17, Michael Gratton ()
escribió:

> Hi Daniel,
>
> On Wed, Apr 24, 2019 at 10:46, Daniel Mustieles García via gnome-i18n
>  wrote:
> > Great, but having modules with no standard name for
> > master/trunk/whatever branch might break applications like Damned
> > Lies, so this rename should be reconsidered, at least until we decide
> > to rename the whole modulesed's master branch to another one.
>
> The name of the mainline branch in git cannot be assumed to be "master"
> since git allows it to be changed, and as of Git 1.8 the server sends
> and the client looks for the name of the mainline branch when the repo
> is being fetched (e.g. via a clone). Changing the name of the mainline
> branch is easy to do, and in fact our Gitlab instance lets anyone with
> appropriate privs for a project do just that from the project settings
> UI.
>
> So, Damned-Lies' current behaviour is broken because it makes the
> assumption that the mainline branch is always named "master" (after
> trying a few other hard-coded names), and so it breaks in situations
> like this. However, I submitted a workaround that adds "mainline" to
> that list, and that MR[0] has been merged. I'm not sure if it has been
> deployed, but I think it may have been about a week ago.
>
> Of course, this should be fixed properly to just ask the repo what the
> right name is, and if there's interest in fixing it properly I'll
> happily look into it and submit another MR. I've also worked with
> Andrea to fix places in the sysadmin code (git hooks, GitLab
> integration, etc) making the same assumption[1], and that's been
> working fine for weeks.
>
> Anyway, it should be fixed for Geary now, so if you're still having
> problems with this as of this time last week, please let me know so I
> can look into a fix.
>
> > What would happen if every module maintainer decides to rename it's
> > master branch? It will be a mess... I just think we should keep names
> > homogeously, don't mind if it's called master, trunk... ;-)
> >>
>
> No, everything will work fine as long as people stop writing code that
> (wrongly) assumes git's mainline branch is necessarily called "master".
> :)
>
> //Mike
>
>
> [0] -
> <https://gitlab.gnome.org/Infrastructure/damned-lies/merge_requests/18>
> [1] -
> <https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/127>
>
> --
> ⊨ Michael Gratton, Percept Wrangler.
> ⚙ <http://mjog.vee.net/>
>
>
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


GTXML report: errors in documentation

2019-09-03 Thread Daniel Mustieles García via gnome-i18n
Hi all,

As usual, I've created a report (attatched) with the languages containing
typos or errors in tags in documentation files. Here is the list of the
affected languages:

ca
cs
da
es
fr
ja
pt_BR
ro
ru

Please fix them before the new release, to avoid errors when compiling the
affected modules. If you need help fixing it, just let me know and I'll
help you.

Regards


gtxml-doc-reports.tar.gz
Description: application/gzip
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: Password for 3.34 release notes

2019-09-03 Thread Daniel Mustieles García via gnome-i18n
Thanks! ;-)

El mar., 3 sept. 2019 a las 13:04, Alexandre Franke ()
escribió:

> On Tue, Sep 3, 2019 at 12:56 PM Daniel Mustieles García via gnome-i18n
>  wrote:
> > I'm translating 3.34 release notes and I'd like to check it in the web.
> >
> > Could you please provide me username and passwd for the web?
>
> gnome/wanda
>
> --
> Alexandre Franke
> GNOME Hacker
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Password for 3.34 release notes

2019-09-03 Thread Daniel Mustieles García via gnome-i18n
Hi,

I'm translating 3.34 release notes and I'd like to check it in the web.

Could you please provide me username and passwd for the web?

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


Re: 3.34 release notes ready for translation

2019-08-29 Thread Daniel Mustieles García via gnome-i18n
And now are available in Damned Lies

https://l10n.gnome.org/module/release-notes/

Cheers!

El jue., 29 ago. 2019 a las 14:02, Link Dupont ()
escribió:

> Hi everyone,
>
> The 3.34 release notes are ready for translation. The notes are in the
> gnome-3-34 branch of the release-notes repository[1]. Most images are
> up as well, so feel free to translate to your local language.
>
> Link
>
> 1: https://gitlab.gnome.org/Teams/Engagement/release-notes
>
>
> ___
> 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: [evolution] String freeze break approval plea

2019-08-26 Thread Daniel Mustieles García via gnome-i18n
Early in the freeze, so 1/2 from i18n.

Thanks!

El lun., 26 ago. 2019 a las 14:34, Milan Crha via release-team (<
release-t...@gnome.org>) escribió:

> Hello,
> a user reported a typo in a translatable string [1]. I can fix it, but
> it would break existing translations, even it is visible only in
> GSettings, dconf-editor and similar tools. The faulty string had been
> added before 3.33.1 release.
>
> Can I correct the string, please?
> Bye,
> Milan
>
> [1] https://gitlab.gnome.org/GNOME/evolution/issues/592
>
> ___
> release-t...@gnome.org
> https://mail.gnome.org/mailman/listinfo/release-team
> Release-team lurker? Do NOT participate in discussions.
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: 3.34 release notes ready for translation

2019-09-02 Thread Daniel Mustieles García via gnome-i18n
Not sure about what you mean when say "adding Croatian to PO file".

I've just added Croatian language (hr) to Makefile so you can now commit
your translation and it should appear in Dmaned Lies.

Thanks!

El sáb., 31 ago. 2019 a las 0:17, Milo Ivir () escribió:

> I've just translated Croatian.
> Could you please check, if "Croatian" may/should be added as a
> translatable string in the .pot file. I know it has something to do with
> the translation's percentage, but I don't know how you calculate it ...
>
> Milo
>
> 29.08.2019., u 14:14, Daniel Mustieles García via gnome-i18n <
> gnome-i18n@gnome.org> je napisao:
>
> And now are available in Damned Lies
>
> https://l10n.gnome.org/module/release-notes/
>
> Cheers!
>
> El jue., 29 ago. 2019 a las 14:02, Link Dupont ()
> escribió:
>
>> Hi everyone,
>>
>> The 3.34 release notes are ready for translation. The notes are in the
>> gnome-3-34 branch of the release-notes repository[1]. Most images are
>> up as well, so feel free to translate to your local language.
>>
>> Link
>>
>> 1: https://gitlab.gnome.org/Teams/Engagement/release-notes
>>
>>
>> ___
>> 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: New po diff view

2019-09-02 Thread Daniel Mustieles García via gnome-i18n
Great feature Claude!

Many thanks for it, it will be really helpful for documentation PO files.

Thanks!

El sáb., 31 ago. 2019 a las 11:28, Claude Paroz ()
escribió:

> Le 31.08.19 à 09:18, Alexandre Franke a écrit :
> > Hey,
> >
> > On Fri, Aug 30, 2019 at 9:59 PM Claude Paroz  wrote:
> >> You may have noticed a new icon right to the PO file download button.
> >> That new link (only available if there are fuzzy string) shows an HTML
> >> representation of the po file including inlined diffs for strings having
> >> the previous string (#| msgid...).
> >
> > I had a look and it will indeed prove very useful. Thanks a lot.
> >
> > It is a bit tedious however to find the relevant strings amongst all
> > the other ones. My first reaction was to scroll and after a while I
> > finally got the sense to use the Find feature of my browser to look up
> > "fuzzy". Can we maybe show *only* the fuzzy messages?
>
> That was exactly my thinking last night :-)
>
> Will try that.
>
> 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: String & UI Freeze break request for GNOME Shell

2019-09-04 Thread Daniel Mustieles García via gnome-i18n
This request has 2/2 from release-team, and it's just one string (with one
word).

I agree with Alexandre, but having RT approval there is no need to stop
this from i18n, so 1/2.

Regards

El mié., 4 sept. 2019 a las 7:28, Alexandre Franke ()
escribió:

> On Tue, Sep 3, 2019 at 11:55 PM Arnaud Bonatti 
> wrote:
> > They cannot, there is no way to do that. Well, in fact, they can set
> > all the things manually if they know dconf-editor as I know it, as its
> > maintainer and main developer; but the *creation* of a folder would
> > look impossible to most users, due to the way the settings are done
> > (only command line allows that, more easily with `dconf` than with
> > `gsettings`; or Software, until now at least); and there is nothing
> > that will help them to do a *renaming*, in any way.
>
> Ok. I took Georges' indication as “it can be done with gsettings”
> anyway, so that doesn’t change my approval and conditions.
>
> --
> Alexandre Franke
> GNOME Hacker
> ___
> 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: GTXML report: errors in documentation

2019-09-04 Thread Daniel Mustieles García via gnome-i18n
Hi Ask,

Yes, but since I download all the PO files from DL in a folder an then
check them I have no way to guess which module they belong to. Only the PO
file might give us a clue but as you've said it's not always clear.

A possible solution could be extract each set in separate folders (core,
gimp-help, etc), create a single report for them and merge reports in a big
one, with separate sections. I cant take a look into it ;-)

Thanks!

El mié., 4 sept. 2019 a las 0:06, Ask Hjorth Larsen ()
escribió:

> Thanks Daniel.
>
> For future reference, it might be helpful to include also the project
> directory.  This is because gimp-help-2 has files like "glossary.po"
> which are not sufficient to tell where the file comes from.
>
> Best regards
> Ask
>
> Am Di., 3. Sept. 2019 um 12:12 Uhr schrieb Daniel Mustieles García via
> gnome-i18n :
> >
> > Hi all,
> >
> > As usual, I've created a report (attatched) with the languages
> containing typos or errors in tags in documentation files. Here is the list
> of the affected languages:
> >
> > ca
> > cs
> > da
> > es
> > fr
> > ja
> > pt_BR
> > ro
> > ru
> >
> > Please fix them before the new release, to avoid errors when compiling
> the affected modules. If you need help fixing it, just let me know and I'll
> help you.
> >
> > Regards
> > ___
> > 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: DL - Error in diff view

2019-09-12 Thread Daniel Mustieles García via gnome-i18n
Many thanks Claude for your help!

Regards

El mié., 11 sept. 2019 a las 23:42, Claude Paroz ()
escribió:

> Sorry, this is due to some path migration on the server. I fixed it now
> by setting temporary symlinks and will fix it soon in the DL code.
> This is a preparation to some infrastructure change (moving to
> OpenShift). We'll try to make it with the less disturbance as possible
> for translators.
>
> Claude
>
> Le 11.09.19 à 11:52, Daniel Mustieles García a écrit :
> > Hi Claude,
> >
> > When I try to see diff view between original and uploaded PO file, I got
> > a "Page not found" error in DL. This is the link I'm trying to access:
> > https://l10n.gnome.org/vertimus/diff/494216/0/0/
> >
> > And this is the page of the module I'm trying to proofread:
> > https://l10n.gnome.org/vertimus/gnome-user-docs/master/gnome-help/es/
> >
> > Could you please review it?
> >
> > Thanks in advance!
> ___
> 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: 3.34 release notes ready for translation

2019-09-13 Thread Daniel Mustieles García via gnome-i18n
cause reasons above (errors
> that I made at beginning), it took me 5 years to become commiter/reviewer
> in Ubuntu.
>
> I accept your translation to GIMP because GIMP is crossplatform apps,
> although translation errors mentioned above.
>
> You make too many translation errors, and I think the reason is that you
> are not a (experienced) Linux user and you are not to good familiar with
> the GNOME environment.
> When you contacted me you said that you even were not using any Linux
> distribution but that you are a Mac OS user.
>
> If you do not use Linux I do not see the point for translating it.
> Since you are not a Linux user, if you want to contribute to translation,
> you have many other translation systems like transifex, crowdin and many
> others, there you can translate many apps you are using in Mac OS.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> pet, 13. ruj 2019. u 10:09 Daniel Mustieles García via gnome-i18n <
> gnome-i18n@gnome.org> napisao je:
>
>>
>>
>> El vie., 13 sept. 2019 a las 9:44, Alexandre Franke ()
>> escribió:
>>
>>> On Fri, Sep 13, 2019 at 8:37 AM Daniel Mustieles García via gnome-i18n
>>>  wrote:
>>> > Images can be committed directly to the repo using command line ;-)
>>> >
>>> > MR will probably got rejected since maintainers do not take care of
>>> translations directly. That task belong to us.
>>>
>>> Right. But we’re trying to move away from translators and coordinators
>>> needing direct git access and an MR was the correct thing to do in
>>> this case. We should educate the maintainers about that and the
>>> language coordinator should be pinged to review these MR.
>>>
>>
>> Sure. I wondered if we could grant him *commiter* role in DL since the
>> coordinator seems to be missing (I pinged him in another thread and still
>> have no answer). MiloType has a lot of translations awating approval, not
>> only release-notes one.
>>
>>>
>>> Christian, do you have a link to that MR please so we can explain the
>>> situation with our i18n hat on?
>>>
>>> --
>>> Alexandre Franke
>>> GNOME Hacker
>>>
>> ___
>> 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: String freeze break request for gnome-shell

2019-09-11 Thread Daniel Mustieles García via gnome-i18n
2/2 from i18n

Thanks!

El mié., 11 sept. 2019 a las 7:55, Piotr Drąg via gnome-i18n (<
gnome-i18n@gnome.org>) escribió:

> śr., 11 wrz 2019, 00:43 użytkownik Florian Müllner 
> napisał:
>
>> Hey!
>>
>> I'd like to push a minor string change in
>> https://gitlab.gnome.org/GNOME/gnome-shell/issues/1538.
>>
>> The change is in the --help output of the newly-added gnome-extensions
>> CLI tool and very simple:
>> "Use %s to get detailed help.\n" becomes
>> "Use “%s” to get detailed help.\n" (note the quotation marks around %s).
>>
>> It is not very important to get the change into 3.34.1, but Piotr
>> suggested asking for a freeze break, so here we are :-)
>>
>
> And here’s 1/2 from i18n. :)
>
> Best,
> Piotr
>
>> ___
> 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


DL - Error in diff view

2019-09-11 Thread Daniel Mustieles García via gnome-i18n
Hi Claude,

When I try to see diff view between original and uploaded PO file, I got a
"Page not found" error in DL. This is the link I'm trying to access:
https://l10n.gnome.org/vertimus/diff/494216/0/0/

And this is the page of the module I'm trying to proofread:
https://l10n.gnome.org/vertimus/gnome-user-docs/master/gnome-help/es/

Could you please review it?

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


Re: 3.34 release notes ready for translation

2019-09-16 Thread Daniel Mustieles García via gnome-i18n
Hi Milo,

El dom., 15 sept. 2019 a las 15:24, Milo Ivir ()
escribió:

> Please excuse, but I'd like to share my thoughts on this subject one last
> time on i18n list.
> Issues about the translation itself, I'll try to solve with Gogo directly.
>
> It would be great if we could find a solution for my translator/commiter
> status, as well as find a way, how to increase the speed for translations
> getting into the releases. Currently I'm the only translator, there are no 
> reviewers
> nor committers and Gogo is the coordinator.
>

You must talk about this with Croatian team coordinator . We have no
criteria to decice if someone has o has no become reviewer or commiter in a
translation team. If you have enought skills to assume those tasks let yor
coordinator know it. Take into account that team coordinator also has
reviewer and commiter roles.

>
> By now 17 of my translation files are stuck in the system since june.
> Half of them are new and complete translations.
>
> 13.09.2019., u 14:31, gogo gogić via gnome-i18n  je
> napisao:
>
> If you do not use Linux I do not see the point for translating it.
>
> My interest is to translate and improve translations of open source
> software. I don't think being a Linux user is a requirement to translate or
> to improve existing translations in the GNOME project. Also, many apps
> outside of Linux are using gtk nowadays, or the cross-platform app Gimp, as
> mentioned before.
>

I disagree with you in this point. If you aren't a GNOME user you will miss
some terms we use and your translations won't be accurate. Yes, Gimp is
cross-platform  and it uses a very specific language, but other GNOME
modules use general terms used in GNOME that you should know before
translating.

>
> 13.09.2019., u 14:31, gogo gogić via gnome-i18n  je
> napisao:
>
> Since you are not a Linux user, if you want to contribute to translation,
> you have many other translation systems like transifex, crowdin and many
> others, there you can translate many apps you are using in Mac OS.
>
> Even if you may not mean it this way, it's like saying: "Go play somewhere
> else."
> The idea is to colaborate, not contra-laborate ;-)
>

Collaborations require some quality... your "contra-colaborate" thinks are
only "keep quality" thinks in our side ;-)

>
> BTW, you are on Transifex as well, where you are also ignoring my requests
> tojoin/ translate/commit files for (non-GNOME) freedesktop.org (I've made
> a request 2 months ago).
>
>
> So please, let's find a solution …
>

Talk about this with Gogo... it's the only one I see, sorry

Best regards.
>
>
>
>
> 13.09.2019., u 14:57, Daniel Mustieles García via gnome-i18n <
> gnome-i18n@gnome.org> je napisao:
>
> Hi gogo,
>
> Maybe i18n list is not the proper place to have this kind of
> discussion/comments, specially due to your (sometimes) rude language.
>
> If you consider those translations have not enough quality to be in GNOME
> it's great you've detected it, but this list is not the proper place to
> drop your comments about it (nor comments about if a person is suitable or
> not to do this kind of task).
>
> This should be resolved in your team's mailing list or private thread, but
> not Ccin'g i18n list. Most of us don't speak Croatian so we can't evaluate
> those translations to guess who is right in the discussion...
>
> Thanks for understanding this point.
>
> Best regards.
>
> El vie., 13 sept. 2019 a las 14:31, gogo gogić ()
> escribió:
>
>> Milo!
>>
>> Damned Lies:
>> https://l10n.gnome.org/vertimus/diff/480332/0/0/
>> This is not translation, it's more or less unnecessary changing already
>> translated translation.
>>
>> What a hell is "spremišta" Repository is Repository, on Croatian
>> "Repozitorij"
>> Do you understand concept of Linux repositories?
>>
>> master branch - It's not grana, It's "glavni ogranak", like GIT main
>> branch
>> mailing list "pretplatnička lista" is it's a literal translation which
>> nobody uses it, it's simple "mailing lista"
>>
>> Damned Lies is Damned Lies, literal translation like "Proklete laži" I
>> think is sounds stupid on Croatian, so it's better to stay Damned Lies
>> because it's the name of Gnome translation system.
>>
>> extensions-web:
>> https://l10n.gnome.org/vertimus/diff/489235/0/0/
>> Like Damned Lies, it's more or less unnecessary changing already
>> translated translation.
>> Except:
>> msgid "About" msgstr "O"  It's better msgstr "Informacije"
>>
>> msgid "Install GNOME Shell int

Re: 3.34 release notes ready for translation

2019-09-13 Thread Daniel Mustieles García via gnome-i18n
El vie., 13 sept. 2019 a las 9:44, Alexandre Franke ()
escribió:

> On Fri, Sep 13, 2019 at 8:37 AM Daniel Mustieles García via gnome-i18n
>  wrote:
> > Images can be committed directly to the repo using command line ;-)
> >
> > MR will probably got rejected since maintainers do not take care of
> translations directly. That task belong to us.
>
> Right. But we’re trying to move away from translators and coordinators
> needing direct git access and an MR was the correct thing to do in
> this case. We should educate the maintainers about that and the
> language coordinator should be pinged to review these MR.
>

Sure. I wondered if we could grant him *commiter* role in DL since the
coordinator seems to be missing (I pinged him in another thread and still
have no answer). MiloType has a lot of translations awating approval, not
only release-notes one.

>
> Christian, do you have a link to that MR please so we can explain the
> situation with our i18n hat on?
>
> --
> Alexandre Franke
> GNOME Hacker
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Error generating POT: gnome-video-effects

2019-08-02 Thread Daniel Mustieles García via gnome-i18n
Hi all,

There is an error in gnome-video-effects, DL can't generate POT file:

https://l10n.gnome.org/vertimus/gnome-video-effects/master/po/es/

This happens for several languages, not only for Spanish

It seems that the last commit in the project was some weeks ago, so maybe
the issue is in the DL side.

@Claude: could you please take a look into it?

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


Re: Error generating POT: gnome-video-effects

2019-08-02 Thread Daniel Mustieles García via gnome-i18n
El vie., 2 ago. 2019 a las 10:17, Claude Paroz ()
escribió:

> Le 02.08.19 à 08:57, Daniel Mustieles García via gnome-i18n a écrit :
> > Hi all,
> >
> > There is an error in gnome-video-effects, DL can't generate POT file:
> >
> > https://l10n.gnome.org/vertimus/gnome-video-effects/master/po/es/
> >
> > This happens for several languages, not only for Spanish
> >
> > It seems that the last commit in the project was some weeks ago, so
> > maybe the issue is in the DL side.
>
> The commit which transitions from intltool to meson was applied just 3
> days ago.
>

Where is it in Gitlab? The commits I see in
https://gitlab.gnome.org/GNOME/gnome-video-effects/commits/master are older
than 3 days

>
> The problem is that xgettext autodetection of the file format doesn't
> succeed (.effect is unknown to gettext).
> We can workaround this by forcing --language=Desktop in XGETTEXT_OPTIONS
> of Makevars. But I fear we'll have issues as soon as a different file
> format is added to POTFILES.in.
>

Not sure about what this change implies... are more modules migrating to
intltool and it will break stats? Sorry if the question has already been
answered, but at this moment I don't remember it.

Thanks Claude!

>
> 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: String freeze break request for Iagno

2019-09-28 Thread Daniel Mustieles García via gnome-i18n
I thought string freeze break was only when new strings were
added...modifying or marking as translatable an existing one was not a
break (this second case always surprised me...).

Which are the cases we should consider a freeze break?

Thanks!

El sáb., 28 sept. 2019 19:09, Piotr Drąg  escribió:

> sob., 28 wrz 2019 o 18:56 Arnaud Bonatti 
> napisał(a):
> >
> > Hi Piotr,
> >
> > 2019-09-28 18:43 UTC+02:00, Piotr Drąg :
> > > sob., 28 wrz 2019 o 18:32 Daniel Mustieles García
> > >  napisał(a):
> > >>
> > >> Isn't it a fix in an already marked for translation string? I thought
> it
> > >> was... Sorry for the noise
> > >>
> > >
> > > It is, which changes strings, i.e. breaks the string freeze. I get
> > > confused sometimes too. :)
> >
> > Hey, I’m lost now! :·) The fix is already pushed, are things good for
> > you, or should I do something more?
> >
>
> I consider Daniel’s approval to still count, so we’re all good. :)
>
> Best,
>
> --
> Piotr Drąg
> https://piotrdrag.fedorapeople.org
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: String freeze break request for Iagno

2019-09-28 Thread Daniel Mustieles García via gnome-i18n
No need to approve this since technically it's not a freeze break but here
it goes... +1 from i18n ;-)

El sáb., 28 sept. 2019 10:49, Arnaud Bonatti via gnome-i18n <
gnome-i18n@gnome.org> escribió:

> Oh, right, “capturable” of course, not “capurable”. :·)
>
> Can I have a second validation from i18n here?
>
> --
> Arnaud Bonatti
> 
> téléphone : +33(0)6 50 57 23 49
> courriel : arnaud.bona...@gmail.com
> ___
> 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: String freeze break request for Iagno

2019-09-28 Thread Daniel Mustieles García via gnome-i18n
Isn't it a fix in an already marked for translation string? I thought it
was... Sorry for the noise

El sáb., 28 sept. 2019 14:11, Piotr Drąg  escribió:

> sob., 28 wrz 2019 o 13:13 Daniel Mustieles García via gnome-i18n
>  napisał(a):
> >
> > No need to approve this since technically it's not a freeze break but
> here it goes... +1 from i18n ;-)
> >
>
> How is it not a break?
>
> 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: String freeze break request for Iagno

2019-09-29 Thread Daniel Mustieles García via gnome-i18n
Many thanks! I was wrong about changing an existing string, but now I have
it in mind ;-)

El sáb., 28 sept. 2019 19:55, Piotr Drąg  escribió:

> sob., 28 wrz 2019 o 19:49 Daniel Mustieles García
>  napisał(a):
> >
> > I thought string freeze break was only when new strings were
> added...modifying or marking as translatable an existing one was not a
> break (this second case always surprised me...).
> >
> > Which are the cases we should consider a freeze break?
> >
>
> Here is the list of cases covered:
>
> https://wiki.gnome.org/TranslationProject/HandlingStringFreezes
>
> In short, changing an already existing string is as much a break as
> adding a new one.
>
> The exception is when a string was not marked for translation by
> mistake, and would just always be in English otherwise.
>
> 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


Error pushing translations for Dia

2019-10-01 Thread Daniel Mustieles García via gnome-i18n
Hi all,

I'm having some problem when trying to push an update for Spanish
translation for Dia. I get the following error in both Damned Lies and
command-line:

GitLab: You are not allowed to push code to protected branches on this
project. To g...@gitlab.gnome.org:GNOME/dia.git ! [remote rejected] master
-> master (pre-receive hook declined) error: failed to push some refs to
'g...@gitlab.gnome.org:GNOME/dia.git

Could you please take a look into it?

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


Re: New string additions

2019-06-14 Thread Daniel Mustieles García via gnome-i18n
El vie., 14 jun. 2019 a las 10:25, Richard Hughes ()
escribió:

> Hi Daniel,
>
> I don't think translating the release notes is a worthwhile thing to
> do;


Sure, but the problem here is that Damned Lies shows a lot of untranslated
strings and translators have to download and review the files to discover
if those new strings are from release notes or from UI.


> the problem being is that translators don't get a chance to do it
> for the current release between "write metainfo" and "prepare tarball"
> as most maintainers just build the metainfo  when they write
> the NEWS file, i.e. at release time.
>
> I think the upstream appdata.its file marks these for translation
> (shipped withlibappstream -- not maintained by me...), but that's not
> something I agree with.
>

Yes, this is due to a recent change in Damned Lies but seeing the problems
it might carry maybe we should discuss if it's worth to have it.

Thanks for your comments!


> Richard
>
> On Thu, 13 Jun 2019 at 14:40, Daniel Mustieles García
>  wrote:
> >
> > Yes, the Appdata file has release notes from very old versions... maybe
> those strings could be removed/moved to another place.
> >
> > @Richard: any idea about how to deal with this?
> >
> > Thanks!
> >
> > El jue., 13 jun. 2019 a las 14:06, scootergrisen via gnome-i18n (<
> gnome-i18n@gnome.org>) escribió:
> >>
> >> Den 13-06-2019 kl. 11:39 skrev Daniel Mustieles García via gnome-i18n:
> >> > Hi Claude,
> >> >
> >> > Is due to this change that gnome-software[1] has about 600
> unstranslated
> >> > new strings?
> >> >
> >> > It's a very big change in just one day... there is no way to reduce
> it?
> >> >
> >> > Thanks in advance
> >> >
> >> > [1] https://l10n.gnome.org/vertimus/gnome-software/master/po/es/
> >> >
> >>
> >> Seems like strings for a lot of releases going back years:
> >>
> https://gitlab.gnome.org/GNOME/gnome-software/blob/master/data/appdata/org.gnome.Software.appdata.xml.in
> >>
> >> Not sure if there is much point translating all those strings and users
> >> might not see them anyway.
> >>
> >> If i search for GNOME software in GNOME software it says version
> >> 3.30.6-2ubuntu4.19.04.1 but i see none of those strings. Maybe because
> >> the version number does not match any of the strings exactly.
> >>
> >> Seems like a wast of time translation strings for a 2014 release.
> >>
> >> When can a user ever see it?
> >>
> >> I normally prefer to have things fully translated but on SMPlayer
> >> website i can also translate a few new strings on each release but i
> >> find it a bit waste of time because in next release its already
> outdated.
> >>
> >> If we have to translated release changes strings like this for every
> >> software that would not be so much fun and the time could properly be
> >> spendt better on improving the software.
> >> ___
> >> 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: New string additions

2019-06-14 Thread Daniel Mustieles García via gnome-i18n
No, I don't, but surely Claude knows it ;-)

El vie., 14 jun. 2019 a las 11:58, Richard Hughes ()
escribió:

> On Fri, 14 Jun 2019 at 10:56, Daniel Mustieles García
>  wrote:
> > Yes, this is due to a recent change in Damned Lies but seeing the
> problems it might carry maybe we should discuss if it's worth to have it.
>
> Do you know where the appdata.loc file comes from in DL? I think now
> it's upstream gettext and it needs to be filed as an issue there.
>
> Richard.
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: Chronojump gift to translators

2019-11-11 Thread Daniel Mustieles García via gnome-i18n
Hi Xavi!

I know this might sound ugly but since Spanish translation team doesn't
have many members I'd like to propose myself for this great reward.

Many thanks

El vie., 8 nov. 2019 a las 14:20, Xavi de Blas via gnome-i18n (<
gnome-i18n@gnome.org>) escribió:

> Hello all
>
> On Chronojump we want to send a small gift to some translators for their
> continuous work.
> Our application has many strings and we are very glad to send this gift to
> those great helpers.
>
> Looking at stats:
> https://l10n.gnome.org/module/chronojump/
>
> We want to send the gift to the teams with 50% or more of the translation
> done.
> The gift will be for just one person on each team.
>
> The gift could be a T-shirt (black, blue or gray, depending also on sizes)
> http://chronojump.org/en/product/shirt/
>
> or a sweatshirt (only black)
> https://innolab.inefc.net/owncloud/index.php/s/Tn77BQRpbNWx3oZ
> https://innolab.inefc.net/owncloud/index.php/s/d6krq8qqtDbGiRW
>
> The procedure will be:
> 1.- the coordinator of each team answers at this thread saying which
> person will be rewarded.
> 2.- Then I contact this person by email to ask which of the two gifts,
> color, size and shipping address.
> 3.- Gift is sent
>
> Also if some of you are on LAS at Barcelona next week, you can enjoy some
> free beer!
>
> Hope everyone enjoy!
> ___
> 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


Error updating stats

2019-11-28 Thread Daniel Mustieles García via gnome-i18n
Hi Claude,

I've updated some translations for Anjuta documentation (faq and build
tutorial) but stats are not updated in DL. Trying to run a manually refresh
I got the following error:

An error occurred while updating statistics for branch master of module
anjuta:
[Errno 128] Command: "['git', 'clean', '-dfq']", Error: fatal: Not a git
repository: /var/www/gnomeweb/scratchdir/git/anjuta/.git/modules/libgd

Could you please review it?

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


Re: Error updating stats

2019-11-29 Thread Daniel Mustieles García via gnome-i18n
Great, many thanks!

El vie., 29 nov. 2019 a las 16:42, Claude Paroz ()
escribió:

> Le 28.11.19 à 13:03, Daniel Mustieles García a écrit :
> > Hi Claude,
> >
> > I've updated some translations for Anjuta documentation (faq and build
> > tutorial) but stats are not updated in DL. Trying to run a manually
> > refresh I got the following error:
> >
> > An error occurred while updating statistics for branch master of module
> > anjuta:
> > [Errno 128] Command: "['git', 'clean', '-dfq']", Error: fatal: Not a git
> > repository: /var/www/gnomeweb/scratchdir/git/anjuta/.git/modules/libgd
>
> Should be fixed now. Thanks for noticing.
>
> Claude
> --
> www.2xlibre.net
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: [gnome-clocks] String freeze break

2020-02-23 Thread Daniel Mustieles García via gnome-i18n
1/1 from i18n.

Thanks!

El dom., 23 feb. 2020 11:51, Alexandre Franke  escribió:

> On Sun, Feb 23, 2020 at 11:43 AM Bilal Elmoussaoui
>  wrote:
> > Sorry, I sent the wrong files.
>
> Thank you.
>
> Fellow coordinators, the full list of 30 new strings is the following:
> "_Repeat"
> "Active"
> "Edit"
> "Delete"
> "Repeats"
> "Stop"
> "Snooze"
> "Add a New World Clock"
> "Optional"
> "R_emove Alarm"
> "You already have an alarm for this time."
> "Add A_larm"
> "_Cancel"
> "Snoozed from %s: %s"
> "Snoozed from %s"
> "Cancel"
> "Done"
> "Add"
> "M"
> "T"
> "W"
> "T"
> "F"
> "S"
> "S"
> "Mondays"
> "Current timezone"
> "%s hour earlier" / "%s hours earlier"
> "%s hour later" / "%s hours later"
> "Current location"
>
>
> --
> Alexandre Franke
> GNOME Hacker
> ___
> 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: [gnome-clocks] String freeze break

2020-02-24 Thread Daniel Mustieles García via gnome-i18n
Yes, I meant 1/2, sorry for the mistake

Another +1 from i18 is needed before committing the change

El lun., 24 feb. 2020 a las 9:29, Alexandre Franke ()
escribió:

> On Sun, Feb 23, 2020 at 3:50 PM Daniel Mustieles García
>  wrote:
> > 1/1 from i18n.
>
> This was probably a typo, Daniel meant 1/2. Since this is Bilal’s
> first freeze request, I’m gonna pretend they have not pushed the
> changes yet and are still waiting for a second approval. Can we get
> one please?
>
> --
> Alexandre Franke
> GNOME Hacker
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: String freeze request for gnome-shell

2020-02-23 Thread Daniel Mustieles García via gnome-i18n
1/2 from i18n

Thanks!

El lun., 24 feb. 2020 0:45, Matthias Clasen via gnome-i18n <
gnome-i18n@gnome.org> escribió:

>
>
> On Sun, Feb 23, 2020, 17:41 Florian Müllner  wrote:
>
>> Hi y'all!
>>
>> When fixing keyboard navigation on the new lock screen(*), I noticed
>> that we also broke screen readers when turning text buttons into image
>> buttons.
>>
>> The fix is to add a (translatable) accessible name:
>> "Log in as another user"
>>
>
> +1 from me
>
>> ___
> 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 commiting Gimp translations in DL

2020-01-30 Thread Daniel Mustieles García via gnome-i18n
Fixed. Many thanks Claude! :-)

El jue., 30 ene. 2020 a las 9:44, Claude Paroz ()
escribió:

> This should be fixed now (I force removed the lock file on the server).
>
> Regards,
>
> Claude
>
> Le 29.01.20 à 08:50, Daniel Mustieles García a écrit :
> > Hi all,
> >
> > I'm getting the following error when trying to commit GIMP's
> > translations through Damned Lies:
> >
> > «[Errno 128] Command: "['git', 'checkout', '-f', 'master']", Error:
> > fatal: Unable to create
> > '/var/www/djamnedlies/data/scratchdir/git/gimp/.git/index.lock': File
> > exists. If no other git process is currently running, this probably
> > means a git process crashed in this repository earlier. Make sure no
> > other git process is running and remove the file manually to continue. »
> >
> > Committing it directly into git from console it works perfectly.
> >
> > Could you please take a look into this?
> >
> > Thanks in advance for your help!
>
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


gnome-control-center stats are not updated

2020-02-04 Thread Daniel Mustieles García via gnome-i18n
Hi!

gnome-control-center stats in DL are not working properly. It shows one
fuzzy string (for Spanish), but i've committed an up-to-date PO file and it
still remains as fuzzy in DL.

Could you please review?

Can we (translators, team coordinators) do something in this cases? Maybe a
button to force update or something? Just an idea, to avoid disturbing you
with these issues.

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


Error commiting Gimp translations in DL

2020-01-28 Thread Daniel Mustieles García via gnome-i18n
Hi all,

I'm getting the following error when trying to commit GIMP's translations
through Damned Lies:

«[Errno 128] Command: "['git', 'checkout', '-f', 'master']", Error: fatal:
Unable to create
'/var/www/djamnedlies/data/scratchdir/git/gimp/.git/index.lock': File
exists. If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to continue. »

Committing it directly into git from console it works perfectly.

Could you please take a look into this?

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


Re: gnome-control-center stats are not updated

2020-02-05 Thread Daniel Mustieles García via gnome-i18n
Yes, I did it but got an error message.

I've tried again and seems to work ok, but after a while I get a Gateway
Timeout message. It appears frecuently in the last weeks (specially when
uploading Gimp-help's translations). Any idea about why it happens?

Thanks for your help Claude :-)

El mié., 5 feb. 2020 a las 8:56, Claude Paroz ()
escribió:

> Le 04.02.20 à 12:44, Daniel Mustieles García a écrit :
> > Hi!
> >
> > gnome-control-center stats in DL are not working properly. It shows one
> > fuzzy string (for Spanish), but i've committed an up-to-date PO file and
> > it still remains as fuzzy in DL.
> >
> > Could you please review?
> >
> > Can we (translators, team coordinators) do something in this cases?
> > Maybe a button to force update or something? Just an idea, to avoid
> > disturbing you with these issues.
>
> Hi Daniel,
>
> You should be able to force stats refreshing by clicking on the circular
> double-arrows icon beside the branch name.
>
> HTH,
>
> Claude
> --
> www.2xlibre.net
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


GTXML report: errors in documentation

2020-02-18 Thread Daniel Mustieles García via gnome-i18n
Hi all,

As usual, I've created a report (attatched) with the languages containing
typos or errors in tags in documentation files. Here is the list of the
affected languages:

ca
cs
da
de
el
fr
gl
id
ja
pl
pt_BR
ru

Please fix them before the new release, to avoid errors when compiling the
affected modules. If you need help fixing it, just let me know and I'll
help you.

Regards


gtxml-doc-reports.tar.gz
Description: application/gzip
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: [FYI] Updated some localized user docs screenshots; please review/accept

2020-02-17 Thread Daniel Mustieles García via gnome-i18n
Many thanks Andre por taking care of this.

Help with images is always welcome :-)

Regards

El vie., 14 feb. 2020 a las 22:36, Anders Jonsson (<
mailingli...@norsjovallen.se>) escribió:

> On 2020-02-14 19:17, Andre Klapper wrote:
> > I took the liberty to push some updated user documentation screenshots
> > in your language. Please see the list below, sorted by language.
> >
> > The msgid entry for these images should be marked as fuzzy in the
> > corresponding user docs .po file for your language. To actually get
> > these localized screenshots displayed in the help in your language, you
> > have to mark the string for those images as non-fuzzy in the .po file
> > for your language. Please review the images first (or complain to me!).
>
> Thank you! Image help is always welcome. :-)
>
>
> The Swedish images look good, so I have un-fuzzied them.
>
> > --
> > Cheers,
> > andre
> > --
> Regards,
> Anders
> ___
> 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: [DL]String additions to 'tracker.master'

2020-02-20 Thread Daniel Mustieles García via gnome-i18n
Hi Rafael,

I think it is, since endpoint.c has been added as a new file with new
translations.

@Piotr: could you please confirm us if this is a freeze break?

Thanks!

El mié., 19 feb. 2020 a las 18:09, Rafael Fontenelle ()
escribió:

> Hi all,
>
> Is this a string freeze break?
>
> Att,
> Rafael Fontenelle
>
> Em qua., 19 de fev. de 2020 às 13:57, GNOME Status Pages
>  escreveu:
> >
> > This is an automatic notification from status generation scripts on:
> > https://l10n.gnome.org.
> >
> > There have been following string additions to module 'tracker.master':
> >
> > + "A database path must be specified"
> > + "Closing connection…"
> > + "Connects to a DBus service"
> > + "Connects to a remote service"
> > + "Could not own DBus name"
> > + "Create a SPARQL endpoint"
> > + "Creating endpoint at %s…"
> > + "DBus name lost"
> > + "DBus service name"
> > + "DIR"
> > + "Listening to SPARQL commands. Press Ctrl-C to stop."
> > + "Location of the database"
> > + "NAME"
> > + "No database path was provided"
> > + "No endpoint information was provided"
> > + "One “ontology” or “ontology path” option should be provided"
> > + "Opening database at %s…"
> > + "Remote service URI"
> > + "Specify a path to an ontology to be used in this endpoint"
> > + "Specify one --database, --dbus-service or --remote-service option"
> > + "Specify the DBus name of this endpoint"
> > + "Specify the ontology name used in this endpoint"
> > + "Use session bus"
> > + "Use system bus"
> >
> > Note that this doesn't directly indicate a string freeze break, but it
> > might be worth investigating.
> > https://gitlab.gnome.org/GNOME/tracker/commits/master
> > ___
> > 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: Gnome translations / GTranslator hackfest or meeting

2020-01-14 Thread Daniel Mustieles García via gnome-i18n
Hey Dani!

This is a great idea, since Gtranslator has been fixed and improved so it
now is completely usable for GNOME translators as an official translation
tool.

I have some ideas for the integration-with-DL project, and a hackfest might
be an ideal scenario to talk about it. I'm not sure I could move to Malaga,
but surely I could attend it remotely.

Many thanks for your efforts improving and fixing it.

Cheers!

El mar., 14 ene. 2020 a las 10:50, danigm () escribió:

> Hello,
>
> Some time ago I take the gtranslator project [1] and I've updated it to
> use Gtk3 and fixed some issues. Right now I'm just maintaining the
> project and fixing small issues from time to time, but I take advantage
> of internship programs like GSoC and Outreachy to propose projects to
> improve it, so I think we've some resources to spend here and improve
> the translation experience.
>
> I don't know a lot about translations and the GNOME translation
> process, that's the reason because I want to plan a hackfest or a video
> conference talk to review GNOME translators tools and think about how
> we can improve this.
>
> I'm based on Malaga (Spain) and I think that I'll be able to find a
> place to do a 2/3 days hackfest, are there someone interested in
> something like this for Feb or March?
>
> In other case I'll try to plan one or more remote open meetings to work
> on this.
>
> Regards,
>
> [1] http://gitlab.gnome.org/gnome/gtranslator
>
>
> ___
> 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: Password for 3.36 release notes

2020-03-09 Thread Daniel Mustieles García via gnome-i18n
Hi Fran,

Try with gnome/wanda.

I've not been able to see release notes translated in the website. If I
switch to Spanish it shows HTML code.

Please let me/us know if you can see the localized version.

Regards

El lun., 9 mar. 2020 20:11, Fran Dieguez 
escribió:

> Hi,
>
> I'm translating the release notes for 3.36 and I'd like to check it on the
> web.
>
> Could someone please provide me the authentication for the web?
>
> Thanks!
> ___
> 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: Build error

2020-03-11 Thread Daniel Mustieles García via gnome-i18n
We can watch it and add new languages to Makefile if they are added into
DL, there is no problem with it.

About DL, yes, it would be great if it would allow doing things like you
did, but it doesn't. The best option would be adding new languages
automagically to Makefile, but it was difficult to implement properly

El mar., 10 mar. 2020 a las 23:00, Rafael Fontenelle ()
escribió:

> Hi Daniel,
>
> I notice the warning, but I'm afraid that D-L might allow adding new
> translation to Release Notes by adding it to the LINGUAS file, and
> right now Release Notes does not read the LINGUAS file.  Don't you
> think this can be a problem like translation being added but not
> effectively enabled?
>
> Em ter., 10 de mar. de 2020 às 18:55, Daniel Mustieles García
>  escreveu:
> >
> > Hi Rafael,
> >
> > I've done it because DL was not able to read languages variable from the
> Makefile, showing warnings in every language shown in DL for release-notes
> module.
> >
> > I know adding languages manually to Makefile is not the best option, but
> that's the way it's done in other modules and avoids DL showing warnings.
> >
> > Maybe I should have noticed you before applying it, sorry. Hope you
> understand why I made that change.
> >
> > Regards
> >
> > El mar., 10 mar. 2020 22:10, Rafael Fontenelle 
> escribió:
> >>
> >> Hello Daniel,
> >>
> >> I notice you partially reverted the addition of LINGUAS to
> >> release-notes, which might cause new translations added via Damned
> >> Lies to not be made available to the resulting documentation. Can
> >> please explain your reasons?
> >>
> >> Best regards,
> >> Rafael Fontenelle
> >>
> >> Em seg., 9 de mar. de 2020 às 15:49, Rafael Fontenelle
> >>  escreveu:
> >> >
> >> > Em seg., 9 de mar. de 2020 às 12:50, Link Dupont 
> escreveu:
> >> > >
> >> > > Thanks for the MR Rafael. I just merged it. Don't worry about
> opening
> >> > > an MR against master right now. master is very outdated. The current
> >> > > branching process is to branch off the previous gnome-3-xx version
> (so
> >> > > for example, I branched off gnome-3-34 to create gnome-3-36). I
> plan on
> >> > > cleaning up master after 3.36 is done so that we properly branch off
> >> > > master for each release, like other modules do.
> >> > >
> >> >
> >> > Thanks for merging it!
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: Build error

2020-03-11 Thread Daniel Mustieles García via gnome-i18n
Sure, I've reverted the commit I did, so LINGUAS is again called from
Makefile.

Thanks Claude!

El mié., 11 mar. 2020 a las 8:30, Claude Paroz ()
escribió:

> I'm sorry, I didn't check if the LINGUAS thing was working for
> release-notes. I would have fixed D-L if I had known.
>
> Maybe you could re-apply the LINGUAS patch and I'll fix D-L ASAP. Just
> tell me.
>
> Claude
>
> Le 11.03.20 à 08:21, Daniel Mustieles García via gnome-i18n a écrit :
> > We can watch it and add new languages to Makefile if they are added into
> > DL, there is no problem with it.
> >
> > About DL, yes, it would be great if it would allow doing things like you
> > did, but it doesn't. The best option would be adding new languages
> > automagically to Makefile, but it was difficult to implement properly
> >
> > El mar., 10 mar. 2020 a las 23:00, Rafael Fontenelle
> > (mailto:rafae...@gnome.org>>) escribió:
> >
> > Hi Daniel,
> >
> > I notice the warning, but I'm afraid that D-L might allow adding new
> > translation to Release Notes by adding it to the LINGUAS file, and
> > right now Release Notes does not read the LINGUAS file.  Don't you
> > think this can be a problem like translation being added but not
> > effectively enabled?
> >
> > Em ter., 10 de mar. de 2020 às 18:55, Daniel Mustieles García
> > mailto:daniel.mustie...@gmail.com>>
> > escreveu:
> > >
> > > Hi Rafael,
> > >
> > > I've done it because DL was not able to read languages variable
> > from the Makefile, showing warnings in every language shown in DL
> > for release-notes module.
> > >
> > > I know adding languages manually to Makefile is not the best
> > option, but that's the way it's done in other modules and avoids DL
> > showing warnings.
> > >
> > > Maybe I should have noticed you before applying it, sorry. Hope
> > you understand why I made that change.
> > >
> > > Regards
> > >
> > > El mar., 10 mar. 2020 22:10, Rafael Fontenelle  > <mailto:rafae...@gnome.org>> escribió:
> > >>
> > >> Hello Daniel,
> > >>
> > >> I notice you partially reverted the addition of LINGUAS to
> > >> release-notes, which might cause new translations added via Damned
> > >> Lies to not be made available to the resulting documentation. Can
> > >> please explain your reasons?
> > >>
> > >> 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


Re: Password for 3.36 release notes

2020-03-10 Thread Daniel Mustieles García via gnome-i18n
El lun., 9 mar. 2020 a las 21:38, Andre Klapper () escribió:

> On Mon, 2020-03-09 at 20:35 +0100, Daniel Mustieles García wrote:
> > I've not been able to see release notes translated in the website. If
> > I switch to Spanish it shows HTML code.
>
> $:acko\> curl -I
> https://help.gnome.org/misc/release-notes/3.36/index.html.es
> Content-Type
> :
> application/ecmascript
>
> $:acko\> curl -I
> https://help.gnome.org/misc/release-notes/3.36/index.html.fr
> Content-Type
> :
> text/html; charset=UTF-8
>
> Wild guess: The ".es" URL ending makes browsers assume ECMAScript code,
> so "X-Content-Type-Options" should be set to "nosniff"?
>
> Id' say feel free to file a ticket under
> https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/ or so.
>

Yes, I did it yesterday:
https://gitlab.gnome.org/Infrastructure/help.gnome.org/issues/1

Maybe it's just a server configuration issue. Meanwhile we can review
translations directly in the PO file.

Thanks!

>
> 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
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: Build error

2020-03-11 Thread Daniel Mustieles García via gnome-i18n
Great, thanks!

El mié., 11 mar. 2020 a las 14:20, Claude Paroz ()
escribió:

> Should be OK now, thanks for re-applying.
>
> Claude
>
> Le 11.03.20 à 08:48, Daniel Mustieles García a écrit :
> > Sure, I've reverted the commit I did, so LINGUAS is again called from
> > Makefile.
> >
> > Thanks Claude!
> >
> > El mié., 11 mar. 2020 a las 8:30, Claude Paroz ( > <mailto:cla...@2xlibre.net>>) escribió:
> >
> > I'm sorry, I didn't check if the LINGUAS thing was working for
> > release-notes. I would have fixed D-L if I had known.
> >
> > Maybe you could re-apply the LINGUAS patch and I'll fix D-L ASAP.
> Just
> >     tell me.
> >
> > Claude
> >
> > Le 11.03.20 à 08:21, Daniel Mustieles García via gnome-i18n a écrit :
> > > We can watch it and add new languages to Makefile if they are
> > added into
> > > DL, there is no problem with it.
> > >
> > > About DL, yes, it would be great if it would allow doing things
> > like you
> > > did, but it doesn't. The best option would be adding new languages
> > > automagically to Makefile, but it was difficult to implement
> properly
> > >
> > > El mar., 10 mar. 2020 a las 23:00, Rafael Fontenelle
> > > (mailto:rafae...@gnome.org>
> > <mailto:rafae...@gnome.org <mailto:rafae...@gnome.org>>>) escribió:
> > >
> > > Hi Daniel,
> > >
> > > I notice the warning, but I'm afraid that D-L might allow
> > adding new
> > > translation to Release Notes by adding it to the LINGUAS file,
> and
> > > right now Release Notes does not read the LINGUAS file.  Don't
> you
> > > think this can be a problem like translation being added but
> not
> > > effectively enabled?
> > >
> > > Em ter., 10 de mar. de 2020 às 18:55, Daniel Mustieles García
> > >  > <mailto:daniel.mustie...@gmail.com>
> > <mailto:daniel.mustie...@gmail.com  daniel.mustie...@gmail.com>>>
> > > escreveu:
> > > >
> > > > Hi Rafael,
> > > >
> > > > I've done it because DL was not able to read languages
> variable
> > > from the Makefile, showing warnings in every language shown in
> DL
> > > for release-notes module.
> > > >
> > > > I know adding languages manually to Makefile is not the best
> > > option, but that's the way it's done in other modules and
> > avoids DL
> > > showing warnings.
> > > >
> > > > Maybe I should have noticed you before applying it, sorry.
> Hope
> > > you understand why I made that change.
> > > >
> > > > Regards
> > > >
> > > > El mar., 10 mar. 2020 22:10, Rafael Fontenelle
> > mailto:rafae...@gnome.org>
> > > <mailto:rafae...@gnome.org <mailto:rafae...@gnome.org>>>
> escribió:
> > > >>
> > > >> Hello Daniel,
> > > >>
> > > >> I notice you partially reverted the addition of LINGUAS to
> > > >> release-notes, which might cause new translations added via
> > Damned
> > > >> Lies to not be made available to the resulting
> > documentation. Can
> > > >> please explain your reasons?
> > > >>
> > > >> Best regards,
> > > >> Rafael Fontenelle
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: GTXML report: errors in documentation

2020-03-09 Thread Daniel Mustieles García via gnome-i18n
Hi again,

Here is an up-to-date report, with still some affected languages:

ca
cs
de
el
fr
gl
id
ja
pt_BR
ru

if you could please review it before the release it would be great!

Thanks in advance for your work

El sáb., 29 feb. 2020 a las 22:40, Jordi Mas ()
escribió:

> Thanks for generating this. It's really useful. I tried to fix most of it.
>
> Jordi,
>
> On Tue, Feb 18, 2020 at 12:13 PM Daniel Mustieles García via gnome-i18n <
> gnome-i18n@gnome.org> wrote:
>
>> Hi all,
>>
>> As usual, I've created a report (attatched) with the languages
>> containing typos or errors in tags in documentation files. Here is the list
>> of the affected languages:
>>
>> ca
>> cs
>> da
>> de
>> el
>> fr
>> gl
>> id
>> ja
>> pl
>> pt_BR
>> ru
>>
>> Please fix them before the new release, to avoid errors when compiling
>> the affected modules. If you need help fixing it, just let me know and I'll
>> help you.
>>
>> Regards
>>
>> ___
>> gnome-i18n mailing list
>> gnome-i18n@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>
>


gtxml-doc-reports.tar.gz
Description: application/gzip
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: gnome-control-center stats are not updated

2020-04-01 Thread Daniel Mustieles García via gnome-i18n
Hi Claude,

This issue is back again, now in all modules, not only in Gimp-help.

Cc'ing Andrea Veri, maybe he can modify webserver's timeout to avoid
gateway timeout message every time a module is commited into git trought DL.

Thanks!

El mié., 5 feb. 2020 a las 10:03, Claude Paroz ()
escribió:

> Le 05.02.20 à 09:25, Daniel Mustieles García a écrit :
> > Yes, I did it but got an error message.
> >
> > I've tried again and seems to work ok, but after a while I get a Gateway
> > Timeout message. It appears frecuently in the last weeks (specially when
> > uploading Gimp-help's translations). Any idea about why it happens?
>
> For sure, that's a classical issue with long Web operations. These
> should be deferred to some task queue on the server, but I didn't find
> time for this development in recent times.
>
> Claude
> --
> www.2xlibre.net
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: Broken markup in [es, hu, sv] zenity user doc translations

2020-04-03 Thread Daniel Mustieles García via gnome-i18n
Hi Andre,

Spanish should be fixed, many thanks for reporting it.

I don't know about Gitlab, buy PyG3t tools (gtxml especifically) checks XML
syntax to detect this cases. I've put this on the table several times,
asking to integrate it in DL like msgfmt is. This would help us avoid this
situations, maybe now we can talk about it again ;-)

Regards

El vie., 3 abr. 2020 a las 9:51, Andre Klapper () escribió:

> There is a contributed patch by Christian in
> https://gitlab.gnome.org/GNOME/zenity/-/merge_requests/4/
> which fixes broken markup in the es, hu, sv user help translations.
>
> I'd like to merge this patch (and hence bypass our l10n.gnome.org
> process) as the situation breaks compiling.
> https://l10n.gnome.org/module/zenity/ shows none of these languages
> have any translations in progress, so I think this is acceptable.
>
> I also already boldly fixed
> https://gitlab.gnome.org/Teams/Translation/el/issues/6
> as I have received no feedback for months from Greek translators and
> https://l10n.gnome.org/vertimus/zenity/master/help/el/ is inactive.
>
> I'm generally wondering how much teams follow 'their' issue tracker.
>
> And Christian's question:
> Does anyone know if/how this could have been caught by GitLab CI?
>
> 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
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: Broken markup in [es, hu, sv] zenity user doc translations

2020-04-03 Thread Daniel Mustieles García via gnome-i18n
Never mind ;-)

My proposal is to include gtxml as part of the checks DL (or git, in a
pre-commit hook) does, like it's currently done with msgfmt, to avoid this
issues when committing help files (maybe a pre-commit hook is the best
option, to also detect possible issues out of DL workflow).

As a pre-commit hook it should be easy to implement (maybe Andrea Veri
could help us with this). In DL I don't know how much difficult it is.

About the issue with the <_:link> tag, I'm sure Ask will be able to know
why it happened and fix it :-)

El vie., 3 abr. 2020 a las 11:47, Andre Klapper () escribió:

> On Fri, 2020-04-03 at 11:26 +0200, Daniel Mustieles García wrote:
> > Yes, id hast not detected that one (and I'm Cc'ed Ask, gtxml's
> > developer to review it) but id detects many others. Are we dropping a
> > good tool because of an isolated bug? ;-)
>
> Ah, sorry, I thought you had meant that gtxml (which I also love to use
> locally) could have caught this issue. Looks like I misunderstood you!
>
> andre
>
> > El vie., 3 abr. 2020 a las 11:08, Andre Klapper ()
> > escribió:
> > > [No need to CC me as I am a mailing list member]
> > >
> > > On Fri, 2020-04-03 at 10:19 +0200, Daniel Mustieles García wrote:
> > > > I don't know about Gitlab, buy PyG3t tools (gtxml especifically)
> > > > checks XML syntax to detect this cases.
> > >
> > > No, as you wrote yourself that it does NOT detect these cases in
> > > https://gitlab.gnome.org/GNOME/zenity/-/issues/17#note_758794 : "It
> > > was
> > > a wrong <_:link> tag in license string, but gtxml didn't detect
> > > it." :)
> > >
> > > 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
> >
> > ___
> > gnome-i18n mailing list
> > gnome-i18n@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gnome-i18n
> --
> 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
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: Broken markup in [es, hu, sv] zenity user doc translations

2020-04-03 Thread Daniel Mustieles García via gnome-i18n
Yes, id hast not detected that one (and I'm Cc'ed Ask, gtxml's developer to
review it) but id detects many others. Are we dropping a good tool because
of an isolated bug? ;-)

El vie., 3 abr. 2020 a las 11:08, Andre Klapper () escribió:

> [No need to CC me as I am a mailing list member]
>
> On Fri, 2020-04-03 at 10:19 +0200, Daniel Mustieles García wrote:
> > I don't know about Gitlab, buy PyG3t tools (gtxml especifically)
> > checks XML syntax to detect this cases.
>
> No, as you wrote yourself that it does NOT detect these cases in
> https://gitlab.gnome.org/GNOME/zenity/-/issues/17#note_758794 : "It was
> a wrong <_:link> tag in license string, but gtxml didn't detect it." :)
>
> 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
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: Translation updates through gitlab?

2020-04-02 Thread Daniel Mustieles García via gnome-i18n
Hi Jehan,

There are several teams that don't use Damned Lies' workflow, relying it on
malining list, for example, so using MRs is an option.

But you cannot forget about DL at all because PO file in your repository
are not valid for translation. I mean, those PO files are static, they are
not automatically updated with new strings added to source code. That's
part of the magic of Damned Lies :-)

The PO file you download from DL is not a direct link to PO file in git:
i'ts generated using some tools that read POTFILES and other files and
extract translatable strings to generate an up-to-date PO file. Of course
you can do that process manually, but maybe it makes no sense to duplicate
efforts.

Another question is: who will review those translations? You should
encourage every translation team to use that new workflow, and opening that
door can be "dangerous": most of the coordinators won't accept modifying
their workflow, because it simply works. Having two ways to receive/review
translations (gitlab's MR and DL) can be a pain for those who have to
review and approve them. And you should speak several languages to be able
to review all of them ;-)

Also note that every team has it's own rules: usually there is a team
coordinator that approves commiting translations into git. "Plain"
translators usually not have that power, so accepting translations directly
from translators might cause problems in the translation team.

Just my 2 cents, maybe other people have a different idea, and it's of
course acceptable.

Regards.

El mié., 1 abr. 2020 a las 21:13, Jehan Pagès via gnome-i18n (<
gnome-i18n@gnome.org>) escribió:

> Hello everyone!
>
> Lately we have had some people uploading GIMP translations in the form of
> merge requests on gitlab.
>
> Notably we had someone who uploaded big po files updates for Korean, a
> year ago:
> For GIMP 2.10: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/51
> For master: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/54
>
> He did update a lot of translatable text. Unfortunately he was not
> responsive on gitlab when we (as well as the Korean team coordinator) asked
> him to send his po file through the team channel, even after we tried to
> discuss with him in English or Korean. No idea why. He was capable enough
> to translate hundreds of sentence from English to Korean, use git and make
> gitlab MR, but he would not answer. In the end, we just had to close the MR
> without taking the changes in, which was a bit heartbreaking (never nice to
> waste contributor's hard work, especially as Korean is not updated that
> often unfortunately!).
>
> Recently, after a year, the same person reopened a new MR, and again
> without answering or following procedure:
> https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/213
>
> Also recently someone also opened a MR for zh_TW and he doesn't answer
> much either (though there was only one comment, so I made a new one and
> will wait a bit before closing). Don't know what's up with translators
> making MRs and not following up!
> https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/206
>
> Anyway bottom line: I am wondering if there were a way to improve the
> procedures for translation reviews made through MR? I mean, these
> translators definitely could improve their contribution skills by actually
> reading/answering comments and following up, but the base idea is still
> right. The po files are on our repository so I understand why an outsider
> might think making a MR makes sense. Of course if it ended up that the
> translation was not right, if the translation needed changes before
> merging, with a non-responsive person, the end result might be the same.
> That's a problem anyway. But maybe it could have just worked out without
> changes?
> So yeah, I'd be happy to work more closely with translators team willing
> to review translations in gitlab.
>
> Am I missing something?
> Thanks everyone!
>
> Jehan
>
> --
> ZeMarmot open animation film
> http://film.zemarmot.net
> Liberapay: https://liberapay.com/ZeMarmot/
> Patreon: https://patreon.com/zemarmot
> Tipeee: https://www.tipeee.com/zemarmot
> ___
> 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: ***UNCHECKED*** Fwd: bug reporting

2020-03-26 Thread Daniel Mustieles García via gnome-i18n
El jue., 26 mar. 2020 a las 0:55, Andre Klapper () escribió:

> On Wed, 2020-03-25 at 18:22 +0100, Peter Mraz via gnome-i18n wrote:
> >
> > > bug reporting about issues of l18n is for new member of team
> > > > complicated
> > >
> > > Please explain what exactly is "complicated" with steps to
> > > reproduce,
> > > and what you would like to see instead.
> >
> > traslate english to native language is something else then write
> > whole request in english. Some people have a problem with it.
>
> I might not understand... How is this problem solved by reporting
> something in damned lies itself, instead of GNOME Gitlab?
>
> > > > Is it posible to integrate bug reporting system directly into damnet
> > > > lies?
> > >
> > > Creating more isolated silos is usually never a solution...
> > >
> >
> > I think that could by helpful if we have som standardized forms for
> > common issues like request plural forms, request description and
> > request context. The forms cana automatically generate bugreport and
> > could be localized to native language.
>
> Maybe that's possible, though I'm wondering how OAuth (/LDAP) would
> work between l10n.gnome.org and gitlab.gnome.org because there must be
> that user's account which creates a ticket in GNOME Gitlab. Not sure if
> any and all translators also have a GNOME Gitlab account...
>

Maybe we could create special user for this case (like the Damned Lies user
for commiitng translations). Retrieving each module gitlab's URL should be
easy since DL's API has it (i.e.
https://l10n.gnome.org/api/v1/modules/podcasts).

Also we could make it better: if logged user in DL has account in Gitlab,
issue is opened with that user; if no, use the "default" user.

>
> Setting up task templates in GNOME Gitlab is another option but I don't
> know much about it. Might be on a per-project level so wouldn't scale.
>

Yes, AFAIK gitlab templates are owned by each module, but having a tag to
file every translation issue could work.

Just some ideas ;-)

Regards

>
> 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
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: Evolution stats in DL are not updated

2020-05-01 Thread Daniel Mustieles García via gnome-i18n
Hi Claude,

Yes, I noticed the GTK problem but sent an email to Matthias because I
thought it was caused by a missing file.

Yes, I'm aware DL problems (specially when try to commit GIMP-help
translations... it's a pain). I hope we can solve it soon.

Can we (translators/i18n coordinators) do something?

Many thanks for your help :-)

El jue., 30 abr. 2020 a las 22:15, Claude Paroz ()
escribió:

> Hi Daniel,
>
> Looks like the stats ar now OK again.
> I'm sorry for that (it also happened for gtk recently). There is a major
> problem right now with the D-L hosting. The disk performance of the
> hosting platform is not sufficient for D-L needs (much slower than my
> 9-year old personal machine!).
>
> I'm convinced the GNOME sysadmin team is working hard on the
> infrastructure, but since D-L moved to the OpenShift platform, it
> occasioned a lot of issues and I spent more time on it that I would want.
> I'm pleading to get back to a traditional VM infrastructure, but I'm not
> the one who can decide this currently.
> So sorry for you translators, hopefully we can find a solution in a not
> too far future.
>
> Claude
>
> Le 30.04.20 à 11:40, Daniel Mustieles García via gnome-i18n a écrit :
> > Hi Claude,
> >
> > I've noticed Evolution stats in DL are not being updated. Doing it
> > manually also doesn't work.
> >
> > Last update was done 2 days ago so changes done yesterday are not
> reflected.
> >
> > Could you please review it.
> >
> > Thanks in advance!
> >
> > https://l10n.gnome.org/module/evolution/
> ___
> 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


Evolution stats in DL are not updated

2020-04-30 Thread Daniel Mustieles García via gnome-i18n
Hi Claude,

I've noticed Evolution stats in DL are not being updated. Doing it manually
also doesn't work.

Last update was done 2 days ago so changes done yesterday are not reflected.

Could you please review it.

Thanks in advance!

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


Re: Evolution stats in DL are not updated

2020-05-18 Thread Daniel Mustieles García via gnome-i18n
 > no interest from your side. We keep mentioning on IRC and other
>> mediums
>> >>> > > we're around to offer our knowledge in order to fullfil your
>> needs when
>> >>> > > it comes to maintaining this service properly.
>> >>> > >
>> >>> > > That said, we'll look into moving that volume into Ceph late next
>> week.
>> >>> > >
>> >>> > > [1]
>> >>> > >
>> https://www.dragonsreach.it/2020/03/30/2020-03-30-gnome-infrastructure-up
>> >>> > > dates>
>> >>> > > Il gio 30 apr 2020, 22:24 Claude Paroz  ha
>> scritto:
>> >>> > >> Hi Daniel,
>> >>> > >>
>> >>> > >> Looks like the stats ar now OK again.
>> >>> > >> I'm sorry for that (it also happened for gtk recently). There is
>> a major
>> >>> > >> problem right now with the D-L hosting. The disk performance of
>> the
>> >>> > >> hosting platform is not sufficient for D-L needs (much slower
>> than my
>> >>> > >> 9-year old personal machine!).
>> >>> > >>
>> >>> > >> I'm convinced the GNOME sysadmin team is working hard on the
>> >>> > >> infrastructure, but since D-L moved to the OpenShift platform, it
>> >>> > >> occasioned a lot of issues and I spent more time on it that I
>> would want.
>> >>> > >> I'm pleading to get back to a traditional VM infrastructure, but
>> I'm not
>> >>> > >> the one who can decide this currently.
>> >>> > >> So sorry for you translators, hopefully we can find a solution
>> in a not
>> >>> > >> too far future.
>> >>> > >>
>> >>> > >> Claude
>> >>> > >>
>> >>> > >> Le 30.04.20 à 11:40, Daniel Mustieles García via gnome-i18n a
>> écrit :
>> >>> > >> > Hi Claude,
>> >>> > >> >
>> >>> > >> > I've noticed Evolution stats in DL are not being updated.
>> Doing it
>> >>> > >> > manually also doesn't work.
>> >>> > >> >
>> >>> > >> > Last update was done 2 days ago so changes done yesterday are
>> not
>> >>> > >> > reflected.
>> >>> > >> >
>> >>> > >> > Could you please review it.
>> >>> > >> >
>> >>> > >> > Thanks in advance!
>> >>> > >> >
>> >>> > >> > https://l10n.gnome.org/module/evolution/
>> >>> >
>> >>> > --
>> >>> > Cheers,
>> >>> >
>> >>> > Andrea
>> >>> >
>> >>> > Red Hatter,
>> >>> > Fedora / EPEL packager,
>> >>> > GNOME Infrastructure Team Coordinator,
>> >>> > Former GNOME Foundation Board of Directors Secretary,
>> >>> > GNOME Foundation Membership & Elections Committee Chairman
>> >>> >
>> >>> > Homepage: https://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
>>
>>
>>
>> --
>> Cheers,
>>
>> Andrea
>>
>> Red Hatter,
>> Fedora / EPEL packager,
>> GNOME Infrastructure Team Coordinator,
>> Former GNOME Foundation Board of Directors Secretary,
>> GNOME Foundation Membership & Elections Committee Chairman
>>
>> Homepage: https://www.gnome.org/~av
>>
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: Evolution stats in DL are not updated

2020-05-18 Thread Daniel Mustieles García via gnome-i18n
The commits I did today (~3 hours ago) were made directly from command line
and they wen ok:

https://gitlab.gnome.org/GNOME/epiphany/-/commit/07f89a83001cf6a4e3970c99e96e817141d2b362

The problem is that DL is not updating stats. Following the same example
with Epiphany, last update was done "2020-05-16 10:32 a.m." so the commit I
did today is not being reflected in DL.

Anyway, if you need me to make another commit from command line I can do
it, just let me know ;-)

Thanks!

El lun., 18 may. 2020 a las 12:58, Andrea Veri () escribió:

> That was related as it was preventing the post receive hook to run
> properly. It was fixed this morning, if any of you could send in a commit
> and confirm it'd be lovely.
>
> Thanks!
>
> Il giorno lun 18 mag 2020 alle ore 12:54 Jordi Mas 
> ha scritto:
>
>> Hello,
>>
>> When you commit from command line (at least last night) you got this
>> error:
>>
>>
>>
>>
>>
>>
>>
>> *remote:
>> /opt/gitlab/embedded/service/gitlab-shell/hooks/post-receive.d/post-receive:
>> line 35: /home/admin/bin/git/gnome-post-receive-email: Permission
>> deniedremote: Traceback (most recent call last):remote:   File
>> "/home/admin/bin/git/post-receive-notify-l10n", line 34, in remote:
>> main()remote:   File "/home/admin/bin/git/post-receive-notify-l10n",
>> line 25, in mainremote: branch_name =
>> get_branch_name(sys.stdin.readline().split()[2])remote: IndexError: list
>> index out of range*
>>
>> It may be related
>>
>> Hopefully it helps 
>>
>> Jordi,
>>
>> On Mon, May 18, 2020 at 10:25 AM Daniel Mustieles García via gnome-i18n <
>> gnome-i18n@gnome.org> wrote:
>>
>>> Hi Claude,
>>>
>>> Sorry to bother you again with the same issue, but it DL is not updating
>>> statistics... I've committed some translations (epiphany, swell-foop, for
>>> example) and stats are not updated.
>>>
>>> For example, DL says that Epiphany las update was on 2020-05-16 10:32 a.m
>>>
>>> Thanks in advance for your help
>>>
>>> El sáb., 16 may. 2020 a las 11:32, Daniel Mustieles García (<
>>> daniel.mustie...@gmail.com>) escribió:
>>>
>>>> Don't worry, it seems to be working properly now :-)
>>>>
>>>> Thanks!
>>>>
>>>> El vie., 15 may. 2020 12:08, Andrea Veri  escribió:
>>>>
>>>>> Daniel,
>>>>>
>>>>> forgot to mention the API came back up after a few minutes since your
>>>>> original email yesterday.
>>>>>
>>>>> Please let me know if you see anything else not being functional.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Il giorno gio 14 mag 2020 alle ore 17:25 Daniel Mustieles García
>>>>>  ha scritto:
>>>>> >
>>>>> > Hi Andrea,
>>>>> >
>>>>> > I've just notice the API section in Damned Lies it's not working:
>>>>> >
>>>>> > https://l10n.gnome.org/api/v1/modules/pitivi
>>>>> >
>>>>> > Could you please review it? It is needed by Gtranslator to be able
>>>>> to select and download PO files into the application.
>>>>> >
>>>>> > Thanks in advance for your help
>>>>> >
>>>>> > El jue., 14 may. 2020 a las 15:41, Daniel Mustieles García (<
>>>>> daniel.mustie...@gmail.com>) escribió:
>>>>> >>
>>>>> >> It seems that GIMP-help now works properly (this moduleset was the
>>>>> biggest problem due to timeouts when commiting PO files).
>>>>> >>
>>>>> >> I will test it in the following days and if I see something wrong I
>>>>> will notice you.
>>>>> >>
>>>>> >> Many thanks for your help!
>>>>> >>
>>>>> >> El jue., 14 may. 2020 a las 15:29, Yuri Chornoivan via gnome-i18n (<
>>>>> gnome-i18n@gnome.org>) escribió:
>>>>> >>>
>>>>> >>> четвер, 14 травня 2020 р. 15:49:26 EEST Andrea Veri написано:
>>>>> >>> > Translators,
>>>>> >>> >
>>>>> >>> > we just completed the migration to a different storage backend,
>>>>> please
>>>>> >>> > let us know whether how that contributed to speed up your
>>>>> day

Re: Evolution stats in DL are not updated

2020-05-16 Thread Daniel Mustieles García via gnome-i18n
Don't worry, it seems to be working properly now :-)

Thanks!

El vie., 15 may. 2020 12:08, Andrea Veri  escribió:

> Daniel,
>
> forgot to mention the API came back up after a few minutes since your
> original email yesterday.
>
> Please let me know if you see anything else not being functional.
>
> Thanks!
>
> Il giorno gio 14 mag 2020 alle ore 17:25 Daniel Mustieles García
>  ha scritto:
> >
> > Hi Andrea,
> >
> > I've just notice the API section in Damned Lies it's not working:
> >
> > https://l10n.gnome.org/api/v1/modules/pitivi
> >
> > Could you please review it? It is needed by Gtranslator to be able to
> select and download PO files into the application.
> >
> > Thanks in advance for your help
> >
> > El jue., 14 may. 2020 a las 15:41, Daniel Mustieles García (<
> daniel.mustie...@gmail.com>) escribió:
> >>
> >> It seems that GIMP-help now works properly (this moduleset was the
> biggest problem due to timeouts when commiting PO files).
> >>
> >> I will test it in the following days and if I see something wrong I
> will notice you.
> >>
> >> Many thanks for your help!
> >>
> >> El jue., 14 may. 2020 a las 15:29, Yuri Chornoivan via gnome-i18n (<
> gnome-i18n@gnome.org>) escribió:
> >>>
> >>> четвер, 14 травня 2020 р. 15:49:26 EEST Andrea Veri написано:
> >>> > Translators,
> >>> >
> >>> > we just completed the migration to a different storage backend,
> please
> >>> > let us know whether how that contributed to speed up your day-to-day
> >>> > operations.
> >>> >
> >>> > Thanks!
> >>>
> >>> Hi,
> >>>
> >>> Works much faster. Many thanks for your work.
> >>>
> >>> Best regards,
> >>> Yuri
> >>>
> >>> > Il giorno ven 1 mag 2020 alle ore 14:07 Andrea Veri 
> ha
> >>> scritto:
> >>> > > Claude,
> >>> > >
> >>> > > Your statements are pretty unfair I have to be honest. The current
> issue
> >>> > > is that glusterfs doesn't seem to perform well when trying to cope
> with
> >>> > > big repositories such as gtk or gimp. The solution there is mainly
> moving
> >>> > > this data out of it into the brand new Ceph cluster we deployed and
> >>> > > blogged about [1] recently.
> >>> > >
> >>> > > Openshift is a platform that we introduced for the community and
> used /
> >>> > > loved by multiple contributors as of today. It introduced, as
> every new
> >>> > > technology, a learning curve that has to be filled before the
> actual
> >>> > > features can become of good use. Saying I want to go back to a
> plain VM
> >>> > > is the old please give me back a bare metal because I want all the
> >>> > > performances for myself when the world transitioned off to virtual
> >>> > > machines ages ago. It doesn't scale, adds maintenance burdens, and
> it's
> >>> > > definitely unnecessary.
> >>> > >
> >>> > > The GNOME Infrastructure Team has made sure l10n runs beautifully
> with the
> >>> > > new platform with a service degradation that only happened during
> the
> >>> > > datacenter migration we recently performed and fixed right
> afterwards. On
> >>> > > top of that we made sure the entire VM to container migration was
> >>> > > performed in its *entirety* by us, we offered our help to let you
> >>> > > understand how the platform works to get you up to speed with
> little to
> >>> > > no interest from your side. We keep mentioning on IRC and other
> mediums
> >>> > > we're around to offer our knowledge in order to fullfil your needs
> when
> >>> > > it comes to maintaining this service properly.
> >>> > >
> >>> > > That said, we'll look into moving that volume into Ceph late next
> week.
> >>> > >
> >>> > > [1]
> >>> > >
> https://www.dragonsreach.it/2020/03/30/2020-03-30-gnome-infrastructure-up
> >>> > > dates>
> >>> > > Il gio 30 apr 2020, 22:24 Claude Paroz  ha
> scritto:
> >>> > >> Hi Daniel,
> >>> > >>
> >>> > >> Looks like the sta

Re: Evolution stats in DL are not updated

2020-05-14 Thread Daniel Mustieles García via gnome-i18n
It seems that GIMP-help now works properly (this moduleset was the biggest
problem due to timeouts when commiting PO files).

I will test it in the following days and if I see something wrong I will
notice you.

Many thanks for your help!

El jue., 14 may. 2020 a las 15:29, Yuri Chornoivan via gnome-i18n (<
gnome-i18n@gnome.org>) escribió:

> четвер, 14 травня 2020 р. 15:49:26 EEST Andrea Veri написано:
> > Translators,
> >
> > we just completed the migration to a different storage backend, please
> > let us know whether how that contributed to speed up your day-to-day
> > operations.
> >
> > Thanks!
>
> Hi,
>
> Works much faster. Many thanks for your work.
>
> Best regards,
> Yuri
>
> > Il giorno ven 1 mag 2020 alle ore 14:07 Andrea Veri  ha
> scritto:
> > > Claude,
> > >
> > > Your statements are pretty unfair I have to be honest. The current
> issue
> > > is that glusterfs doesn't seem to perform well when trying to cope with
> > > big repositories such as gtk or gimp. The solution there is mainly
> moving
> > > this data out of it into the brand new Ceph cluster we deployed and
> > > blogged about [1] recently.
> > >
> > > Openshift is a platform that we introduced for the community and used /
> > > loved by multiple contributors as of today. It introduced, as every new
> > > technology, a learning curve that has to be filled before the actual
> > > features can become of good use. Saying I want to go back to a plain VM
> > > is the old please give me back a bare metal because I want all the
> > > performances for myself when the world transitioned off to virtual
> > > machines ages ago. It doesn't scale, adds maintenance burdens, and it's
> > > definitely unnecessary.
> > >
> > > The GNOME Infrastructure Team has made sure l10n runs beautifully with
> the
> > > new platform with a service degradation that only happened during the
> > > datacenter migration we recently performed and fixed right afterwards.
> On
> > > top of that we made sure the entire VM to container migration was
> > > performed in its *entirety* by us, we offered our help to let you
> > > understand how the platform works to get you up to speed with little to
> > > no interest from your side. We keep mentioning on IRC and other mediums
> > > we're around to offer our knowledge in order to fullfil your needs when
> > > it comes to maintaining this service properly.
> > >
> > > That said, we'll look into moving that volume into Ceph late next week.
> > >
> > > [1]
> > >
> https://www.dragonsreach.it/2020/03/30/2020-03-30-gnome-infrastructure-up
> > > dates>
> > > Il gio 30 apr 2020, 22:24 Claude Paroz  ha
> scritto:
> > >> Hi Daniel,
> > >>
> > >> Looks like the stats ar now OK again.
> > >> I'm sorry for that (it also happened for gtk recently). There is a
> major
> > >> problem right now with the D-L hosting. The disk performance of the
> > >> hosting platform is not sufficient for D-L needs (much slower than my
> > >> 9-year old personal machine!).
> > >>
> > >> I'm convinced the GNOME sysadmin team is working hard on the
> > >> infrastructure, but since D-L moved to the OpenShift platform, it
> > >> occasioned a lot of issues and I spent more time on it that I would
> want.
> > >> I'm pleading to get back to a traditional VM infrastructure, but I'm
> not
> > >> the one who can decide this currently.
> > >> So sorry for you translators, hopefully we can find a solution in a
> not
> > >> too far future.
> > >>
> > >> Claude
> > >>
> > >> Le 30.04.20 à 11:40, Daniel Mustieles García via gnome-i18n a écrit :
> > >> > Hi Claude,
> > >> >
> > >> > I've noticed Evolution stats in DL are not being updated. Doing it
> > >> > manually also doesn't work.
> > >> >
> > >> > Last update was done 2 days ago so changes done yesterday are not
> > >> > reflected.
> > >> >
> > >> > Could you please review it.
> > >> >
> > >> > Thanks in advance!
> > >> >
> > >> > https://l10n.gnome.org/module/evolution/
> >
> > --
> > Cheers,
> >
> > Andrea
> >
> > Red Hatter,
> > Fedora / EPEL packager,
> > GNOME Infrastructure Team Coordinator,
> > Former GNOME Foundation Board of Directors Secretary,
> > GNOME Foundation Membership & Elections Committee Chairman
> >
> > Homepage: https://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
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: Evolution stats in DL are not updated

2020-05-14 Thread Daniel Mustieles García via gnome-i18n
Hi Andrea,

I've just notice the API section in Damned Lies it's not working:

https://l10n.gnome.org/api/v1/modules/pitivi

Could you please review it? It is needed by Gtranslator to be able to
select and download PO files into the application.

Thanks in advance for your help

El jue., 14 may. 2020 a las 15:41, Daniel Mustieles García (<
daniel.mustie...@gmail.com>) escribió:

> It seems that GIMP-help now works properly (this moduleset was the biggest
> problem due to timeouts when commiting PO files).
>
> I will test it in the following days and if I see something wrong I will
> notice you.
>
> Many thanks for your help!
>
> El jue., 14 may. 2020 a las 15:29, Yuri Chornoivan via gnome-i18n (<
> gnome-i18n@gnome.org>) escribió:
>
>> четвер, 14 травня 2020 р. 15:49:26 EEST Andrea Veri написано:
>> > Translators,
>> >
>> > we just completed the migration to a different storage backend, please
>> > let us know whether how that contributed to speed up your day-to-day
>> > operations.
>> >
>> > Thanks!
>>
>> Hi,
>>
>> Works much faster. Many thanks for your work.
>>
>> Best regards,
>> Yuri
>>
>> > Il giorno ven 1 mag 2020 alle ore 14:07 Andrea Veri  ha
>> scritto:
>> > > Claude,
>> > >
>> > > Your statements are pretty unfair I have to be honest. The current
>> issue
>> > > is that glusterfs doesn't seem to perform well when trying to cope
>> with
>> > > big repositories such as gtk or gimp. The solution there is mainly
>> moving
>> > > this data out of it into the brand new Ceph cluster we deployed and
>> > > blogged about [1] recently.
>> > >
>> > > Openshift is a platform that we introduced for the community and used
>> /
>> > > loved by multiple contributors as of today. It introduced, as every
>> new
>> > > technology, a learning curve that has to be filled before the actual
>> > > features can become of good use. Saying I want to go back to a plain
>> VM
>> > > is the old please give me back a bare metal because I want all the
>> > > performances for myself when the world transitioned off to virtual
>> > > machines ages ago. It doesn't scale, adds maintenance burdens, and
>> it's
>> > > definitely unnecessary.
>> > >
>> > > The GNOME Infrastructure Team has made sure l10n runs beautifully
>> with the
>> > > new platform with a service degradation that only happened during the
>> > > datacenter migration we recently performed and fixed right
>> afterwards. On
>> > > top of that we made sure the entire VM to container migration was
>> > > performed in its *entirety* by us, we offered our help to let you
>> > > understand how the platform works to get you up to speed with little
>> to
>> > > no interest from your side. We keep mentioning on IRC and other
>> mediums
>> > > we're around to offer our knowledge in order to fullfil your needs
>> when
>> > > it comes to maintaining this service properly.
>> > >
>> > > That said, we'll look into moving that volume into Ceph late next
>> week.
>> > >
>> > > [1]
>> > >
>> https://www.dragonsreach.it/2020/03/30/2020-03-30-gnome-infrastructure-up
>> > > dates>
>> > > Il gio 30 apr 2020, 22:24 Claude Paroz  ha
>> scritto:
>> > >> Hi Daniel,
>> > >>
>> > >> Looks like the stats ar now OK again.
>> > >> I'm sorry for that (it also happened for gtk recently). There is a
>> major
>> > >> problem right now with the D-L hosting. The disk performance of the
>> > >> hosting platform is not sufficient for D-L needs (much slower than my
>> > >> 9-year old personal machine!).
>> > >>
>> > >> I'm convinced the GNOME sysadmin team is working hard on the
>> > >> infrastructure, but since D-L moved to the OpenShift platform, it
>> > >> occasioned a lot of issues and I spent more time on it that I would
>> want.
>> > >> I'm pleading to get back to a traditional VM infrastructure, but I'm
>> not
>> > >> the one who can decide this currently.
>> > >> So sorry for you translators, hopefully we can find a solution in a
>> not
>> > >> too far future.
>> > >>
>> > >> Claude
>> > >>
>> > >> Le 30.04.20 à 11:40, Daniel Mustieles 

Re: Freeze break request for gnome-shell

2020-03-19 Thread Daniel Mustieles García via gnome-i18n
+1 from i18n

Thanks!

El jue., 19 mar. 2020 a las 12:59, Florian Müllner ()
escribió:

> Hey everyone!
>
> As you may know, we now have an official "Extensions" app for managing
> gnome-shell extensions. Unfortunately we missed adding appdata for it,
> so it doesn't show up in GNOME Software at all.
>
> I would like to address this for 3.36.1 as part of
> https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1081, but
> it adds a new translatable string for the description:
>
> "GNOME Extensions handles updating extensions, configuring extension
> preferences and removing or disabling unwanted extensions."
>
> That string has been heavily inspired by the release notes, so
> hopefully it doesn't impose too much work on translators.
>
> Stay safe,
> Florian
>
>
> ___
> 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


  1   2   >