gnome release notes

[Fabio Tomat]

I'm not english but this sentence sounds me wrong, so I just ask to the
community if it's ok:

"Character forms and spacing have been evolved, so that text that is more
readable and attractive."

Is the sencond "that" ok?
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

[evince] Created branch gnome-3-28

[Jose Aliste]

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

 493afe9... Release 3.27.92

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

FYI: gnome-terminal help pages

[Egmont Koblinger]

Dear Translators,

This is just a friendly heads-up:

gnome-terminal's help pages received lots of changes about a month
ago. The pages were updated against the new merged preferences window,
plus they received many one-off fixes as well.

There are several languages where these pages were 100% translated in
3.26, but are at 72% now. In case you have time, it would be awesome
if you could update them so that they don't regress. These languages
are: ca cs de el es fr hu ko pt_BR sv. Also in quite good shape,
probably worth completing are: fi ru.

Special thanks go out to Piotr Drąg for his continuous effort on
fixing the source strings, and the completeness of the Polish
translation!

Thanks for your great work guys,

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

Re: [dconf-editor] string freeze break (or opinions) request

[Arnaud Bonatti]

2018-03-05 17:04 UTC+01:00, Piotr Drąg :
>>  – Proposition 1: fix the string generation using “” in the
>> gschema file, and let translators redo the translations;
>>  – Proposition 2: replace the two line breaks by one space, so that
>> all translations already done work, but without any line break (and
>> I’d change the strings next cycle for what is wanted).
>
> In a perfect world, we would fix bug #793931 properly. As we live in
> this world, I think proposition 2 is the best solution for 3.28, and
> we can deal with the bigger problem in 3.30. The decision is yours,
> though.

I’ll certainly go that way if there are no other opinions on this question.

>> I had also planned a 1bis proposition, where I fix the gschema file
>> and all the translations in one patch, avoiding work from translators,
>> but following previous discussion, that’s probably not a path I can
>> follow. ;)
>
> The difference is that this would be a change (presumably) consulted
> with and approved by the translation teams, which makes it OK. :P

Something that cannot be done in one day, so a path I can’t follow. :·)

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: [dconf-editor] string freeze break (or opinions) request

[Piotr Drąg]

2018-03-05 9:42 GMT+01:00 Arnaud Bonatti :
> Hello everybody! Reviewing translations of the “dconf-editor” module I
> maintain, I’ve discovered that I had a string generation problem: in
> the gschema file, four strings contains line breaks, but these line
> breaks doesn’t finish in the po files, and so the translations made by
> translators do not finish in the application. So sad. :·( That has
> been reported in the Bugzilla instance by Piotr Drąg[1] against GLib
> using another module as example.
>
> So. I’m not sure if I’m in a “string freeze break request” case or not
> (I don’t find my exact case in the Wiki[2]), but I have two
> proposition for fixing these bug-ly untranslated strings:

I’d say this is covered by “Marking a message for translation that was
previously not marked for translation by accident.” Even though the
string was technically translatable, the translation couldn’t be used.

>  – Proposition 1: fix the string generation using “” in the
> gschema file, and let translators redo the translations;
>  – Proposition 2: replace the two line breaks by one space, so that
> all translations already done work, but without any line break (and
> I’d change the strings next cycle for what is wanted).

In a perfect world, we would fix bug #793931 properly. As we live in
this world, I think proposition 2 is the best solution for 3.28, and
we can deal with the bigger problem in 3.30. The decision is yours,
though.

> I had also planned a 1bis proposition, where I fix the gschema file
> and all the translations in one patch, avoiding work from translators,
> but following previous discussion, that’s probably not a path I can
> follow. ;)
>

The difference is that this would be a change (presumably) consulted
with and approved by the translation teams, which makes it OK. :P

> Anyway, should I do something, or not, and if yes what? That’s not an
> important change, but for now translators are working on strings that
> doesn’t appear, and that lost time makes me sad. :·(
>

I would like to say that I really appreciate your concern!

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: Updated month name translations needed in GLib

[Philip Withnall]

On Sat, 2018-03-03 at 22:49 +0100, Piotr Drąg wrote:
> 2018-02-21 12:49 GMT+01:00 Philip Withnall :
> > Hi all,
> > 
> > (I’m not subscribed to the list, so please CC me in replies.)
> > 
> > As discussed previously[1], nominative/genitive month name support
> > has
> > come to GLib. We’ve got a few unit tests which depend on
> > translations
> > existing for the new month name strings[2] which are currently
> > broken
> > due to the new strings being missing in the following locales:
> >  • fr_FR
> >  • el_GR
> >  • hr_HR
> >  • lt_LT
> >  • ru_RU
> > 
> > There’s also this bug[3] which requires the same updates in ja_JP.
> > 
> > Could the translation teams please prioritise updating the month
> > name
> > strings in GLib? Both for the sake of making the tests pass, and
> > for
> > making sure users in your locale get correctly-translated month
> > names.
> > In locales with no nominative/genitive difference, you still need
> > to
> > update the translations to avoid the C-locale string being used in
> > the
> > new context.
> > 
> > For many languages, this will be a case of copying the existing
> > strings
> > from one context to the other, unchanged. Those languages which
> > have a
> > difference between nominative and genitive forms will have to be a
> > bit
> > more careful. Typically, the strings should be the same as the
> > output
> > of `locale mon` on a system running the latest glibc release.
> > 
> > If anybody has any questions about the translations, let me or
> > Rafal
> > know.
> > 
> 
> Reminder for *every* translation team: you should update strings from
> glib/gdatetime.c in GLib to avoid a chance of English dates in the
> next GNOME release. Languages which won’t get an update soon will get
> a commit from https://gitlab.gnome.org/GNOME/glib/commits/wip/piotrdr
> ag/missing-months
> merged.

I have merged that branch to GLib master, so it will be in the 2.56.0
release. There is still time for translation teams to update the
strings there before the release, if you spot any problems with them.

(Please CC me in any replies as I am not subscribed to gnome-i18n.)

Thanks,
Philip

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

Re: assignee for friulian translation in bugzilla

[Andre Klapper]

Hi Fabio,

On Mon, 2018-03-05 at 10:53 +0100, Fabio Tomat wrote:
> I'm Fabio Tomat the coordinator for friulian translations in GNOME DL
> I noticed that in bugzilla the "assigned to" field and "QA Contact"
> field for some bugs are set to Massimo Furlani, whom I tried to
> contact at his e-mail. The response was:
> 
> 550 Invalid Recipient  ...
> 
> I don't know anything about him, but if there is no way of contacting
> him, and he isn't anymore involved in the project, I'll be glad to
> take charge of the commitment, at least I receive the bugs in my e-
> mail.

Indeed, I also got a 550 error. I've set you as the new default
assignee and QA contact for tickets under 'L10N>Friulian' in BZ.

Thanks,
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

assignee for friulian translation in bugzilla

[Fabio Tomat]

I'm Fabio Tomat the coordinator for friulian translations in GNOME DL
I noticed that in bugzilla the "assigned to" field and "QA Contact" field
for some bugs are set to Massimo Furlani, whom I tried to contact at his
e-mail. The response was:

550 Invalid Recipient  ...

I don't know anything about him, but if there is no way of contacting him,
and he isn't anymore involved in the project, I'll be glad to take charge
of the commitment, at least I receive the bugs in my e-mail.

Best regards

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

[dconf-editor] string freeze break (or opinions) request

[Arnaud Bonatti]

Hello everybody! Reviewing translations of the “dconf-editor” module I
maintain, I’ve discovered that I had a string generation problem: in
the gschema file, four strings contains line breaks, but these line
breaks doesn’t finish in the po files, and so the translations made by
translators do not finish in the application. So sad. :·( That has
been reported in the Bugzilla instance by Piotr Drąg[1] against GLib
using another module as example.

So. I’m not sure if I’m in a “string freeze break request” case or not
(I don’t find my exact case in the Wiki[2]), but I have two
proposition for fixing these bug-ly untranslated strings:
 – Proposition 1: fix the string generation using “” in the
gschema file, and let translators redo the translations;
 – Proposition 2: replace the two line breaks by one space, so that
all translations already done work, but without any line break (and
I’d change the strings next cycle for what is wanted).
I had also planned a 1bis proposition, where I fix the gschema file
and all the translations in one patch, avoiding work from translators,
but following previous discussion, that’s probably not a path I can
follow. ;)

Anyway, should I do something, or not, and if yes what? That’s not an
important change, but for now translators are working on strings that
doesn’t appear, and that lost time makes me sad. :·(

Waiting for your suggestions,
Arnaud


[1] https://bugzilla.gnome.org/show_bug.cgi?id=793931
[2] https://wiki.gnome.org/TranslationProject/HandlingStringFreezes

-- 
Arnaud Bonatti

courriel : arnaud.bona...@gmail.com
From 6b371b87d30bb894b6038fbb443834c55b278f60 Mon Sep 17 00:00:00 2001
From: Arnaud Bonatti 
Date: Mon, 5 Mar 2018 09:21:47 +0100
Subject: [PATCH] Proposition 1.

---
 editor/ca.desrt.dconf-editor.gschema.xml | 16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/editor/ca.desrt.dconf-editor.gschema.xml b/editor/ca.desrt.dconf-editor.gschema.xml
index aeb7ccc..d3f02c5 100644
--- a/editor/ca.desrt.dconf-editor.gschema.xml
+++ b/editor/ca.desrt.dconf-editor.gschema.xml
@@ -234,30 +234,22 @@
 
   0
   A D-Bus handle type, type ‘h’
-  The handle type is a 32-bit signed integer value that is, by convention, used as an index into an array of file descriptors that are sent alongside a D-Bus message.
-
-If you are not interacting with D-Bus, then there is no reason to make use of this type.
+  The handle type is a 32-bit signed integer value that is, by convention, used as an index into an array of file descriptors that are sent alongside a D-Bus message.If you are not interacting with D-Bus, then there is no reason to make use of this type.
 
 
   '/ca/desrt/dconf_editor'
   A D-Bus object path, type ‘o’
-  An object path is used to identify D-Bus objects at a given destination on the bus.
-
-If you are not interacting with D-Bus, then there is no reason to make use of this type.
+  An object path is used to identify D-Bus objects at a given destination on the bus.If you are not interacting with D-Bus, then there is no reason to make use of this type.
 
 
   ['/ca/desrt/dconf_editor/menus/appmenu', '/ca/desrt/dconf_editor/window/1']
   A D-Bus object path array, type ‘ao’
-  An object path array could contain any number of object paths (including none: “[]”).
-
-If you are not interacting with D-Bus, then there is no reason to make use of this type.
+  An object path array could contain any number of object paths (including none: “[]”).If you are not interacting with D-Bus, then there is no reason to make use of this type.
 
 
   'ii'
   A D-Bus signature, type ‘g’
-  A D-Bus signature is a string used as type signature for a D-Bus method or message.
-
-If you are not interacting with D-Bus, then there is no reason to make use of this type.
+  A D-Bus signature is a string used as type signature for a D-Bus method or message.If you are not interacting with D-Bus, then there is no reason to make use of this type.
 
 
   3.1415926535897933
-- 
2.14.3

From d3c7ca4d70af2409ff8bfa52d2b65d53187d5c6a Mon Sep 17 00:00:00 2001
From: Arnaud Bonatti 
Date: Mon, 5 Mar 2018 09:22:28 +0100
Subject: [PATCH] Proposition 2.

---
 editor/ca.desrt.dconf-editor.gschema.xml | 16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/editor/ca.desrt.dconf-editor.gschema.xml b/editor/ca.desrt.dconf-editor.gschema.xml
index aeb7ccc..f6ec818 100644
--- a/editor/ca.desrt.dconf-editor.gschema.xml
+++ b/editor/ca.desrt.dconf-editor.gschema.xml
@@ -234,30 +234,22 @@
 
   0
   A D-Bus handle type, type ‘h’
-  The handle type is a 32-bit signed integer value that is, by convention, used as an index into an array of file descriptors that are sent alongside a D-Bus message.
-
-If you are not interacting with D-Bus, then there is no reason to