În data de Tue, 8 May 2012 20:20:15 +0400, Alexandre Prokoudine a scris:

Unfortunately it looks like people update translations in the gimp-2-8 branch based on translations from the master branch. This is utterly, utterly wrong :)

If you have questions, please ask :)

What is the status of the script-fu translation for 2.8 ? Right now the .pot file is the 61 strings version and so the files for all languages follow the truncated version.

Cristi

În data de Wed, 9 May 2012 00:52:10 +0400, Alexandre Prokoudine a scris:

What is the status of the script-fu translation for 2.8 ? Right now the .pot file is the 61 strings version and so the files for all languages follow the truncated version.

And you are telling that us just now?????

??

Few days ago Michael Schumacher told me that "It looks like we're facing a technical problem here". I just waited for the technical problem to be fixed, in a hope that my problem with the missing Romanian translation in the official release will be fixed also.

I didn't tell how long I should wait :)

Cristi

În data de Wed, 9 May 2012 00:13:57 +0300, Cristian Secară a scris:

I didn't tell how long I should wait :)

Sorry, I meant "_he_ didn't tell how long I should wait :)"

Cristi

On 12-05-08 04:42 PM, Cristian Secară wrote:

What is the status of the script-fu translation for 2.8 ? Right now the .pot file is the 61 strings version and so the files for all languages follow the truncated version.

I don't know why you are only seeing 21 strings. I just checked out the 2.8 branch and see there are 62 "msgid" entries in the file po-script-fu/ro.po with an additional 540 entries commented out. The en_CA.po file has 627 entries. The Romain po file may be missing some entries if a git master was used to update the .po file for 2.8 but that still seems a bit odd as the strings in the Script-Fu scripts shouldn't have changed much to cause this problem.

În data de Tue, 08 May 2012 18:41:51 -0400, Kevin Cozens a scris:

On 12-05-08 04:42 PM, Cristian Secară wrote:

What is the status of the script-fu translation for 2.8 ? Right now the .pot file is the 61 strings version and so the files for all languages follow the truncated version.

I don't know why you are only seeing 21 strings.

I see 61 strings, not 21.

I just checked out the 2.8 branch and see there are 62 "msgid" entries in the file po-script-fu/ro.po with an additional 540 entries commented out. The en_CA.po file has 627 entries. The Romain po file may be missing some entries if a git master was used to update the .po file for 2.8 but that still seems a bit odd as the strings in the Script-Fu scripts shouldn't have changed much to cause this problem.

Before 2.8 release (i.e. during 2.7.x), the template file for script-fu for master branch at that time had 603 strings. My ro translation that I keep on my computer, the same that was commited on 10 February 2012, has 603 strings.

If you look at the official package available here ftp://ftp.gimp.org/pub/gimp/v2.8/
and browse some script-fu .po files, you can be seen that (for example) de has 603 strings, es has 603 strings, fr has 603 strings, it has 604 strings, sv has 603 strings. At the same time, in the same package, ro (my language) has only 61 strings.

In my running compiled 2.8 program (on Windows), almost all script-fu related menus are English-only. If I put manually the gimp20-script-fu.mo file in the \GIMP 2\share\locale\ro\LC_MESSAGES directory, then the respective menus are back to Romanian, so obviously the 2.8 version program code requires the 603 strings script-fu translation, not just the 61 one.

Cristi

On Wed, 2012-05-09 at 09:30 +0300, Cristian Secară wrote:

Before 2.8 release (i.e. during 2.7.x), the template file for script-fu for master branch at that time had 603 strings. My ro translation that I keep on my computer, the same that was commited on 10 February 2012, has 603 strings.

what was commited on 10 Feb 2012 is:

commit eb93f484c8ad8da3606ab1b44ab8a7f143ea089e Author: Daniel Șerbănescu
Date: Fri Feb 10 19:35:57 2012 +0100

Updated Romanian translation

po-script-fu/ro.po | 4003 +++++++++++++++++++++++++++---------------------------------------- 1 file changed, 1603 insertions(+), 2400 deletions(-)

and puts the file exactly into the current state. Please tell the committer that he messed up and have him restore the file to what you translated.

--Mitch

On 09/05/2012, Michael Natterer wrote:

On Wed, 2012-05-09 at 09:30 +0300, Cristian Secară wrote:

Before 2.8 release (i.e. during 2.7.x), the template file for script-fu for master branch at that time had 603 strings. My ro translation that I keep on my computer, the same that was commited on 10 February 2012, has 603 strings.

what was commited on 10 Feb 2012 is:

commit eb93f484c8ad8da3606ab1b44ab8a7f143ea089e Author: Daniel Șerbănescu
Date: Fri Feb 10 19:35:57 2012 +0100

Updated Romanian translation

po-script-fu/ro.po | 4003 +++++++++++++++++++++++++++---------------------------------------- 1 file changed, 1603 insertions(+), 2400 deletions(-)

and puts the file exactly into the current state. Please tell the committer that he messed up and have him restore the file to what you translated.

When i run make update-po in po-scripts/ i get a gimp20-script-fu.pot with only 62 msgid entries. It looks like it's only extracting the first string in every set of translatable strings, or maybe only ones that immediately follow an opening parenthesis. For example, in spyrogimp.scm,

SF-OPTION _"Tool" '(_"Pencil" _"Brush" _"Airbrush")

The only string that appears in gimp20-script-fu.pot from those is "Pencil".

În data de Wed, 09 May 2012 09:20:23 +0200, Michael Natterer a scris:

what was commited on 10 Feb 2012 is:

commit eb93f484c8ad8da3606ab1b44ab8a7f143ea089e Author: Daniel Șerbănescu
Date: Fri Feb 10 19:35:57 2012 +0100

Updated Romanian translation

po-script-fu/ro.po | 4003 +++++++++++++++++++++++++++---------------------------------------- 1 file changed, 1603 insertions(+), 2400 deletions(-)

and puts the file exactly into the current state. Please tell the committer that he messed up and have him restore the file to what you translated.

Hmm, strange. Ok, I will tell him, but I cannot do that right away, I mean not before the template file from 2.8 script-fu will be reverted too.

What is common with this 61 number ? Why was my file screwed in February down to 61 strings and now in May the template file and the rest of all languages also screwed down to 61 strings ? I find hard to believe (though possible) that in February it was just the committer fault.

So, when will be the 2.8 script-fu template reverted ?

Cristi

On Wed, 2012-05-09 at 10:55 +0300, Cristian Secară wrote:

În data de Wed, 09 May 2012 09:20:23 +0200, Michael Natterer a scris:

what was commited on 10 Feb 2012 is:

commit eb93f484c8ad8da3606ab1b44ab8a7f143ea089e Author: Daniel Șerbănescu
Date: Fri Feb 10 19:35:57 2012 +0100

Updated Romanian translation

po-script-fu/ro.po | 4003 +++++++++++++++++++++++++++---------------------------------------- 1 file changed, 1603 insertions(+), 2400 deletions(-)

and puts the file exactly into the current state. Please tell the committer that he messed up and have him restore the file to what you translated.

Hmm, strange. Ok, I will tell him, but I cannot do that right away, I mean not before the template file from 2.8 script-fu will be reverted too.

What is common with this 61 number ? Why was my file screwed in February down to 61 strings and now in May the template file and the rest of all languages also screwed down to 61 strings ? I find hard to believe (though possible) that in February it was just the committer fault.

So, when will be the 2.8 script-fu template reverted ?

You are right, generating a new template results in 62 strings.

There seems to be a bug in intltool-update --pot that only extracts strings which immediately follow a '(', so

(_"foo" ends up in the template

but

_"foo" doesn't.

At least that's the pattern I found when looking at the pot file and the scheme source files.

To the folks on gnome-i18n@gnome.org: did you ever hear of this issue? Can you investigate it? I'm sure there are more i18n experts on gnome-i18n@gnome.org than on gimp-developer-list ;)

Regards, --Mitch

2012-05-09 10:41 keltezéssel, Michael Natterer írta:

On Wed, 2012-05-09 at 10:55 +0300, Cristian Secară wrote:

În data de Wed, 09 May 2012 09:20:23 +0200, Michael Natterer a scris:

what was commited on 10 Feb 2012 is:

commit eb93f484c8ad8da3606ab1b44ab8a7f143ea089e Author: Daniel Șerbănescu
Date: Fri Feb 10 19:35:57 2012 +0100

Updated Romanian translation

po-script-fu/ro.po | 4003 +++++++++++++++++++++++++++---------------------------------------- 1 file changed, 1603 insertions(+), 2400 deletions(-)

and puts the file exactly into the current state. Please tell the committer that he messed up and have him restore the file to what you translated.

Hmm, strange. Ok, I will tell him, but I cannot do that right away, I mean not before the template file from 2.8 script-fu will be reverted too.

What is common with this 61 number ? Why was my file screwed in February down to 61 strings and now in May the template file and the rest of all languages also screwed down to 61 strings ? I find hard to believe (though possible) that in February it was just the committer fault.

So, when will be the 2.8 script-fu template reverted ?

You are right, generating a new template results in 62 strings.

There seems to be a bug in intltool-update --pot that only extracts strings which immediately follow a '(', so

(_"foo" ends up in the template

but

_"foo" doesn't.

At least that's the pattern I found when looking at the pot file and the scheme source files.

To the folks on gnome-i18n@gnome.org: did you ever hear of this issue? Can you investigate it? I'm sure there are more i18n experts on gnome-i18n@gnome.org than on gimp-developer-list ;)

Yes, I met this here:
https://bugs.launchpad.net/ubuntu-translations/+bug/986897

Seems like a recent change in intltool causes this, which makes the scheme string extraction done by xgettext instead of intltools built-in and dropped parser.

In turn, http://www.gnu.org/software/gettext/manual/gettext.html#Scheme says that the gettext shorthand for scheme strings is (_"foo"), so I think your source files should be modified to conform this notation.

Regards Gabor Kelemen

On Wed, 2012-05-09 at 11:30 +0200, Gabor Kelemen wrote:

2012-05-09 10:41 keltezéssel, Michael Natterer írta:

On Wed, 2012-05-09 at 10:55 +0300, Cristian Secară wrote:

În data de Wed, 09 May 2012 09:20:23 +0200, Michael Natterer a scris:

what was commited on 10 Feb 2012 is:

commit eb93f484c8ad8da3606ab1b44ab8a7f143ea089e Author: Daniel Șerbănescu
Date: Fri Feb 10 19:35:57 2012 +0100

Updated Romanian translation

po-script-fu/ro.po | 4003 +++++++++++++++++++++++++++---------------------------------------- 1 file changed, 1603 insertions(+), 2400 deletions(-)

and puts the file exactly into the current state. Please tell the committer that he messed up and have him restore the file to what you translated.

Hmm, strange. Ok, I will tell him, but I cannot do that right away, I mean not before the template file from 2.8 script-fu will be reverted too.

What is common with this 61 number ? Why was my file screwed in February down to 61 strings and now in May the template file and the rest of all languages also screwed down to 61 strings ? I find hard to believe (though possible) that in February it was just the committer fault.

So, when will be the 2.8 script-fu template reverted ?

You are right, generating a new template results in 62 strings.

There seems to be a bug in intltool-update --pot that only extracts strings which immediately follow a '(', so

(_"foo" ends up in the template

but

_"foo" doesn't.

At least that's the pattern I found when looking at the pot file and the scheme source files.

To the folks on gnome-i18n@gnome.org: did you ever hear of this issue? Can you investigate it? I'm sure there are more i18n experts on gnome-i18n@gnome.org than on gimp-developer-list ;)

Yes, I met this here:
https://bugs.launchpad.net/ubuntu-translations/+bug/986897

Seems like a recent change in intltool causes this, which makes the scheme string extraction done by xgettext instead of intltools built-in and dropped parser.

In turn, http://www.gnu.org/software/gettext/manual/gettext.html#Scheme says that the gettext shorthand for scheme strings is (_"foo"), so I think your source files should be modified to conform this notation.

Thanks, we will fix that.

Regards, --Mitch

On Wed, 2012-05-09 at 13:35 +0200, Michael Natterer wrote:

On Wed, 2012-05-09 at 11:30 +0200, Gabor Kelemen wrote:

2012-05-09 10:41 keltezéssel, Michael Natterer írta:

On Wed, 2012-05-09 at 10:55 +0300, Cristian Secară wrote:

În data de Wed, 09 May 2012 09:20:23 +0200, Michael Natterer a scris:

what was commited on 10 Feb 2012 is:

commit eb93f484c8ad8da3606ab1b44ab8a7f143ea089e Author: Daniel Șerbănescu
Date: Fri Feb 10 19:35:57 2012 +0100

Updated Romanian translation

po-script-fu/ro.po | 4003 +++++++++++++++++++++++++++---------------------------------------- 1 file changed, 1603 insertions(+), 2400 deletions(-)

and puts the file exactly into the current state. Please tell the committer that he messed up and have him restore the file to what you translated.

Hmm, strange. Ok, I will tell him, but I cannot do that right away, I mean not before the template file from 2.8 script-fu will be reverted too.

What is common with this 61 number ? Why was my file screwed in February down to 61 strings and now in May the template file and the rest of all languages also screwed down to 61 strings ? I find hard to believe (though possible) that in February it was just the committer fault.

So, when will be the 2.8 script-fu template reverted ?

You are right, generating a new template results in 62 strings.

There seems to be a bug in intltool-update --pot that only extracts strings which immediately follow a '(', so

(_"foo" ends up in the template

but

_"foo" doesn't.

At least that's the pattern I found when looking at the pot file and the scheme source files.

To the folks on gnome-i18n@gnome.org: did you ever hear of this issue? Can you investigate it? I'm sure there are more i18n experts on gnome-i18n@gnome.org than on gimp-developer-list ;)

Yes, I met this here:
https://bugs.launchpad.net/ubuntu-translations/+bug/986897

Seems like a recent change in intltool causes this, which makes the scheme string extraction done by xgettext instead of intltools built-in and dropped parser.

In turn, http://www.gnu.org/software/gettext/manual/gettext.html#Scheme says that the gettext shorthand for scheme strings is (_"foo"), so I think your source files should be modified to conform this notation.

Thanks, we will fix that.

Well, that (_"foo") is broken, it's an illegal function call, so that can't be what we should put there :(

--Mitch

Hi,

Am Mittwoch 09 Mai 2012, um 14:10:41 schrieb Michael Natterer:

On Wed, 2012-05-09 at 13:35 +0200, Michael Natterer wrote:

On Wed, 2012-05-09 at 11:30 +0200, Gabor Kelemen wrote:

2012-05-09 10:41 keltezéssel, Michael Natterer írta:

On Wed, 2012-05-09 at 10:55 +0300, Cristian Secară wrote:

În data de Wed, 09 May 2012 09:20:23 +0200, Michael Natterer a scris:

what was commited on 10 Feb 2012 is:

commit eb93f484c8ad8da3606ab1b44ab8a7f143ea089e Author: Daniel Șerbănescu
Date: Fri Feb 10 19:35:57 2012 +0100

Updated Romanian translation

po-script-fu/ro.po | 4003 +++++++++++++++++++++++++++---------------------------------------- 1 file changed, 1603 insertions(+), 2400 deletions(-)

and puts the file exactly into the current state. Please tell the committer that he messed up and have him restore the file to what you translated.

Hmm, strange. Ok, I will tell him, but I cannot do that right away, I mean not before the template file from 2.8 script-fu will be reverted too.

What is common with this 61 number ? Why was my file screwed in February down to 61 strings and now in May the template file and the rest of all languages also screwed down to 61 strings ? I find hard to believe (though possible) that in February it was just the committer fault.

So, when will be the 2.8 script-fu template reverted ?

You are right, generating a new template results in 62 strings.

There seems to be a bug in intltool-update --pot that only extracts strings which immediately follow a '(', so

(_"foo" ends up in the template

but

_"foo" doesn't.

At least that's the pattern I found when looking at the pot file and the scheme source files.

To the folks on gnome-i18n@gnome.org: did you ever hear of this issue? Can you investigate it? I'm sure there are more i18n experts on gnome-i18n@gnome.org than on gimp-developer-list ;)

Yes, I met this here:
https://bugs.launchpad.net/ubuntu-translations/+bug/986897

Seems like a recent change in intltool causes this, which makes the scheme string extraction done by xgettext instead of intltools built-in and dropped parser.

In turn, http://www.gnu.org/software/gettext/manual/gettext.html#Scheme says that the gettext shorthand for scheme strings is (_"foo"), so I think your source files should be modified to conform this notation.

Thanks, we will fix that.

Well, that (_"foo") is broken, it's an illegal function call, so that can't be what we should put there :(

I guess it should read (_ "foo") instead of (_"foo") here...?

--Mitch

Kind regards,

Christian

kernel concepts GmbH       Tel: +49-271-771091-14
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/

On Wed, 2012-05-09 at 14:28 +0200, Christian Hilberg wrote:

Hi,

Am Mittwoch 09 Mai 2012, um 14:10:41 schrieb Michael Natterer:

On Wed, 2012-05-09 at 13:35 +0200, Michael Natterer wrote:

On Wed, 2012-05-09 at 11:30 +0200, Gabor Kelemen wrote:

2012-05-09 10:41 keltezéssel, Michael Natterer írta:

On Wed, 2012-05-09 at 10:55 +0300, Cristian Secară wrote:

În data de Wed, 09 May 2012 09:20:23 +0200, Michael Natterer a scris:

what was commited on 10 Feb 2012 is:

commit eb93f484c8ad8da3606ab1b44ab8a7f143ea089e Author: Daniel Șerbănescu
Date: Fri Feb 10 19:35:57 2012 +0100

Updated Romanian translation

po-script-fu/ro.po | 4003 +++++++++++++++++++++++++++---------------------------------------- 1 file changed, 1603 insertions(+), 2400 deletions(-)

and puts the file exactly into the current state. Please tell the committer that he messed up and have him restore the file to what you translated.

Hmm, strange. Ok, I will tell him, but I cannot do that right away, I mean not before the template file from 2.8 script-fu will be reverted too.

What is common with this 61 number ? Why was my file screwed in February down to 61 strings and now in May the template file and the rest of all languages also screwed down to 61 strings ? I find hard to believe (though possible) that in February it was just the committer fault.

So, when will be the 2.8 script-fu template reverted ?

You are right, generating a new template results in 62 strings.

There seems to be a bug in intltool-update --pot that only extracts strings which immediately follow a '(', so

(_"foo" ends up in the template

but

_"foo" doesn't.

At least that's the pattern I found when looking at the pot file and the scheme source files.

To the folks on gnome-i18n@gnome.org: did you ever hear of this issue? Can you investigate it? I'm sure there are more i18n experts on gnome-i18n@gnome.org than on gimp-developer-list ;)

Yes, I met this here:
https://bugs.launchpad.net/ubuntu-translations/+bug/986897

Seems like a recent change in intltool causes this, which makes the scheme string extraction done by xgettext instead of intltools built-in and dropped parser.

In turn, http://www.gnu.org/software/gettext/manual/gettext.html#Scheme says that the gettext shorthand for scheme strings is (_"foo"), so I think your source files should be modified to conform this notation.

Thanks, we will fix that.

Well, that (_"foo") is broken, it's an illegal function call, so that can't be what we should put there :(

I guess it should read (_ "foo") instead of (_"foo") here...?

Yes, and that produces another error message :( I guess we'll have to fix script-fu.

Thanks,
--mitch

On Wed, May 9, 2012 at 4:41 AM, Michael Natterer wrote:

You are right, generating a new template results in 62 strings.

There seems to be a bug in intltool-update --pot that only extracts strings which immediately follow a '(', so

(_"foo" ends up in the template

but

_"foo" doesn't.

At least that's the pattern I found when looking at the pot file and the scheme source files.

To the folks on gnome-i18n@gnome.org: did you ever hear of this issue? Can you investigate it? I'm sure there are more i18n experts on gnome-i18n@gnome.org than on gimp-developer-list ;)

Please review this bug, which details the probable cause (ignoring .scm files?) for GIMP script-fu only having 61 strings instead of 600-odd.

GIMP missing menu translations https://bugs.launchpad.net/intltool/+bug/986897

They are using a manual workaround on Launchpad for Ubuntu (comment #8)

There is a also comment that this change may have introduced the issue: http://bazaar.launchpad.net/~intltool/intltool/trunk/revision/722

I came across this while searching for an answer to why WebKitGTK+ POT generation is munged up. It apparently can most easily be fixed by addressing this intltool ticket.

There's no way to specify where's the po directory if it's not on topdir https://bugs.launchpad.net/intltool/+bug/823217

If you use Launchpad, please feel free to click the "this bug effects me" link on this bug. I'm hoping for some action on it. Good luck getting intltool to not mangle the GIMP script-fu POT generation.

cjl

gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

On 12-05-09 05:30 AM, Gabor Kelemen wrote:

https://bugs.launchpad.net/ubuntu-translations/+bug/986897

Seems like a recent change in intltool causes this, which makes the scheme string extraction done by xgettext instead of intltools built-in and dropped parser.

The information for revision 722 indicates that intltool-extract.in and intltool-update.in had the support for Scheme code in files ending with .scm removed. The test case file "test.scm" was also removed.

I would be interested to know more about why this change was made. Back in the early days of gimp when these two scripts were part of the GIMP source tree we had to apply a patch to make them handle the marked strings in GIMP's .scm files.

It's almost as if there is supposed to be one way of marking strings in Scheme based scripts (regardless of which interpreter is being used), or xgettext never got the additional changes to handle strings marked in .scm files the way they are in GIMP's Script-Fu scripts, or both.

If there is a move towards using xgettext to do string extraction we need to find out how to use it to extract strings from Script-Fu scripts. If it can't do that, we should ask the gettext people to update xgettext to include the code that was dropped from the two external scripts.

In turn, http://www.gnu.org/software/gettext/manual/gettext.html#Scheme says that the gettext shorthand for scheme strings is (_"foo"), so I think your source files should be modified to conform this notation.

Scheme in gettext manual references GNU guile. BTW, the markup it uses has a space between the _ and the opening " of the string. The form _"abc" is still valid markup for awk but I don't expect that to be of much help to us.

On 12-05-12 05:03 PM, Kevin Cozens wrote:

On 12-05-09 05:30 AM, Gabor Kelemen wrote:

Seems like a recent change in intltool causes this, which makes the scheme string extraction done by xgettext instead of intltools built-in and dropped parser.

I forgot to add some information.

There was some discussion about modifying the Script-Fu scripts to conform to the (Guile) supported method of markup. My initial feeling was that it would not be that difficult to change the interpreter to support the method but I also suspect that the change in syntax in the scripts will lead to problems.

I'm busy with an online course for another three weeks or so which limits the time I have to spend working on making the changes and seeing if it would break the scripts. My concern is for markup of strings in register blocks.