Re: Problems commiting damned-lies package

[Carlos Soriano]

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

Re: [GitLab] Another batch migration coming this week

[Carlos Soriano]

All done, feel free to reenable your notifications

On Tue, 19 Mar 2019 at 17:20, Carlos Soriano  wrote:

> I forgot an important one, i18n (cced now) and all their products will
> also be migrated.
>
> On Tue, 19 Mar 2019 at 11:17, Carlos Soriano  wrote:
>
>> Hey all,
>>
>> As the subject says, whenever I manage to make the tool work I will do
>> another batch migration. If you want to avoid the mass mailing, feel free
>> to turn off Bugzilla notifications.
>>
>> The projects on the batch are these
>> <https://gitlab.gnome.org/Infrastructure/GitLab/issues?label_name%5B%5D=Migration+request>,
>> except those that have the "need evaluation" label.
>>
>> Cheers
>>
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: [GitLab] Another batch migration coming this week

[Carlos Soriano]

I forgot an important one, i18n (cced now) and all their products will also
be migrated.

On Tue, 19 Mar 2019 at 11:17, Carlos Soriano  wrote:

> Hey all,
>
> As the subject says, whenever I manage to make the tool work I will do
> another batch migration. If you want to avoid the mass mailing, feel free
> to turn off Bugzilla notifications.
>
> The projects on the batch are these
> <https://gitlab.gnome.org/Infrastructure/GitLab/issues?label_name%5B%5D=Migration+request>,
> except those that have the "need evaluation" label.
>
> Cheers
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Strings additions in Nautilus

[Carlos Soriano]

Hello all,

Heads up we introduced a few strings in Nautilus, we added a plugin for
totem entirely inside Nautilus now. The strings are located for videos and
audios in the properties dialog and they are exactly the same as they were
in Totem.

Here's the commit

in case you want to see the added strings.

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

String freeze break in Nautilus stable

[Carlos Soriano]

Hello all,

I recently introduced a commit

with some translatable strings for something we removed in 3.30 and we
added it back now. The strings are for an error message, for an use case
that it's quite obscure (drag and drop image from Epiphany to Nautilus, it
doesn't work with Chrome or such).

The translations should be available in previous versions too, in case you
need to copy paste them or something.

Is this problematic?

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

Re: GitLab minor-reorganization to Community group

[Carlos Soriano]

Yes, Translation are discussing it over now. Not sure what the Foundation
group was about, but for the board we are fine with just a project. Board
will continue as a project, it's what works for us.

On Mon, 24 Sep 2018 at 18:29, Britt Yazel  wrote:

> Carlos,
>
> Excellent! Thank you so much. Under teams the proposal had a few more
> teams listed such as "board" and others. Those have to go through you if
> they want to be added to the "teams" group yes? I don't have anything to do
> with those groups, so I'll let them sort it out, I just want to know for
> clarification
>
> On Mon, Sep 24, 2018 at 9:21 AM Carlos Soriano  wrote:
>
>> This is done now, please check everything is alright.
>>
>> Left to be done:
>> - The translation team, whether they want a group, projects, or something
>> else. To be discussed.
>> - The DeveloperPortal, since they weren't part of the disscussion afaik
>> so I want to double check with them.
>> -  Creating "Marketing" and "Outreach" groups/projects under Engagement.
>> The owners have permissions so they can create them, since I don't know
>> exactly what they will be used for.
>>
>> Cheers
>>
>> On Mon, 24 Sep 2018 at 18:05, Piotr Drąg via desktop-devel-list <
>> desktop-devel-l...@gnome.org> wrote:
>>
>>> 2018-09-23 2:52 GMT+02:00 Petr Kovar :
>>> > On Fri, 14 Sep 2018 10:58:30 +0200
>>> > Andre Klapper  wrote:
>>> >
>>> >> [CC'ing gnome-i18n@]
>>> >>
>>> >> On Mon, 2018-09-10 at 11:46 -0600, Britt Yazel wrote:
>>> >> > There's been an ongoing discussion about reorganizing the
>>> "community"
>>> >> > top level group from containing both our community partner repos
>>> >> > (purism, ubuntu, fedora) as well as a myriad of other repositories.
>>> >> > As of right now, the Community top level is somewhat of a catch-all,
>>> >> > and we have proposed a fix to split Community into both 'Community'
>>> >> > and 'Teams' repositories, with the new 'Teams' top level being where
>>> >> > we will organize all of our Foundation teams, i.e. Engagement,
>>> >> > Design, Translation, Events, etc.
>>> >> [...]
>>> >> >
>>> https://gitlab.gnome.org/Infrastructure/GitLab/issues/294#note_280162
>>> >>
>>> >> Re Translation:
>>> >>
>>> >> It's unclear to me where in Gitlab people are supposed to file bug
>>> >> reports against a translation in a specific language, which would
>>> allow
>>> >> translators of a language to get aware of bugs in their translations.
>>> >>
>>> >> There is a "8. Translation" label at
>>> >> https://gitlab.gnome.org/groups/GNOME/-/labels which allows
>>> subscribing
>>> >> but does not allow differentiating per language. It should probably be
>>> >> renamed to "8. Internationalization" and only be about code which does
>>> >> not allow proper translation; the label description could link to
>>> >> https://wiki.gnome.org/TranslationProject/DevGuidelines .
>>> >>
>>>
>>> +1
>>>
>>> >> Currently there is an "L10N" product in GNOME Bugzilla with
>>> >> subcomponents for each language. Each subcomponent can be watched
>>> >> separately by folks interested in that subcomponent (=language).
>>> >>
>>> >> Maybe some Gitlab setup / ideas already exists that I'm not aware of?
>>> >
>>> > Can we use https://gitlab.gnome.org/Community/Translation and set up
>>> > translation teams as issue labels there?
>>> >
>>> > Alternatively, we could make Community/Translation a group and set up
>>> > languages as individual projects within that team. That could give
>>> teams
>>> > a better control over where and how to submit issues against their
>>> language.
>>> >
>>>
>>> I like the second idea. I opened
>>> https://gitlab.gnome.org/Infrastructure/GitLab/issues/341 to
>>> kick-start the process.
>>>
>>> Best regards,
>>>
>>> --
>>> Piotr Drąg
>>> https://piotrdrag.fedorapeople.org
>>> ___
>>> desktop-devel-list mailing list
>>> desktop-devel-l...@gnome.org
>>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-l...@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: GitLab minor-reorganization to Community group

[Carlos Soriano]

This is done now, please check everything is alright.

Left to be done:
- The translation team, whether they want a group, projects, or something
else. To be discussed.
- The DeveloperPortal, since they weren't part of the disscussion afaik so
I want to double check with them.
-  Creating "Marketing" and "Outreach" groups/projects under Engagement.
The owners have permissions so they can create them, since I don't know
exactly what they will be used for.

Cheers

On Mon, 24 Sep 2018 at 18:05, Piotr Drąg via desktop-devel-list <
desktop-devel-l...@gnome.org> wrote:

> 2018-09-23 2:52 GMT+02:00 Petr Kovar :
> > On Fri, 14 Sep 2018 10:58:30 +0200
> > Andre Klapper  wrote:
> >
> >> [CC'ing gnome-i18n@]
> >>
> >> On Mon, 2018-09-10 at 11:46 -0600, Britt Yazel wrote:
> >> > There's been an ongoing discussion about reorganizing the "community"
> >> > top level group from containing both our community partner repos
> >> > (purism, ubuntu, fedora) as well as a myriad of other repositories.
> >> > As of right now, the Community top level is somewhat of a catch-all,
> >> > and we have proposed a fix to split Community into both 'Community'
> >> > and 'Teams' repositories, with the new 'Teams' top level being where
> >> > we will organize all of our Foundation teams, i.e. Engagement,
> >> > Design, Translation, Events, etc.
> >> [...]
> >> > https://gitlab.gnome.org/Infrastructure/GitLab/issues/294#note_280162
> >>
> >> Re Translation:
> >>
> >> It's unclear to me where in Gitlab people are supposed to file bug
> >> reports against a translation in a specific language, which would allow
> >> translators of a language to get aware of bugs in their translations.
> >>
> >> There is a "8. Translation" label at
> >> https://gitlab.gnome.org/groups/GNOME/-/labels which allows subscribing
> >> but does not allow differentiating per language. It should probably be
> >> renamed to "8. Internationalization" and only be about code which does
> >> not allow proper translation; the label description could link to
> >> https://wiki.gnome.org/TranslationProject/DevGuidelines .
> >>
>
> +1
>
> >> Currently there is an "L10N" product in GNOME Bugzilla with
> >> subcomponents for each language. Each subcomponent can be watched
> >> separately by folks interested in that subcomponent (=language).
> >>
> >> Maybe some Gitlab setup / ideas already exists that I'm not aware of?
> >
> > Can we use https://gitlab.gnome.org/Community/Translation and set up
> > translation teams as issue labels there?
> >
> > Alternatively, we could make Community/Translation a group and set up
> > languages as individual projects within that team. That could give teams
> > a better control over where and how to submit issues against their
> language.
> >
>
> I like the second idea. I opened
> https://gitlab.gnome.org/Infrastructure/GitLab/issues/341 to
> kick-start the process.
>
> Best regards,
>
> --
> Piotr Drąg
> https://piotrdrag.fedorapeople.org
> ___
> desktop-devel-list mailing list
> desktop-devel-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: GitLab minor-reorganization to Community group

[Carlos Soriano]

Since there hasn't been any complains I'm going ahead with Britt
reorganizacion proposal.

Let me know if any issue arises. If permissions are the problem, check the
owners of their respective groups/subgroups/projects and check with them or
fallback to contact me or Andrea Veri.

Cheers

On Sun, 23 Sep 2018 at 02:52, Petr Kovar  wrote:

> On Fri, 14 Sep 2018 10:58:30 +0200
> Andre Klapper  wrote:
>
> > [CC'ing gnome-i18n@]
> >
> > On Mon, 2018-09-10 at 11:46 -0600, Britt Yazel wrote:
> > > There's been an ongoing discussion about reorganizing the "community"
> > > top level group from containing both our community partner repos
> > > (purism, ubuntu, fedora) as well as a myriad of other repositories.
> > > As of right now, the Community top level is somewhat of a catch-all,
> > > and we have proposed a fix to split Community into both 'Community'
> > > and 'Teams' repositories, with the new 'Teams' top level being where
> > > we will organize all of our Foundation teams, i.e. Engagement,
> > > Design, Translation, Events, etc.
> > [...]
> > > https://gitlab.gnome.org/Infrastructure/GitLab/issues/294#note_280162
> >
> > Re Translation:
> >
> > It's unclear to me where in Gitlab people are supposed to file bug
> > reports against a translation in a specific language, which would allow
> > translators of a language to get aware of bugs in their translations.
> >
> > There is a "8. Translation" label at
> > https://gitlab.gnome.org/groups/GNOME/-/labels which allows subscribing
> > but does not allow differentiating per language. It should probably be
> > renamed to "8. Internationalization" and only be about code which does
> > not allow proper translation; the label description could link to
> > https://wiki.gnome.org/TranslationProject/DevGuidelines .
> >
> > Currently there is an "L10N" product in GNOME Bugzilla with
> > subcomponents for each language. Each subcomponent can be watched
> > separately by folks interested in that subcomponent (=language).
> >
> > Maybe some Gitlab setup / ideas already exists that I'm not aware of?
>
> Can we use https://gitlab.gnome.org/Community/Translation and set up
> translation teams as issue labels there?
>
> Alternatively, we could make Community/Translation a group and set up
> languages as individual projects within that team. That could give teams
> a better control over where and how to submit issues against their
> language.
>
> My 5¢.
>
> Cheers,
> pk
> ___
> desktop-devel-list mailing list
> desktop-devel-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

[nautilus] Created branch gnome-3-30

[Carlos Soriano]

The branch 'gnome-3-30' was created pointing to:

 efef783... Revert "icon: update app icon"

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

Re: Git access for translators

[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: Git access for translators

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

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

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

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: Git access for translators

[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

Git access for translators

[Carlos Soriano]

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

Re: Release notes translation

[Carlos Soriano]

Ok cool, I added it to the members now.

Piotr, you have developer access too, feel free to add/remove users as
needed, but I guess it shouldn't be necessary anymore right?

On Mon, 3 Sep 2018 at 02:08, Piotr Drąg  wrote:

> 2018-09-02 23:44 GMT+02:00 Carlos Soriano :
> > What's the username of the translations bot?
> >
>
> It’s @translations. I see we’ve reported this issue in every
> conceivable place. :)
>
> https://gitlab.gnome.org/Community/Engagement/release-notes/issues/6
>
> --
> Piotr Drąg
> https://piotrdrag.fedorapeople.org
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Release notes translation

[Carlos Soriano]

What's the username of the translations bot?

On Sun, 2 Sep 2018 at 22:54, Claude Paroz  wrote:

> Le 02. 09. 18 à 22:24, Alexandre Franke a écrit :
> > On Sun, Sep 2, 2018 at 10:10 PM Aurimas Cernius via gnome-i18n
> > mailto:gnome-i18n@gnome.org>> wrote:
> >
> > Hi,
> >
> >
> > Hi,
> >
> > Starting today I cannot push translations for release notes. Have I
> > missed some update recently?
> >
> >
> > When did you last try? There was an issue with permissions because the
> > repository changed locations but Carlos changed settings and that may
> > have fixed it.
>
> I still don't see the translations user on:
> https://gitlab.gnome.org/Community/Engagement/release-notes/project_members
>
> Claude
> --
> www.2xlibre.net
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Modules out of GNOME tag in GitLab

[Carlos Soriano]

Yeah, I agree the translators tools should learn how to deal with different
GitLab groups... this will be quite useful soon when Engagement group has
also projects that translators at GNOME wants to help translating with.

Let me know if you have any questions about that.

On Thu, 31 May 2018 at 13:31, Piotr Drąg  wrote:

> 2018-05-31 13:21 GMT+02:00 Carlos Soriano :
> > Hey Daniel,
> >
> > library-web and others are infrastructure projects, so they are handled
> > differently on purpose.
> >
> > Fractal is not a GNOME app, so it's not in GNOME/. Ideally they would
> be...
> > but I don't think they started the process for that yet, if any.
> >
> > Moving them to the non-GNOME section in dammed-lies looks like the proper
> > solution.
> >
>
> Hi,
>
> Infrastructure projects are still GNOME projects, so that leaves us
> with only Fractal as a non-GNOME project. I don’t think creating a new
> release set for just one module is worth it, and I do hope Fractal
> will move to GNOME/ soon. Additionally, it being in a different group
> on GitLab shouldn’t change anything in the standard translator
> workflow. I’m sorry if you needed to make any changes in your
> scripting and automation — had I known, I would definitely notify you
> earlier.
>
> 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: Modules out of GNOME tag in GitLab

[Carlos Soriano]

Hey Daniel,

library-web and others are infrastructure projects, so they are handled
differently on purpose.

Fractal is not a GNOME app, so it's not in GNOME/. Ideally they would be...
but I don't think they started the process for that yet, if any.

Moving them to the non-GNOME section in dammed-lies looks like the proper
solution.

Cheers

On Thu, 31 May 2018 at 13:19, Daniel Mustieles García <
daniel.mustie...@gmail.com> wrote:

> Hi all,
>
> Rafael Fontenelle has noticed that in GitLab there are several modules not
> in ":GNOME". (*library-web* and *gnome-web-www* in :Infrastructure
>  and *fractal* in :World, for
> example). 
>
> This might break scripts like gttk.sh
> , (used
> to commit PO files into Git) and many other scripts doing a git clone.
>
> My question is why this modules are out of the :GNOME tag and if they
> could be included into it to avoid this kind of issues. Another posibility
> could be move this modules from their current Damned Lies categories to the
> No GNOME section, so translators can notice this modules don't follow the
> official workflow (whatever it mean in every case ;-) )
>
> Regards
>
>
> 
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

[nautilus] Created branch gnome-3-28

[Carlos Soriano]

The branch 'gnome-3-28' was created pointing to:

 ee55096... Update Swedish translation

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

Nautilus: String adition

[Carlos Soriano]

We added two strings in Nautilus:

   1.
   
https://gitlab.gnome.org/GNOME/nautilus/blob/master/src/nautilus-window.c#L1812
   2.
   
https://gitlab.gnome.org/GNOME/nautilus/blob/master/src/nautilus-window.c#L1818

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

Re: Updating translations on GItlab

[Carlos Soriano]

Hey all,

If you want to use git access instead of dammed lies you need to log in at
least once in GitLab with your LDAP account. Once that happens you will
receive developer access, in the time frame of one hour since the first
login.

Cheers,
Carlos Soriano

On Sun., 4 Feb. 2018, 19:28 Aurimas Cernius, <auri...@gmail.com> wrote:

> > I’m lost. I’ve added Carlos to CC, he should know more.
>
> I got an email about receiving Developer access to GNOME group, now
> everything work.
> Whoever did that, thank you!
>
> --
> Aurimas
>
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Translation Context for sort in czech

[Carlos Soriano]

Thanks Rafal, that makes it clear then.

Again thanks all for the answers!

Carlos Soriano
GNOME Board of Directors

On Fri, Jan 19, 2018 at 10:57 PM, Rafal Luzynski <
digitalfr...@lingonborough.com> wrote:

> Marek's descriptions look perfect as the translators' comments but it's
> obviously too long for a context identifier. I suggest e.g. "menu item"
> and "preferences" or "preference option". So this could look like:
>
>  context="preferences"
> comments="Translators: An option group label in a Preferences dialog
> with
> option Sort folders before files."
> translatable="yes">Sort
>
>  context="menu item"
> comments="Translators: A menu item group in a toolbar menu with the
> sort
> criterions as A-Z or Last Modified."
> translatable="yes">Sort
>
> Please take this as an example and adjust because I have not analyzed
> the project in details. Also apply your formatting. Note that using
> the entities like  and starting the comment with "Translators:"
> is obligatory.
>
> Regards,
>
> Rafal
>
>
> 19.01.2018 15:18 Marek Černocký <ma...@manet.cz> wrote:
> >
> >  Please use an usecase description. E.g.:
> >  "An option group label in a Preferences dialog with option 'Sort folders
> > before files'."
> >  "A menu item group in a toolbar menu with the sort criterions as 'A-Z'
> or
> > 'Last Modified'."
> >
> >  Reagards
> >  Marek Černocký
> >
> >
> >  Carlos Soriano píše v Pá 19. 01. 2018 v 10:45 +0100:
> >> >Thanks Rafal, Petr for the answer,
> > >
> > >It's still confusing to me what I should in the code then, if
> context
> > > "verb" or "noun" it's not enough. Just to clarify, I'm not the
> translator.
> > >
> > >What should we put in the context at the code to fix this issue for
> all
> > > languages?
> > >
> > >Cheers
> > >
> > >On Thu, Jan 18, 2018 at 11:25 PM, Rafal Luzynski
> > > <digitalfr...@lingonborough.com mailto:digitalfr...@lingonborough.com
> >
> > > wrote:
> > >  > > > 18.01.2018 14:03 Petr Kovar <pmko...@gnome.org
> > >  > > > mailto:pmko...@gnome.org > wrote:
> > > >  >
> > > >  >
> > > >  > On Thu, 18 Jan 2018 13:50:02 +0100
> > > >  > Carlos Soriano <csori...@gnome.org mailto:csori...@gnome.org
> >
> > > >  > wrote:
> > > >  >
> > > >  > > Hey all,
> > > >  > >
> > > >  > > I asked Rahul to send an email because we couldn't figure
> out
> > > >  > > what is the
> > > >  > > problem in Czech for the word "Sort" that is explained in
> that
> > > >  > > issue. Do
> > > >  > > any Czech person (Andre? :P) understand the problem
> explained in
> > > >  > > the issue
> > > >  > > and what context does it require for Czech people to be
> able to
> > > >  > > translate
> > > >  > > it properly?
> > > >  > >
> > > >  > > In case you need to check in the actual UI of Nautilus, the
> two
> > > >  > > uses of the
> > > >  > > word Sort are (Nautilus 3.26):
> > > >  > > 1- Preferences -> Views -> Sort
> > > >  > > 2- Hamburguer menu -> Sort (as title of one of the menu
> sections)
> > > >  >
> > > >  > Just a wild guess: the former could be translated as a noun
> > > >  > (třídění) while
> > > >  > the latter as a verb (třídit).
> > > >  >
> > > >  > "When marking strings for translations, there may be certain
> > > >  > strings that
> > > >  > are used in more than one context, and so may need different
> > > >  > translations.
> > > >  > In these cases, you should use translation contexts to
> disambiguate
> > > >  > them. "
> > > >  >
> > > >  > https://wiki.gnome.org/TranslationProject/
> DevGuidelines/Translation%20contexts
> > > >
> > > >  TLDR: In case of a doubt it's better to split.
> > > >
> > > >  Full

Re: Translation Context for sort in czech

[Carlos Soriano]

Thanks Rafal, Petr for the answer,

It's still confusing to me what I should in the code then, if context
"verb" or "noun" it's not enough. Just to clarify, I'm not the translator.

What should we put in the context at the code to fix this issue for all
languages?

Cheers

On Thu, Jan 18, 2018 at 11:25 PM, Rafal Luzynski <
digitalfr...@lingonborough.com> wrote:

> 18.01.2018 14:03 Petr Kovar <pmko...@gnome.org> wrote:
> >
> >
> > On Thu, 18 Jan 2018 13:50:02 +0100
> > Carlos Soriano <csori...@gnome.org> wrote:
> >
> > > Hey all,
> > >
> > > I asked Rahul to send an email because we couldn't figure out what is
> the
> > > problem in Czech for the word "Sort" that is explained in that issue.
> Do
> > > any Czech person (Andre? :P) understand the problem explained in the
> issue
> > > and what context does it require for Czech people to be able to
> translate
> > > it properly?
> > >
> > > In case you need to check in the actual UI of Nautilus, the two uses
> of the
> > > word Sort are (Nautilus 3.26):
> > > 1- Preferences -> Views -> Sort
> > > 2- Hamburguer menu -> Sort (as title of one of the menu sections)
> >
> > Just a wild guess: the former could be translated as a noun (třídění)
> while
> > the latter as a verb (třídit).
> >
> > "When marking strings for translations, there may be certain strings that
> > are used in more than one context, and so may need different
> translations.
> > In these cases, you should use translation contexts to disambiguate
> them. "
> >
> > https://wiki.gnome.org/TranslationProject/DevGuidelines/Translation%
> 20contexts
>
> TLDR: In case of a doubt it's better to split.
>
> Full explanation. A split translation term should also contain translators
> comments to explain why it is split and what is the difference between the
> meanings. "This is in a preference window" and "This is in a toolbar view
> menu" is not enough; it must be explained what is its role in a preference
> window and in a menu. Those two lines:
>
> > 1- Preferences -> Views -> Sort
> > 2- Hamburguer menu -> Sort (as title of one of the menu sections)
>
> look better. "Verb" and "noun" as the context name is also not good and
> can be misleading, some languages may use a different scheme than Czech
> and sooner or later you will get a complaint from an XX translator saying
> "The noun does not fit here in my language, please change" or "My language
> does not have infinite verbs, what should I do?" :-)
>
> In case of a doubt in the meaning in English it is also good to check how
> other languages similar to your own have solved this problem, for example
> Polish: [1]
>
> #: src/resources/ui/nautilus-preferences-window.ui:44
> #: src/resources/ui/nautilus-toolbar-view-menu.ui:98
> msgid "Sort"
> msgstr "Porządkowanie"
>
> So this is twice a noun (like Czech "Třídění"). I understand that for a
> menu
> item and other commands you'd like a verb, maybe in an infinitive form
> ("Třídit"), maybe in an imperative form (hm... I don't know how to say it
> in Czech). But the other day I saw translation guidelines for Polish
> translations (I can't find the link now) which said that we should avoid
> personal verbs ("Please copy" or "I'm copying") and use impersonal nouns
> ("[The] Copy", "Copying in progress") because computers are not humans and
> we should not give the users an impression that they are talking to
> computers.
> Maybe you should adopt the same in Czech language as well and use "Třídění"
> in both cases?
>
> Regards,
>
> Rafal
>
>
> [1] https://gitlab.gnome.org/GNOME/nautilus/blob/master/po/pl.po
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Translation Context for sort in czech

[Carlos Soriano]

Hey all,

I asked Rahul to send an email because we couldn't figure out what is the
problem in Czech for the word "Sort" that is explained in that issue. Do
any Czech person (Andre? :P) understand the problem explained in the issue
and what context does it require for Czech people to be able to translate
it properly?

In case you need to check in the actual UI of Nautilus, the two uses of the
word Sort are (Nautilus 3.26):
1- Preferences -> Views -> Sort
2- Hamburguer menu -> Sort (as title of one of the menu sections)

Cheers

On Thu, Jan 18, 2018 at 1:42 PM, Andre Klapper  wrote:

> On Thu, 2018-01-18 at 17:47 +0530, Rahul Verma wrote:
> > In this issue
> > https://gitlab.gnome.org/GNOME/nautilus/issues/151
> >
> > what is the context of word (Czech) used in two files .
> > i.e context="verb" or context="noun"
>
> I'm afraid you'd need to ask Nautilus developers (who put that string
> into place) or look at the Nautilus code yourself, instead of asking
> other translators. :)
>
> andre
> --
> Andre Klapper  |  ak...@gmx.net
> http://blogs.gnome.org/aklapper/
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

[nautilus] Created branch gnome-3-26

[Carlos Soriano]

The branch 'gnome-3-26' was created pointing to:

 1cdbecd... Revert "toolbar: Add explanatory tooltips to buttons"

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

Re: Still unable to push to nautilus gitlab

[Carlos Soriano]

Hey Alexander,

Not sure why this happened to you, you don't need any changes to continue
contributing to Nautilus since the repos are redirected. I can see in your
output you have a mix of remotes and some bad set up ones.

If you need help, join #sysadmin in irc.gnome.org and we can help there to
set up your remotes properly.

Best
--
Carlos Soriano
GNOME Foundation <https://www.gnome.org/foundation/>
Treasurer, Board of Directors

On Wed, Sep 6, 2017 at 5:09 PM, Alexander Shopov <li...@kambanaria.org>
wrote:

> Hi all,
> I am still not able to merge the updated Bulgarian translation of nautilus.
>
> *cd GNOME/nautilus; git remote -vv *
> httpshttps://gitlab.gnome.org/GNOME/nautilus.git (fetch)
> httpshttps://gitlab.gnome.org/GNOME/nautilus.git (push)
> origingit://git.gnome.org/nautilus (fetch)
> originssh://al_sho...@git.gnome.org/git/nautilus (push)
> sshg...@gitlab.gnome.org:GNOME/nautilus.git (fetch)
> sshg...@gitlab.gnome.org:GNOME/nautilus.git (push)
>
> *git push origin *
> says the repo does not exist
>
> *git push ssh*
> GitLab: You are not allowed to push code to this project.
> fatal: Could not read from remote repository.
> Please make sure you have the correct access rights
> and the repository exists.
>
> *git push https*
> Username for 'https://gitlab.gnome.org': al_shopov
> Password for 'https://al_sho...@gitlab.gnome.org':# Paste the
> https://gitlab.gnome.org/profile/personal_access_tokens token here
> remote: You are not allowed to push code to this project.
> fatal: unable to access 'https://gitlab.gnome.org/GNOME/nautilus.git/':
> The requested URL returned error: 403
>
> What am I missing to get rights to push?
>
> Kind regards:
> al_shopov
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Events for translators

[Carlos Soriano]

On Mon., 3 Jul. 2017, 13:56 Alexandre Franke, <afra...@gnome.org> wrote:

> On Mon, Jul 3, 2017 at 1:09 PM, Carlos Soriano <csori...@gnome.org> wrote:
> >> There is a table on the wiki page. Coordinator satisfaction can depend
> >> on a number of criteria and should be defined on a per event basis.
> >
> > Inside the wide satisfaction level, could it be a more or less standard?
> As
> > in, maybe 100 strings of quality translated? It's just to give some very
> > basic guidelines, to avoid an event report like "yeah they learnt
> > something".
>
> Did you read the page? The table and agenda address that question.
>

I did. I don't feel that answers my question though...


> > Is the general guide I linked before good enough as a basic
> > guideline for someone that wants to organise such event?
>
> Not really. First of all that is not what that page is for (it’s
> information for people from the outside trying to join, not community
> members trying to organize an event) and second of all this page needs
> to be revamped (as many of the pages in that namespace).
>

Oh I mean as a kind of tutorial for the atendees, to avoid following some
workflow that is not expected (i.e. this happened "how to build GNOME" and
resulted in not so great experience)


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

Re: Events for translators

[Carlos Soriano]

On Mon, Jul 3, 2017 at 12:42 PM, Alexandre Franke <afra...@gnome.org> wrote:

> On Mon, Jul 3, 2017 at 11:23 AM, Carlos Soriano <csori...@gnome.org>
> wrote:
> > Hello all,
>
> Hi,
>
> > One of the ideas is a "Translation race" event. Basically various people
> get
> > together to learn how to translate and translate some module with some of
> > you.
>
> I organized [such an event in
> 2014](https://wiki.gnome.org/Hackfests/LeTranslathon2014). It was on a
> weekend at the Mozilla office space in Paris and it was very
> successful. The wiki page addresses many of your questions.
>

Cool, that's helpful.


>
> > - What items would be interesting for you? (e.g. stickers, some cake,
> > snacks,)
>
> The two most important items are a venue (which can usually be
> provided for free or sponsored by a third party) and transportation
> for the experienced contributors to ensure they will be able to come
> and guide the other attendees. After that, I’d invest in food, not
> swag.
>

Noted


>
> > - How many people could a single organiser handle in a comfortable way?
>
> I’d say around 5 newcomers per experienced translator.
>

Noted


>
> > - Do you think "translated one module per person" is doable in that time
> and
> > a good way to measure the success of the event? If not, what do you
> propose
> > as a measurement of success of the event?
>
> There is a table on the wiki page. Coordinator satisfaction can depend
> on a number of criteria and should be defined on a per event basis.
>

Inside the wide satisfaction level, could it be a more or less standard? As
in, maybe 100 strings of quality translated? It's just to give some very
basic guidelines, to avoid an event report like "yeah they learnt
something".


>
> > - Coordinators bureocracy is difficult and will delay the process
>
> If people create their accounts together at the beginning of the event
> while the organizer walks them through the steps, it should take about
> 10 minutes before someone is able to contribute. I don’t think it’s
> any more difficult or longer than the process of getting your first
> patch ready for review.
>
>
Right.


> > - Each team has its own guidelines
>
> Yes and I expect this to remain the case. Translation teams have to
> integrate in the GNOME community, but they also have to take the
> language community into account. The French team for GNOME
> collaborates with the translators of LibreOffice, KDE, Ubuntu, Fedora…
>

Indeed. Is the general guide I linked before good enough as a basic
guideline for someone that wants to organise such event?


>
> Cheers,
>
> --
> Alexandre Franke
> GNOME Hacker & Foundation Director
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Events for translators

[Carlos Soriano]

Hello Daniel,

Thanks for your input! Your main two points are interesting:
- Coordinators bureocracy is difficult and will delay the process
- Each team has its own guidelines

For the first point I think is good enough if the organizers review the
patches and explain the process that will go through with yhe coordinators
later on.
For the second point, do you think the main wiki is good enough as general
guide? I guess we can use that one as main source, but allow local teams to
do slightly modifications in the event based on the local guidelines.

About doing it on remote, what do you mean? This event on remote would be
just a videocall  right? In that case what would th foundation do to help?
The items we were proposing were all for in person events (stickers,
snacks, some cash)

Best,
Carlos Soriano

On Mon., 3 Jul. 2017, 11:51 Daniel Mustieles García, <
daniel.mustie...@gmail.com> wrote:

> Hi!
>
> This is a good idea, since translations is sometimes a forgotten side of
> the Project (at least for the Spanish team, don't know about other teams),
> and this initiative could be interesting for those who want collaborate
> with translation tasks.
>
> Start translating a module is more or less easy... just set up a
> translation program, download the PO file and start translating (and
> reading previous translations to learn about terms, tags, etc). The main
> obstacle might be the burocracy around a translation team, since there are
> not standar ways to manage them. In the case of the Spanish team, we have
> some guidelines about our internal management which might be difficult to
> understand and follow in a first stage.
>
> So, first of all, I would think about an standar way to manage the
> workflow of the event (send the translation, review it, comit into git,
> etc). This would imply to coordinate all team coordinators interested in
> the event.
>
> About the measure of the success... it's difficult to say, since IMHO
> quality is better then quantity, so just translating one module, but
> without errors is better for me than translating 5 modules with typos os
> grammatical errors. This should be decided by team
> coordinators/proofreaders.
>
> For this event, I would choose general, non-specific modules (GIMP for
> example should not be a good candidate, unless there is someone specialized
> on it). Again, team coordinators should choose the modules they think are
> more suitable for it, ow which modules need more attention.
>
> In my case, I would like to participate/support this event for the Spanish
> people interested on it. Will it be possible to do it remotely?
>
> My 2cents ;-)
>
> Cheers!
>
> 2017-07-03 11:23 GMT+02:00 Carlos Soriano <csori...@gnome.org>:
>
>> Hello all,
>>
>> Lately we have been trying to define what events GNOME can sponsor and
>> how. You can read more in the wiki [0]
>>
>> One of the ideas is a "Translation race" event. Basically various people
>> get together to learn how to translate and translate some module with some
>> of you.
>>
>> However I need a little of help to figure out how that event could be.
>> The questions I have are:
>> - How much time do you think it would take to set up, teach and translate
>> a module?
>> - What items would be interesting for you? (e.g. stickers, some cake,
>> snacks,)
>> - How many people could a single organiser handle in a comfortable way?
>> - Do you think "translated one module per person" is doable in that time
>> and a good way to measure the success of the event? If not, what do you
>> propose as a measurement of success of the event?
>> - Do you have a canonical guide an orgnizer should follow and make the
>> people follow? (similar to /Newcomers). Is
>> https://wiki.gnome.org/TranslationProject/JoiningTranslation the one?
>> - Any other point we should take into account?
>>
>> [0] https://wiki.gnome.org/Engagement/Events
>>
>> ___
>> 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

Events for translators

[Carlos Soriano]

Hello all,

Lately we have been trying to define what events GNOME can sponsor and how.
You can read more in the wiki [0]

One of the ideas is a "Translation race" event. Basically various people
get together to learn how to translate and translate some module with some
of you.

However I need a little of help to figure out how that event could be. The
questions I have are:
- How much time do you think it would take to set up, teach and translate a
module?
- What items would be interesting for you? (e.g. stickers, some cake,
snacks,)
- How many people could a single organiser handle in a comfortable way?
- Do you think "translated one module per person" is doable in that time
and a good way to measure the success of the event? If not, what do you
propose as a measurement of success of the event?
- Do you have a canonical guide an orgnizer should follow and make the
people follow? (similar to /Newcomers). Is
https://wiki.gnome.org/TranslationProject/JoiningTranslation the one?
- Any other point we should take into account?

[0] https://wiki.gnome.org/Engagement/Events
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

[zenity] Created branch gnome-3-18

[Carlos Soriano]

The branch 'gnome-3-18' was created pointing to:

 c2ac30a... Bump to 3.18.0

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

[nautilus] Created branch gnome-3-24

[Carlos Soriano]

The branch 'gnome-3-24' was created pointing to:

 80d796b... Updated Ukrainian translation

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

[zenity] Created branch gnome-3-22

[Carlos Soriano]

The branch 'gnome-3-22' was created pointing to:

 20aa119... release: prepare for 3.22.0

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

[zenity] Created branch gnome-3-20

[Carlos Soriano]

The branch 'gnome-3-20' was created pointing to:

 668bbf0... Bump to 3.20.0

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

[zenity] Created branch gnome-3-18

[Carlos Soriano]

The branch 'gnome-3-18' was created pointing to:

 0b990c5... release: Prepare for 3.24.0

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

String addition to file-roller

[Carlos Soriano via gnome-i18n]

Hello translation team,

I just pushed some string additions to file roller and will make the .91 
release now.
The string is the nautilus extension, and they are:
Extract Here
Extract the selected archive to the current position
Extract To...
Extract the selected archive
Compress...
Create a compressed archive with the selected objects

Hope it's fine being officially in string freeze but without the .91 release 
done in file-roller (I know it's not an excuse, but wanted to push as soon as 
possible to not be so far from official string freeze).



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

[nautilus] Created branch gnome-3-22

[Carlos Soriano]

The branch 'gnome-3-22' was created pointing to:

 ce0c0bb... release: prepare for 3.22.1

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

String addition in gtk+

[Carlos Soriano]

Hello,

There was a string not marked for translation. Specifically, in 
gtkplacesview.ui:
"ftp:// or ftps://"

Since this is a forgotten string, the string freeze break exception is 
automatically accepted and I just marked for translation and pushed the fix for 
gtk+ and Nautilus.
Bug report: https://bugzilla.gnome.org/show_bug.cgi?id=771666



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

Strings addition on Nautilus

[Carlos Soriano Sanchez]

Hello,

I'm going to add few strings to Nautilus. Yesterday I realized there are few 
constants that were not marked as translation, so this will be an addition 
rather than a change. The freeze exception rules state that this is 
automatically approved since these strings were already in the code, but not 
marked as translated.

The strings are:
Camera model
Creation date
Season number
Episode number
Track number
Artist name
Album name
Title
Original file name

They are located in src/batch-batch-rename-dialog.h

Best regards,
Carlos Soriano

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

[gnome-autoar] Created branch gnome-3-22

[Carlos Soriano Sánchez]

The branch 'gnome-3-22' was created pointing to:

 40ebefe... Fix a typo in doap file

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

Re: Nautilus string changes

[Carlos Soriano Sanchez]

Hey Marek,

Thanks for reporting. We changed this a few hours ago, is it ok for you now?

Regards,
Carlos Soriano

- Original Message -
| Some of this new strings have some problems:
| 
| "Extract %d files" - required ngettext for plural forms
| "Compress '%d' files" - required ngettext for plural forms and remove
| single quotes
| "Delete %d extracted files" - required ngettext for plural forms
| 
| Best regards
| Marek Černocký
| 
| 
| Dne 23.8.2016 11:07, Carlos Soriano Sanchez napsal:
| > Hello teams,
| > 
| > Yesterday we merged code to Nautilus that incorporated 46 new strings.
| > Sorry for not sending a warning beforehand.
| > 
| > Also we are planning to merge another piece of work in the upcoming
| > days in Nautilus, that will incorporate more new strings. We will
| > announce when that happens.
| > 
| > Best regards,
| > 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

Nautilus string changes

[Carlos Soriano Sanchez]

Hello teams,

Yesterday we merged code to Nautilus that incorporated 46 new strings. Sorry 
for not sending a warning beforehand.

Also we are planning to merge another piece of work in the upcoming days in 
Nautilus, that will incorporate more new strings. We will announce when that 
happens.

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

Branch 3.20 of nautilus it's not freezed

[Carlos Soriano Sanchez]

Hello,

I needed to branch 3.20 to be able to perform some code changes that I don't 
want to be in 3.20.
I was unsure if either use a wip/next branch or just branch 3.20 already, and I 
went with the later choice.
The gnome-3-20 in nautilus is not freezed yet neither in UI or strings, so 
expect to be more changes there (actually just received some strings 
improvements requests from Piotr).

Sorry for the inconveniences to cherry-pick from master to 3.20 now.

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

[nautilus] Created branch gnome-3-20

[Carlos Soriano Sánchez]

The branch 'gnome-3-20' was created pointing to:

 3e9238d... toolbar: don't show operations popover in desktop

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

Re: String additions to 'nautilus.gnome-3-18'

[Carlos Soriano Sanchez]

ups sorry, going to revert now. I wanted to use the already in use "New Window" 
string.
I guess if I use this one is okay right?
- Original Message -
| 2015-11-12 21:49 GMT+01:00 GNOME Status Pages :
| > This is an automatic notification from status generation scripts on:
| > http://l10n.gnome.org.
| >
| > There have been following string additions to module 'nautilus.gnome-3-18':
| >
| > + "Open a New Window"
| >
| 
| Hi Carlos,
| 
| Your commit
| 
https://git.gnome.org/browse/nautilus/commit/?h=gnome-3-18=3e873d5c7c6a2062a219141feacb5606d6620a72
| broke the string freeze. Please revert it. You can ask for an
| exception later, if you think it's *absolutely* necessary (it's
| unlikely to get approved so late in the 3.18 cycle).
| 
| https://wiki.gnome.org/TranslationProject/HandlingStringFreezes
| 
| Best regards,
| 
| --
| Piotr Drąg
| http://raven.fedorapeople.org/
| 
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: String additions to 'nautilus.gnome-3-18'

[Carlos Soriano Sanchez]

Argh, bummer. Patch reverted from 3.18, I guess just for 3.20 then...

Thanks for the heads up.

- Original Message -
| 2015-11-12 22:15 GMT+01:00 Carlos Soriano Sanchez <csori...@redhat.com>:
| > ups sorry, going to revert now. I wanted to use the already in use "New
| > Window" string.
| > I guess if I use this one is okay right?
| 
| It would be, but there is no "New Window" string in Nautilus. You're
| probably thinking of "New _Window", which is unfortunately different.
| 
| Best regards,
| 
| --
| Piotr Drąg
| http://raven.fedorapeople.org/
| 
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

[nautilus] Created branch gnome-3-18

[Carlos Soriano Sánchez]

The branch 'gnome-3-18' was created pointing to:

 21f23b8... release: prepare for 3.18.1

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

Re: UI freeze exception

[Carlos Soriano Sanchez]

Thanks everyone!

- Original Message -
| Second i18n approval
| 
| Cheers!
| 
| 2015-09-02 18:00 GMT+02:00 Andre Klapper <ak...@gmx.net>:
| 
| > On Tue, 2015-09-01 at 15:57 -0400, Carlos Soriano Sanchez wrote:
| > > Even if it is late, I would like to ask for an UI freeze exception
| > > for https://bugzilla.gnome.org/show_bug.cgi?id=725939
| > > The reason is that GtkFileChooser implemented it, but nautilus
| > > didn't. One of the points for 3.18 was to make consistent
| > > the behavior between GtkFileChooser and Nautilus, and this is the
| > > last important item remaining.
| > >
| > > Basically it adds an action bar when a search is performed in some
| > > remote location, indicating the user that the search is
| > > being done non recursively. Here a screenshot:
| >
| > Makes sense so this is one r-t approval.
| >
| > andre
| > --
| > Andre Klapper  |  ak...@gmx.net
| > http://blogs.gnome.org/aklapper/
| >
| >
| > ___
| > gnome-i18n mailing list
| > gnome-i18n@gnome.org
| > https://mail.gnome.org/mailman/listinfo/gnome-i18n
| >
| 
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: UI freeze exception

[Carlos Soriano Sanchez]

Thanks for the response, ccing gnome-i18n as recommended.

- Original Message -
| ​I may be biased by having implemented this in the file chooser, but I am
| in favor of taking this (keeping the file chooser and nautilus in sync was
| one of the major themes of the work in those places this cycle, after all).
| You should cc gnome-i18n though, since this adds new strings to nautilus
| (even though they can be copied from GTK+ - right ?)
|
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: String additions to 'nautilus.gnome-3-16'

[Carlos Soriano Sanchez]

Thanks.
I don't have any rush for a 3.16.3 from my side,
so I prefer to wait as long as need to have some translations.

Regards
Carlos Soriano

- Original Message -
| 2015-07-02 18:01 GMT+02:00 Carlos Soriano Sanchez csori...@redhat.com:
|  Hi,
| 
|  Sorry for that, I though it was an old translation, but it's true we
|  changed how we displayed
|  those items in 3.16.
| 
|  Should I revert and then ask for string exception? Or just ask for string
|  exception now?
| 
| 
| Let's bend the rules a little: here is 1/2 from i18n.
| 
| Can we hope for a 3.16.3 next week? It'd be nice to have two weeks for
| translators, but I understand if you don't want to wait that long.
| 
| Best regards,
| 
| --
| Piotr Drąg
| http://raven.fedorapeople.org/
| 
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: String additions to 'nautilus.gnome-3-16'

[Carlos Soriano Sanchez]

Hi,

Sorry for that, I though it was an old translation, but it's true we changed 
how we displayed
those items in 3.16.

Should I revert and then ask for string exception? Or just ask for string 
exception now?

Carlos Soriano

- Original Message -
| 2015-07-01 20:03 GMT+02:00 Debarshi Ray rishi...@lostca.se:
|  To be fair, this restores an old string and actually fixes what some
|  might consider a regression in 3.16.x. It should be possible to somehow
|  restore the old translations too.
| 
| 
| This particular string (every character matters!) was never used in
| Nautilus (I've checked every version since 3.0). As you can see, it
| caused a regression in translation coverage for every language:
| 
| https://l10n.gnome.org/module/nautilus/#gnome-3-16
| 
| To make it worse, this string is very visible to the user.
| 
| If you can restore the translations, then everything would be fine.
| I'm skeptical, though - you'd need to take care of proper mnemonics,
| capitalization etc, all of which vary greatly among languages.
| 
| Please also note that string change fixing a regression has a very
| high chance of getting a quick approval. Especially if you promise to
| make a new release (let's say) a week from now, so translators have
| time to update their translations and can count on getting it in the
| next release.
| 
| Best regards,
| 
| --
| Piotr Drąg
| http://raven.fedorapeople.org/
| 
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

Nautilus string exception

[Carlos Soriano Sanchez]

Hi,

I would like to introduce two string exceptions for Nautilus to fix some bugs 
for 3.16.
- _Delete Permanently in nautilus-view-context-menus for systems that does 
not support trash. Bug report https://bugzilla.gnome.org/show_bug.cgi?id=748692
- _Remove from Recent in nautilus-view-context-menus since we removed it 
accidentally for 3.16. Bug report 
https://bugzilla.gnome.org/show_bug.cgi?id=746392

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

Re: Nautilus string exception

[Carlos Soriano Sanchez]

I retire this petition, talked on IRC with Mathias and this is bad since no 
translation is yet done and they are menu items, which are prominent.

We will try for .3

Cheers,
Carlos Soriano
- Original Message -
From: Carlos Soriano Sanchez csori...@redhat.com
To: gnome-i18n@gnome.org, release-t...@gnome.org, gnome-doc-l...@gnome.org
Sent: Wednesday, 13 May, 2015 3:01:49 PM
Subject: Nautilus string exception

Hi,

I would like to introduce two string exceptions for Nautilus to fix some bugs 
for 3.16.
- _Delete Permanently in nautilus-view-context-menus for systems that does 
not support trash. Bug report https://bugzilla.gnome.org/show_bug.cgi?id=748692
- _Remove from Recent in nautilus-view-context-menus since we removed it 
accidentally for 3.16. Bug report 
https://bugzilla.gnome.org/show_bug.cgi?id=746392

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

[nautilus] Created branch gnome-3-16

[Carlos Soriano Sánchez]

The branch 'gnome-3-16' was created pointing to:

 f0a17d6... Revert view: show New Folder dialog

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

Nautilus brake string freeze

[Carlos Soriano Sánchez]

Hi all,

A11y people wanted https://bugzilla.gnome.org/show_bug.cgi?id=745967  fixed
for 3.16, and I wanted that fix for the .90 I will do in a few hours.

I fixed it, but also, I pushed without asking for string freeze break (I
forgot about the string freeze).
The commit is
https://git.gnome.org/browse/nautilus/commit/?id=7afbac0a64f1734842ed64e333c9147de1cdbcd9

Sorry for that

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

Re: Nautilus brake string freeze

[Carlos Soriano Sánchez]

Thanks

On Wed, 11 Mar 2015 14:55 Daniel Mustieles García 
daniel.mustie...@gmail.com wrote:

 2/2 from i18n
 El 11/03/2015 13:49, Alexandre Franke alexandre.fra...@gmail.com
 escribió:

 On Wed, Mar 11, 2015 at 1:40 PM, Alexandre Franke
 alexandre.fra...@gmail.com wrote:
  So I guess you are now asking for a freeze exception. It would help if
  you gave us the actual strings and the number of strings added.

 5 new strings:
 Action menu
 Open action menu
 Open view menu
 Search files
 View menu

 Given the importance for a11y, the ease for translating those and the
 fact that it's relatively early in the break, I give you i18n approval
 1/2.

 --
 Alexandre Franke

 ___
 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

[no subject]

[Carlos Soriano Sánchez]

Hi,

I commited a patch which removes markup in the notification of Nautilus.
Similar to what gnome-photos just did.
Hope is now better for all of you translators =)

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

Nautilus strings changes

[Carlos Soriano Sánchez]

Hi,

So Nautilus has some strings changes. The strings are:

 _Empty (src/nautilus-trash-bar.c) which added a nmemonic,
 _Delete from Trash (src/nautilus-view-context-menus.xml) which is new,
 Undo (src/nautilus-notification-delete.ui) which was an error and
changed it from uncapitalized to capitalized.

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