Doc team notifications of freeze breaks

[mcatanzaro]

Hi,

Historically, our rules for freezes have required notifying 
gnome-doc-list@ of any freeze breaks. This rule has not always been 
followed (I'm a flagrant violator myself). Since nowadays documentation 
operates on a longer cadence (generally years rather than months), I 
think it really doesn't make sense to have these notifications anymore. 
If there are any recent examples of a documentation change being 
committed within the freeze window in response to a freeze break 
notification, please let me know; otherwise, I don't think this change 
should be controversial.


Also, release team really doesn't need to be involved in string freeze 
breaks (to the extent a string freeze break is not a UI freeze break) 
since the internationalization team is well-qualified to handle these.


This means all freeze break requests can now go to just one place:

* String freeze break requests go to 
* Other freeze break requests go to 

unless you're landing a major UI change with string changes, in which 
case you'll still need separate UI freeze and string freeze break 
approvals.


Hopefully this should make freeze break requests a bit easier.


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

Re: Unauthorized translation changes in dconf-editor

[mcatanzaro]

Please keep gnome-i18n@gnome.org CCed

On Mon, Mar 18, 2019 at 5:02 AM, Arnaud Bonatti 
 wrote:

Hi Jeremy and Michael, hi release-team,

2019-03-17 17:01 UTC+01:00, mcatanz...@gnome.org 
:

 I see:

 
https://gitlab.gnome.org/GNOME/dconf-editor/commits/maintainer-only-3-32/po


 which seems pretty excessive. You probably wouldn't be very happy if
 translators starting introducing unexpected changes outside of po/,
 right? In the same way, the translators would prefer you to not make
 changes under po/.


That’s my role as a maintainer to ensure that the product that is
taggued as stable does not look broken.

If translations are breaking the application layout, by translating
the word “Translators” as something crediting translators on a 
long
multiline string (the said “translator-credits” string from the 
About

dialog), it’s my role to not tag a stable release without these
translations fixed.

If a translation contains a web link to what is currently an
hypnotherapist website, it’s my role to remove that link before it
hits the stable release. Even if I didn’t had the time to join the
translator or its team to fix it in l10n. (Yes, it’s a true story. 
Not

a big issue, but a real life one.)


 Why is this necessary? They can't maintain their translations if you
 have your own separate translations that never make it into
 l10n.gnome.org.


My goal is of course to upstream these changes is l10n, not to
maintain a out of tree patchset indefinitely.

But this upstreaming takes time: sometimes translators do not answer
(see 
https://bugzilla.gnome.org/buglist.cgi?quicksearch=product:l10n%20dconf-editor

for long-time bugs without answers), sometimes translators take time
to understand the problem, and I have to tag a stable release by the
time.

But that should not be a surprise if the last commit before the 3.32
dconf-editor release (8d0fa918) is fixing in one translation a problem
I discovered and temporarily fixed in other po files, that’s part of
my work with translators on these issues.

As opposed to what Jeremy Bicha says, my current workflow is not
breaking the translators one; that was not the case with my previous
attempts (sorry again with that). And it is fixing translations for
real life users. And that’s the important part of this story.

Regards,
Arnaud

--
Arnaud Bonatti

courriel : arnaud.bona...@gmail.com



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

Re: Unauthorized translation changes in dconf-editor

[mcatanzaro]

On Sun, Mar 17, 2019 at 10:11 AM, Jeremy Bicha  
wrote:

I am reviving this old thread because it looks like Arnaud never
stopped making his changes. He has created separate "maintainer-only"
branches. He makes his release tags and tarball releases from those
branches. This has continued with the dconf-editor 3.32.0 release from
a few days ago.

This behavior is very disruptive to the translator workflow.
Translators have a very reasonable expectation that their translations
(as seen in the master and stable git branches and at l10n.gnome.org)
will make it to distros and users without being "fixed" in a hidden
way first.

https://gitlab.gnome.org/GNOME/dconf-editor/tags
https://gitlab.gnome.org/GNOME/dconf-editor/commits/maintainer-only-3-32

Jeremy


Hi Arnaud,

I see:

https://gitlab.gnome.org/GNOME/dconf-editor/commits/maintainer-only-3-32/po

which seems pretty excessive. You probably wouldn't be very happy if 
translators starting introducing unexpected changes outside of po/, 
right? In the same way, the translators would prefer you to not make 
changes under po/.


Why is this necessary? They can't maintain their translations if you 
have your own separate translations that never make it into 
l10n.gnome.org.


Michael


___
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

[mcatanzaro]

1 / 2 release team


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

Re: String Freeze Break - totem

[mcatanzaro]

"The source seems encrypted and can’t be read. Are you trying to play 
an encrypted DVD without libdvdcss?"


It's challenging to come up with an error message that provides the 
right level of technical detail for users to be able to fix the 
problem, without confusing nontechnical users. Not sure you hit the 
right balance here; it sounds jargon-y.


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

Re: Seahorse - String freeze break

[mcatanzaro]

Oops! +1 / 2 release team

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

Re: GNOME Music freeze break request

[mcatanzaro]

On Sat, Feb 16, 2019 at 9:02 PM, mcatanz...@gnome.org wrote:

 I like what Music is doing, +2.


To be clear, that's 2/2 release team.

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

Re: GNOME Music freeze break request

[mcatanzaro]

On Fri, Feb 8, 2019 at 10:56 AM, Emmanuele Bassi via release-team 
 wrote:
Thank you for the clarification; in one of the issues you linked I 
saw the error screen with a GDBus blurb and I got worried. :-)


On Fri, Feb 8, 2019 at 5:15 AM, Emmanuele Bassi via release-team 
 wrote:
Are we really showing a GDBus error message in a landing screen aimed 
at newcomers? Because that would be an immediate -1 from me.


Ciao,


Er well those are screenshots of Photos, not Music. I like what Music 
is doing, +2.


CC: Rishi for the Photos issue. Complaint is that these screenshots:

https://gitlab.gnome.org/GNOME/gnome-photos/merge_requests/85

Should look more like these ones:

https://gitlab.gnome.org/GNOME/gnome-music/merge_requests/335

Michael

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

Re: gnome-software string freeze break request

[mcatanzaro]

On Fri, Sep 14, 2018 at 8:08 AM, Matthias Clasen via release-team 
 wrote:

I asked for this, so +1 from me.


+1 from me as well. You still need two translator approvals.

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

Re: [glib][GDateTime] API and string freeze break request

[mcatanzaro]

On Mon, Feb 12, 2018 at 1:54 PM, Rafal Luzynski 
 wrote:
Thank you. So here I have the feedback from the i18n team, as 
Alexandre said I don't need an approval yet. What about any feedback 
from the documentation and release team? Maybe I don't need an 
approval as well?


You do need two approvals from release-team. This is your first, 
because I assume this change is unlikely to break application unless 
they use the new API.


Michael

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

Heads-up: string change in GNOME 3.22

[mcatanzaro]

Hi,

I'm releasing a new version of libgnome-games-support 1.2 today. This 
is the active branch for both GNOME 3.22 and GNOME 3.24. It contains 
one translatable string change that was made in November, so no string 
break for 3.24, but it's a break for 3.22. The purpose of the change is 
to fix the build with Vala 0.36. Unfortunately, it is a format string, 
and if we don't change it, it doesn't build.


I think this is OK to do because it is the *only* change since the 
previous release, besides translation updates. So translators have 
already had over half a year to update translations for it, and all 
these translation updates will be included. So you can safely ignore 
this string freeze break.


Michael

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