gtranslator-devel — Mail gtranslator development mailing list for discussions - keep on track!

Re: [Gtranslator-devel] Patches

[Ross G. <ro...@go...>]

Hi Vital,

While looking through the patch for the 1.1 branch, I noticed it's full
of unnecessary changes and revertions. For example the changes of
'g_free' to 'GTR_FREE', the whole part of the patch that applied to
about.c, and the changes of PACKAGE to the string 'gtranslator',
reversion of the year value in one of the copyright headers, etc.

Also, whilst applying it to the stable CVS branch, most of the hunks
fail and I get lots of conflicts etc that I just don't have time to
resolve at the moment. It leaves the working directory in an
uncompilable state. Basically, I can't accept the patch as it is,
because it would take too long to strip it down to it's useful changes
and get it to apply cleanly :)

However, I want to accept a patch, and as I can see you've put a lot of
work into the plurals etc. and I hate to say 'no'. So if you could try
the following:

Check out *fresh* working copy of the gtranslator stable (1.1) branch.
Something like:

$ cvs co gtranslator -r gnome-2-8

Copy the changed files from the stable version you've been working on
into place in the new working directory. Run a 'cvs diff -u' to make
sure there aren't any unnecessary changes (as described at the top of
this e-mail). Add some information to the top of the src/ChangeLog.
Here's what I managed to work out for starters:

2005-06-17  =D0=92=D1=96=D1=82=D0=B0=D0=BB=D1=8C =D0=A5=D1=96=D0=BB=D1=8C=
=D0=BA=D0=BE <v.k...@sa...>

	* gui.[ch]: Use a GtkNotebook 'page' for tabbed support of plurals.
 	* actions.c, color-schemes.c, dialogs.c, find.c: Use new 'page'
object.
	* dialogs.c: Use GtkFileChooserDialog.
	* header_stuff.c: Add 'nplurals_spinner' and 'plural_combo' objects.
	* header_stuff.[ch]: Added 'true_header', 'nplurals' and 'plural'
members.
	* languages.[ch]: Added default plurals settings for all the languages.
	* bookmark.c: Use phrase 'No comment' where comment is NULL.
	* bookmark.[ch]: New 'gtranslator_bookmark_resolvable' function.
	* compile.[ch]: Redundant. Removed completely.
	* defines.h: Created to contain compiler definitions.
=09
If you have made any whitespace changes, you might find 'cvs diff -ub'
is more useful. I would prefer no whitespace changes in the patch.

Then, when you can run a 'cvs diff -u' (or '-ub') and the patch is
clean, send me a new copy and I will re-evaluate it.

Same applies for the HEAD patch. If you can make sure the patch is
clean, will apply against an up-to-date HEAD revision and has a similar
ChangeLog, that would make our lives a lot easier :)

Thanks for all your work. Sorry it's taken so long to get round to (they
are certainly big, scary patches as they stand - probably won't be so
scary once you've cleaned them up a bit!).

--
Ross

On =E0=B8=9E., 2005-07-20 at 10:26 +0300, Vital Khilko wrote:
> hi all!
> I spent a certain time on the addition of functionality for
> gtranslator which necessary to me. The majorities of corrections are
> necessary for  working with the plural forms. But since as always I
> experienced deficiency in the time, all patches were written as the
> rapid solutions. One after one, and came out the very bulky and
> terrible code. Therefore I decided to here present some considerations
> on an improvement in the program. Together solve them will be more
> simply.
>=20
> I. Translation statuses which usable for translators (by my
> translation experience):
> 1.message cannot have status "fuzzy" if it not translated
> 2.messages which contains plural forms can have status:
>   - translated, if all messages are translated.=20
>   - untranslated, if all messages are not translated.
>   - fuzzy, if one (or more but not all) message is translated
>     or comment contains "# ,fuzzy" flag.
> 3. Stiky messages is a good idea. ;-)
> Satisfaction of all these conditions will help translators more simply
> to be oriented with the translation. These statuses are not obligated
> to be present in the gettex library. They may be virtual within the
> framework of gtranslator.
>=20
> II. Built-in data about the plural forms strings for each presented
> languages. This is very important point. In time that I am occupied by
> localization of applications I very frequently met different
> determination for these strings in files of different translators. But
> they all this made for _one language_. And this is understandable -
> the plural forms are very difficult for the understanding by series
> user. I think that these data must be stored either inside our program
> or inside the separate library. But better if they are in locale
> data ;-)
> I proposed new language data structure:
> /*
> * The language structure with all the essential data for gtranslator:
> */
> typedef struct {
> /*
> * 1 - The name of the language (e.g. "Turkish").
> */
> gchar *name;
> /*
> * 2 - The language-code (e.g. "tr").
> */
> gchar *locale;
> /*
> * 3 - The encoding mostly used for the language (e.g. "iso-8859-9").
> */
> gchar *encoding;
> /*
> * 4 - The group's EMail list (e.g. "gno...@gn...").
> */
> gchar *group_email;
> /*
> * 5 - The transfer bit count for the language (e.g. "8bit").
> */
> gchar *bits;
> /*
> * 6 - numbers of plural forms
> */
> gint nplurals;
> /*
> * 7 - plural form string
> */
> gchar *plural;=20
> } GtrLanguage;
>=20
> And as result language data view as =20
> GtrLanguage languages[] =3D {
> {
> N_("Afrikaans"), "af", "iso-8859-1",
> "", "8bit", 2, "(n !=3D 1)"
> },
>=20
>=20
> III. File parsing (messages & header).=20
> For the successful work with the plural forms pre-load of po-header is
> necessary. Then header parsing and, if it is necessary, settings of
> correct variables for the plural forms.=20
> Then each message must be parsed with criterion from point I.
> Also on the demand of user and automatically with file saving
> necessary checking according to gettext rules. All errors must be
> hightlighted (as Kbabel ?).
>=20
>=20
> IV. Better visualization data in translation table.
> I think data visualisation and good UI improve translation
> productivity.
> And translation table is good idea. But table must have ability for
> hide without restarting application and must be detachable as toolbar.
> I made the first steps in this direction. I added small icons into
> table nodes and icons for plural form designation. I think that all
> actions conducted above the message they must be mapped into table
> without delay. Although this is questionable possibility.
>=20
>=20
> V. Better preferences dialog.
> Ok, current preferences dialog is terrible. It attempts to engage
> entire screen. I divided it by logic units and was used a tree for the
> selection (as in firefox, monodevelop etc.). I think this only for the
> benefit.
>=20
>=20
> VI. Working with plural forms.
> This the fact that forced me to write patches. Logic is simple -
> notebook with tabs of which one contains plural form messages.=20
>=20
>=20
> to be continue ;-)
>=20
> P.S. Ross, I think rollback to old version is not necessary. It is
> better to add _some_ necessary changes to HEAD branch (I like new
> MDI ;-) ). I will begin from preferences dialog and plural forms data.
>=20
> P.P.S. I will be repeated " patches code is terrible!". Tear me on
> parts ;-)

Re: [Gtranslator-devel] Patches

[Ross G. <ro...@go...>]

On =E0=B8=9E., 2005-07-20 at 10:26 +0300, Vital Khilko wrote:
> hi all!
> I spent a certain time on the addition of functionality for
> gtranslator which necessary to me. The majorities of corrections are
> necessary for  working with the plural forms. But since as always I
> experienced deficiency in the time, all patches were written as the
> rapid solutions. One after one, and came out the very bulky and
> terrible code. Therefore I decided to here present some considerations
> on an improvement in the program. Together solve them will be more
> simply.
>=20

I've just looked at the CVS HEAD patch. It looks great, and I'm looking
forward to trying it, but it doesn't compile. It's giving me:

messages-table.c: In function `gtranslator_messages_table_create':
messages-table.c:339: error: `GTRANSLATOR_PIXMAPS_DIR' undeclared (first
use in this function)

I can't see where that's being defined anywhere.

One other thing - it needs a ChangeLog of some sort. Can you make a
ChangeLog entry describing the *main* changes between CVS HEAD with and
without this patch? Or, if I can get it to compile here, I might be able
to figure that out myself and write one for you.

I'll have to look at the 1.1 series patch another time (sorry - out of
time again!).

> I. Translation statuses which usable for translators (by my
> translation experience):
> 1.message cannot have status "fuzzy" if it not translated
> 2.messages which contains plural forms can have status:
>   - translated, if all messages are translated.=20
>   - untranslated, if all messages are not translated.
>   - fuzzy, if one (or more but not all) message is translated
>     or comment contains "# ,fuzzy" flag.
> 3. Stiky messages is a good idea. ;-)
> Satisfaction of all these conditions will help translators more simply
> to be oriented with the translation. These statuses are not obligated
> to be present in the gettex library. They may be virtual within the
> framework of gtranslator.
>=20

I don't understand sticky messages (yet). What do sticky messages do?

> II. Built-in data about the plural forms strings for each presented
> languages. This is very important point. In time that I am occupied by
> localization of applications I very frequently met different
> determination for these strings in files of different translators. But
> they all this made for _one language_. And this is understandable -
> the plural forms are very difficult for the understanding by series
> user. I think that these data must be stored either inside our program
> or inside the separate library. But better if they are in locale
> data ;-)
> I proposed new language data structure:

Personally, I don't like having this information compiled into
hard-coded arrays in gtranslator. If we need to keep it, we ought to
keep it in a more data-oriented format (such as XML) and have it parsed
in on startup.

Also, as I understand it, most translation projects that I know of
require translations encoded in UTF-8, so I don't understand why we need
to track an encoding per language. And, as I understand it, some
languages have more than one alternative character encoding (for
whatever historical purposes). Is there any reason (of real use to a
gtranslator user) that we should track this attribute, and if so, should
it not be multi-value?

Also, I don't think the 'language group' e-mail attribute is such a good
idea. In the real world, there are many language translation groups.
Different software projects use different translation groups (e.g. GNOME
uses GTP, OpenOffice uses some other group etc etc). Why tie gtranslator
to a particular translation group per language? Again, is this giving
the gtranslator user some real advantage that I'm overlooking?

Personally, I think we need the concept of 'profiles', whereby you can
choose to be a 'Thai GNOME translator' or a 'German OpenOffice
translator' etc. and the character encoding/language group (and
potentially other information, such as translation memories) etc is
stored per translation profile. Or even, have seperate 'language'
profiles and 'translation project' profiles. I don't know, just food for
thought.

>=20
> III. File parsing (messages & header).=20
> For the successful work with the plural forms pre-load of po-header is
> necessary. Then header parsing and, if it is necessary, settings of
> correct variables for the plural forms.=20
> Then each message must be parsed with criterion from point I.
> Also on the demand of user and automatically with file saving
> necessary checking according to gettext rules. All errors must be
> hightlighted (as Kbabel ?).

Of course. IMHO, a  proper exception model should be used in all places
to handle minor and major parser warnings/errors :)

> IV. Better visualization data in translation table.
> I think data visualisation and good UI improve translation
> productivity.
> And translation table is good idea. But table must have ability for
> hide without restarting application and must be detachable as toolbar.
> I made the first steps in this direction. I added small icons into
> table nodes and icons for plural form designation. I think that all
> actions conducted above the message they must be mapped into table
> without delay. Although this is questionable possibility.

Agreed. The table is annoying sometimes, and useful others, and having
to restart the whole application to hide/show it is not really
acceptable :) It's like having to reboot an operating system to update a
driver!

> V. Better preferences dialog.
> Ok, current preferences dialog is terrible. It attempts to engage
> entire screen. I divided it by logic units and was used a tree for the
> selection (as in firefox, monodevelop etc.). I think this only for the
> benefit.

Fantastic.

> VI. Working with plural forms.
> This the fact that forced me to write patches. Logic is simple -
> notebook with tabs of which one contains plural form messages.=20

That looks cleaner than the approach I came up with. The user can see
the 'msgid' and whichever of the 'msgstr' array is chosen (using the
notebook tabs), but how does the user get to see the msgid_plural?

>=20
> to be continue ;-)
>=20
> P.S. Ross, I think rollback to old version is not necessary. It is
> better to add _some_ necessary changes to HEAD branch (I like new
> MDI ;-) ). I will begin from preferences dialog and plural forms data.
>=20

Fantastic!

> P.P.S. I will be repeated " patches code is terrible!". Tear me on
> parts ;-)

Not so bad really. I can see that it's an improvement (at least, the CVS
HEAD one that I've reviewed so far). I just need to work out a ChangeLog
for it, and then I can commit it.

Thanks!

--
Ross

[Gtranslator-devel] Patches

[<v.k...@sa...>]

hi all!
I spent a certain time on the addition of functionality for gtranslator
which necessary to me. The majorities of corrections are necessary for
working with the plural forms. But since as always I experienced
deficiency in the time, all patches were written as the rapid solutions.
One after one, and came out the very bulky and terrible code. Therefore
I decided to here present some considerations on an improvement in the
program. Together solve them will be more simply.

I. Translation statuses which usable for translators (by my translation
experience):
1.message cannot have status "fuzzy" if it not translated
2.messages which contains plural forms can have status:
  - translated, if all messages are translated. 
  - untranslated, if all messages are not translated.
  - fuzzy, if one (or more but not all) message is translated
    or comment contains "# ,fuzzy" flag.
3. Stiky messages is a good idea. ;-)
Satisfaction of all these conditions will help translators more simply
to be oriented with the translation. These statuses are not obligated to
be present in the gettex library. They may be virtual within the
framework of gtranslator.

II. Built-in data about the plural forms strings for each presented
languages. This is very important point. In time that I am occupied by
localization of applications I very frequently met different
determination for these strings in files of different translators. But
they all this made for _one language_. And this is understandable - the
plural forms are very difficult for the understanding by series user. I
think that these data must be stored either inside our program or inside
the separate library. But better if they are in locale data ;-)
I proposed new language data structure:
/*
* The language structure with all the essential data for gtranslator:
*/
typedef struct {
/*
* 1 - The name of the language (e.g. "Turkish").
*/
gchar *name;
/*
* 2 - The language-code (e.g. "tr").
*/
gchar *locale;
/*
* 3 - The encoding mostly used for the language (e.g. "iso-8859-9").
*/
gchar *encoding;
/*
* 4 - The group's EMail list (e.g. "gno...@gn...").
*/
gchar *group_email;
/*
* 5 - The transfer bit count for the language (e.g. "8bit").
*/
gchar *bits;
/*
* 6 - numbers of plural forms
*/
gint nplurals;
/*
* 7 - plural form string
*/
gchar *plural; 
} GtrLanguage;

And as result language data view as  
GtrLanguage languages[] = {
{
N_("Afrikaans"), "af", "iso-8859-1",
"", "8bit", 2, "(n != 1)"
},


III. File parsing (messages & header). 
For the successful work with the plural forms pre-load of po-header is
necessary. Then header parsing and, if it is necessary, settings of
correct variables for the plural forms. 
Then each message must be parsed with criterion from point I.
Also on the demand of user and automatically with file saving necessary
checking according to gettext rules. All errors must be hightlighted (as
Kbabel ?).


IV. Better visualization data in translation table.
I think data visualisation and good UI improve translation productivity.
And translation table is good idea. But table must have ability for hide
without restarting application and must be detachable as toolbar.
I made the first steps in this direction. I added small icons into table
nodes and icons for plural form designation. I think that all actions
conducted above the message they must be mapped into table without
delay. Although this is questionable possibility.


V. Better preferences dialog.
Ok, current preferences dialog is terrible. It attempts to engage entire
screen. I divided it by logic units and was used a tree for the
selection (as in firefox, monodevelop etc.). I think this only for the
benefit.


VI. Working with plural forms.
This the fact that forced me to write patches. Logic is simple -
notebook with tabs of which one contains plural form messages. 


to be continue ;-)

P.S. Ross, I think rollback to old version is not necessary. It is
better to add _some_ necessary changes to HEAD branch (I like new
MDI ;-) ). I will begin from preferences dialog and plural forms data.

P.P.S. I will be repeated " patches code is terrible!". Tear me on
parts ;-)

[Gtranslator-devel] Patches

[Vital K. <vk...@al...>]

hi all!
I spent a certain time on the addition of functionality for gtranslator
which necessary to me. The majorities of corrections are necessary for
working with the plural forms. But since as always I experienced
deficiency in the time, all patches were written as the rapid solutions.
One after one, and came out the very bulky and terrible code. Therefore
I decided to here present some considerations on an improvement in the
program. Together solve them will be more simply.

I. Translation statuses which usable for translators (by my translation
experience):
	1.message cannot have status "fuzzy" if it not translated
	2.messages which contains plural forms can have status:
	  - translated, if all messages are translated. 
	  - untranslated, if all messages are not translated.
	  - fuzzy, if one (or more but not all) message is translated
	    or comment contains "# ,fuzzy" flag.
	3. Stiky messages is a good idea. ;-)
Satisfaction of all these conditions will help translators more simply
to be oriented with the translation. These statuses are not obligated to
be present in the gettex library. They may be virtual within the
framework of gtranslator.

II. Built-in data about the plural forms strings for each presented
languages. This is very important point. In time that I am occupied by
localization of applications I very frequently met different
determination for these strings in files of different translators. But
they all this made for _one language_. And this is understandable - the
plural forms are very difficult for the understanding by series user. I
think that these data must be stored either inside our program or inside
the separate library. But better if they are in locale data ;-)
I proposed new language data structure:
/*
 * The language structure with all the essential data for gtranslator:
 */
typedef struct {
	/*
	 * 1 - The name of the language (e.g. "Turkish").
	 */
	gchar *name;
	/*
	 * 2 - The language-code (e.g. "tr").
	 */
	gchar *locale;
	/*
	 * 3 - The encoding mostly used for the language (e.g. "iso-8859-9").
	 */
	gchar *encoding;
	/*
	 * 4 - The group's EMail list (e.g. "gno...@gn...").
	 */
	gchar *group_email;
	/*
	 * 5 - The transfer bit count for the language (e.g. "8bit").
	 */
	gchar *bits;
	/*
	 * 6 - numbers of plural forms
	 */
	gint nplurals;
	/*
	 * 7 - plural form string
	 */
	 gchar *plural; 
} GtrLanguage;

And as result language data view as  
GtrLanguage languages[] = {
	{
	 N_("Afrikaans"), "af", "iso-8859-1",
	 "", "8bit", 2, "(n != 1)"
	},


III. File parsing (messages & header). 
For the successful work with the plural forms pre-load of po-header is
necessary. Then header parsing and, if it is necessary, settings of
correct variables for the plural forms. 
Then each message must be parsed with criterion from point I.
Also on the demand of user and automatically with file saving necessary
checking according to gettext rules. All errors must be hightlighted (as
Kbabel ?).


IV. Better visualization data in translation table.
I think data visualisation and good UI improve translation productivity.
And translation table is good idea. But table must have ability for hide
without restarting application and must be detachable as toolbar.
I made the first steps in this direction. I added small icons into table
nodes and icons for plural form designation. I think that all actions
conducted above the message they must be mapped into table without
delay. Although this is questionable possibility.


V. Better preferences dialog.
Ok, current preferences dialog is terrible. It attempts to engage entire
screen. I divided it by logic units and was used a tree for the
selection (as in firefox, monodevelop etc.). I think this only for the
benefit.


VI. Working with plural forms.
This the fact that forced me to write patches. Logic is simple -
notebook with tabs of which one contains plural form messages. 


to be continue ;-)

P.S. Ross, I think rollback to old version is not necessary. It is
better to add _some_ necessary changes to HEAD branch (I like new
MDI ;-) ). I will begin from preferences dialog and plural forms data.

P.P.S. I will be repeated " patches code is terrible!". Tear me on
parts ;-)

Re: [Gtranslator-devel] cvs

[Ross G. <ro...@go...>]

On Fri, 2004-09-10 at 06:46 -0300, Jo=C3=A3o Paulo Vanzuita wrote:
> gtranslator doesn't have CVS ?
>=20
> i sent a patch, but doesn't sent the changelog, i already need to write=
 on changelog or it already have been done ?
>=20

I added one for you when I committed your patches. See:

http://cvs.gnome.org/viewcvs/gtranslator/src/ChangeLog?
rev=3D1.936&view=3Dmarkup

However, it's easier for me if you send a patch containing your own
ChangeLog entry ;)

Cheers,

--
Ross

[Gtranslator-devel] cvs

[P. V. <joa...@te...>]

gtranslator doesn't have CVS ?

i sent a patch, but doesn't sent the changelog, i already need to write on changelog or it already have been done ?

Re: [Gtranslator-devel] very small patchs

[Ross G. <ro...@go...>]

On Wed, 2004-09-08 at 10:15 -0300, Jo=C3=A3o Paulo Vanzuita wrote:
> hello, I'm Jo=C3=A3o Paulo, from Brazil, and a like this project too mu=
tch, i
> always wanted to help with something, already translate it to my
> language, and now trying to help with code, this two patchs don't have
> nothing with code, but some few bugfix.


Thanks for the patches.

The first patch looks fine, and I'll commit it to CVS shortly. In fact,
I'm considering whether or not *all* languages should use 'UTF-8' in
that table. Internally, gtranslator should treat all strings as UTF-8,
and (IMHO) should read/write them to/from the po file using whatever
character set is specified in the header (which should typically be UTF-
8 anyway).=20

I've just seen that Bruno Haible (gettext maintainer) has started
committed patches to gettext which will be necessary for gtranslator to
start  use libgettextpo for po file reading/parsing. Hopefully, it
shouldn't be too long before I can start hacking gtranslator to use it.
I'm looking forward to it.

The second patch is already in CVS.

Cheers,

--
Ross

[Gtranslator-devel] very small patchs

[P. V. <joa...@te...>]

hello, I'm João Paulo, from Brazil, and a like this project too mutch, i
always wanted to help with something, already translate it to my
language, and now trying to help with code, this two patchs don't have
nothing with code, but some few bugfix.

[Gtranslator-devel] [Fwd: [gtranslator - Open Discussion] Does not display my locale enabled font]

[Fatih D. <ka...@ka...>]

Hmmm....


-------- Original Message --------
Subject: [gtranslator - Open Discussion] Does not display my locale 
enabled font
Date: Tue, 07 Sep 2004 07:10:11 -0700
From: SourceForge.net <no...@so...>
To: no...@so...


Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=2747543
By: nobody

Hi,
I try to translate some PO files into Persian (RTL and Arabic 
characters) with
Arial which is a Persian enabled font but the gtranslator does not 
display it!
In gedit it does work perfectly but not in gtranslator. I get nothing when I
write. I have specified Arial under settings - preferences and font & 
colors!
Any idea?

Re: [Gtranslator-devel] Mailing list move?

[Ross G. <ro...@go...>]

OK, the wheels are in motion.

Please expect a 'you are now subscribed to gtr...@gn...'
e-mail to arrive in the next few days (if I don't get any objections to
it from the gnome.org side).

Regards,

--
Ross

On Sun, 2004-08-08 at 14:23 +0200, Fatih Demir wrote:
> Nope, if you care to take over mailing list membrs :-)
> 
> 
> 
> 
> Ross Golder wrote:
> > Hi all,
> > 
> > It seems a bit odd that we use bugzilla.gnome.org for bug tracking and
> > cvs.gnome.org for CVS, but we still use sf.net for mailing lists (and
> > file releases). So, I would like to move the gtranslator-devel mailing
> > list over to the GNOME.org servers. Can anyone see any problems with
> > this?
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> gtranslator-devel mailing list
> gtr...@li...
> https://lists.sourceforge.net/lists/listinfo/gtranslator-devel

Re: [Gtranslator-devel] Mailing list move?

[<to...@us...>]

On =D0=BD=D0=B5=D0=B4, 2004-08-08 at 01:21, Ross Golder wrote:
> It seems a bit odd that we use bugzilla.gnome.org for bug tracking and
> cvs.gnome.org for CVS, but we still use sf.net for mailing lists (and
> file releases). So, I would like to move the gtranslator-devel mailing
> list over to the GNOME.org servers. Can anyone see any problems with
> this?

Of course not. SF uses older mailman version which makes problems with
signatures in Evolution. So, go ahead. Move!
:)

Re: [Gtranslator-devel] Mailing list move?

[Fatih D. <ka...@ka...>]

Nope, if you care to take over mailing list membrs :-)




Ross Golder wrote:
> Hi all,
> 
> It seems a bit odd that we use bugzilla.gnome.org for bug tracking and
> cvs.gnome.org for CVS, but we still use sf.net for mailing lists (and
> file releases). So, I would like to move the gtranslator-devel mailing
> list over to the GNOME.org servers. Can anyone see any problems with
> this?

[Gtranslator-devel] Mailing list move?

[Ross G. <ro...@go...>]

Hi all,

It seems a bit odd that we use bugzilla.gnome.org for bug tracking and
cvs.gnome.org for CVS, but we still use sf.net for mailing lists (and
file releases). So, I would like to move the gtranslator-devel mailing
list over to the GNOME.org servers. Can anyone see any problems with
this?

Cheers,

--
Ross

[Gtranslator-devel] Re: Expanding gettext-po.h

[Ross G. <ro...@go...>]

On Wed, 2004-01-28 at 11:44 +0700, Ross Golder wrote:
> Hi GNU gettext people,
> 
> I'm interested in expanding the public API for GNU gettext to include
> the ability for applications to re-use gettext's PO file parsing code,
> and record structures.
> 
> I'm a maintainer of gtranslator, a GNOME front-end for translators to
> edit PO files. I'd like to rewrite the parser code and message structure
> use to use gettext's 'official' structures and code, as it will
> hopefully make the application smaller, more reliable and easier to
> maintain. I'd also eventually like to port this application to my iPAQ,
> where preventing code duplication between applications is far more
> important in order to conserve memory. I can also see it being useful
> for other applications that manipulate PO files.
> 
> I'm not expecting to change or break any API-compatibility, simply add
> the necessary structures and functions so that they're available via the
> gettext-po.h header and libgettext-po.so library files.
> 
> Does anyone have any issues with this? Should I just submit patches
> against the most recent tarball, or should I work from CVS somewhere?
> Who should I send patches to?
> 

Hi,

I've got something a bit more concrete to propose now. Please see the
attached patch. Unfortunately, this approach breaks API compatibility
slightly (for the better, I hope).

Basically, it adds a '**errptr' argument to the read_po and read_po_file
functions. If the 'read_po' or 'read_po_file' functions return with
errptr not NULL, the calling application should handle the error and
free the memory at errptr.

The point is to move the error handling back up the stack to the calling
program, and not have calls to the 'error' function (which calls 'exit')
within the parser itself. This way, applications are responsible for
handling the errors. In the case of command-line programs, like the msg*
programs, they simply call 'error' further up the stack. In my
development branch of gtranslator, it will pop up a GNOME dialog
explaining the problem.

I'd like to submit this patch first for evaluation, discussion,
refinement or whatever is required to get it back into the mainstream
gettext releases.

After this, I'd like to work out some kind of callback mechanism whereby
the parser can feed errors back to the calling program (rather than just
dumping to stderr, as it does now). The msg* programs could have a
simple handler for dumping to stderr as before, and GUI programs could
display them in a dialog, as required.

And finally, I will need to examine the 'write-po' stuff, and do a
similar exercise making sure there are no 'exit' calls lurking in there,
and that errors writing the po file are passed back up the stack to the
calling application.

Also, applications will need to be able to find and include various
gettext headers. For this, I've got patches that install a handful of
headers in '$(includedir)/gettext-0.0'. This seems to be sufficient for
gtranslator to find them by doing '#include <gettext-0.0/messages.h>'
etc. Is this a good approach, or could this be done better?

I've also created a gettext-tools/test/read-write.c which simply parses
a po file into memory using the parser (read-po.c), and writes it out
using the writer (write-po.c). Would this be considered a useful test?

Comments please! :)

Regards,

--
Ross

Re: [Gtranslator-devel] gtranslator & modal dialog

[Andre L. <a.l...@gm...>]

Done, thanks.

Andre

Ross Golder wrote:
> On Thu, 2004-08-05 at 18:44 +0200, Andre Lerche wrote:
> 
>>[...]
> Hi,
> 
> Thanks. This sounds like it could well be a bug in gtranslator.
> 
> It would be very helpful if you could file a bug report about it under
> the 'gtranslator' category at bugs.gnome.org to ensure it gets tracked
> properly.
> 
> Thanks,
> 
> --
> Ross
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> gtranslator-devel mailing list
> gtr...@li...
> https://lists.sourceforge.net/lists/listinfo/gtranslator-devel
> 
> 

Re: [Gtranslator-devel] gtranslator & modal dialog

[Ross G. <ro...@go...>]

On Thu, 2004-08-05 at 18:44 +0200, Andre Lerche wrote:
> Hi,
> 
> using gtranslator 1.0.2 I was facing an issue recently and thought that 
> it's a bug with my windowmanager xfwm4, but the xfwm4 side has 
> enlightened me that it's a gtranslator issue.
> 
> Any chance to change this behaviour, cause it's really annoying that the 
> popup window is opened behind the root window ? These are all necessary 
> items from my original bug report:
> 
> Summary: Issues with gtranslator
> Description: 	Using current CVS head, when I open gtranslator (version 
> 1.0.2) with an existing po-file, it opens a dialog window where I can 
> edit the header of the po file. This dialog window is opened behind the 
> root window and not in the foreground as it should.
> 
> Solution from one of the core xfwm4 developers:
> 
> The problem comes from gtranslator that maps a modal dialog before the 
> window for what it's modal. xfwm4 checks for such a case and ignores the 
> modality in that case.
> 
> Another problem is that, since the dialog is mapped before the main 
> window, the transient field is updated afterwards. That was not 
> supported in xfwm4 because that could cause some trouble if a window 
> specifies another window that has already a transient relationship, like 
> e.g.:
> 
> A transient for B transient for C transient for A

Hi,

Thanks. This sounds like it could well be a bug in gtranslator.

It would be very helpful if you could file a bug report about it under
the 'gtranslator' category at bugs.gnome.org to ensure it gets tracked
properly.

Thanks,

--
Ross

[Gtranslator-devel] gtranslator & modal dialog

[Andre L. <a.l...@gm...>]

Hi,

using gtranslator 1.0.2 I was facing an issue recently and thought that 
it's a bug with my windowmanager xfwm4, but the xfwm4 side has 
enlightened me that it's a gtranslator issue.

Any chance to change this behaviour, cause it's really annoying that the 
popup window is opened behind the root window ? These are all necessary 
items from my original bug report:

Summary: Issues with gtranslator
Description: 	Using current CVS head, when I open gtranslator (version 
1.0.2) with an existing po-file, it opens a dialog window where I can 
edit the header of the po file. This dialog window is opened behind the 
root window and not in the foreground as it should.

Solution from one of the core xfwm4 developers:

The problem comes from gtranslator that maps a modal dialog before the 
window for what it's modal. xfwm4 checks for such a case and ignores the 
modality in that case.

Another problem is that, since the dialog is mapped before the main 
window, the transient field is updated afterwards. That was not 
supported in xfwm4 because that could cause some trouble if a window 
specifies another window that has already a transient relationship, like 
e.g.:

A transient for B transient for C transient for A

Thanks,

Andre

Re: [Gtranslator-devel] [Fwd: [gtranslator] prefs.c patch]

[Ross G. <ro...@go...>]

Looks reasonable to me. Committed to both HEAD and 'gettext-hack'
branches.

--
Ross

On Thu, 2004-07-29 at 20:44 +0200, Fatih Demir wrote:
> Hmm?!?!
> 
> What do you say about it?!?
> 
> 
> 
> -------- Original Message --------
> Subject: [gtranslator] prefs.c patch
> Date: Thu, 29 Jul 2004 17:42:41 +0200
> From: Emmanuel Saracco <esa...@no...>
> To: Fatih Demir <ka...@ka...>
> CC: ka...@us...
> 
> hi,
> 
> here is a tiny patch to prevent preferences dialog for displaying
> anoying validation popups when one change something but do not want to
> save it, or when one just checked/unchecked a toogle button (with no
> modification) and just want to cancel the dialog.
> 
> do whatever you want with it :-)
> 
> thanks for your work,
> 
> bye
> 

Re: [Gtranslator-devel] gtranslator plural forms/PO file parsing

[Ross G. <ro...@go...>]

On Thu, 2004-07-29 at 14:08 +0100, Ross Golder wrote:
> IMHO, it would be more appropriate to spend the time librarising
> gettext, and making exposing all the file reading/writing code (and the
> 'message.h' structure etc) from there. 

Yay! It compiles and works against gettext, but still has a few known
problems. The adventurous may wish to download a small patch to gettext-
0.14.1 that gets it to install a few extra header files (therefore
exposing it's parsing/writing code).

http://www.golder.org/~rossg/tmp/gettext-0.14.1.exposed.patch

Then, check out the 'gettext-hack' branch of gtranslator CVS. All just
proof-of-concept stuff atm, but you can basically open a PO file in the
GUI. Gettext still needs some tidying up wrt error handling etc before
it'll be stable and usable, and I'll have to get the patch in upstream
somehow.

Still, at least it's progress.

--
Ross

[Gtranslator-devel] [Fwd: [gtranslator] prefs.c patch]

[Fatih D. <ka...@ka...>]

Hmm?!?!

What do you say about it?!?



-------- Original Message --------
Subject: [gtranslator] prefs.c patch
Date: Thu, 29 Jul 2004 17:42:41 +0200
From: Emmanuel Saracco <esa...@no...>
To: Fatih Demir <ka...@ka...>
CC: ka...@us...

hi,

here is a tiny patch to prevent preferences dialog for displaying
anoying validation popups when one change something but do not want to
save it, or when one just checked/unchecked a toogle button (with no
modification) and just want to cancel the dialog.

do whatever you want with it :-)

thanks for your work,

bye

-- 
Emmanuel Saracco
http://emmanuel.saracco.free.fr/

[Gtranslator-devel] gtranslator plural forms/PO file parsing

[Ross G. <ro...@go...>]

http://bugzilla.gnome.org/show_bug.cgi?id=123528

First, my apologies for this being outstanding for so long. I've been
meaning to get round to doing this for a very long time now, and every
time I sit down to do it, I come up against the same dilemma. I think
this time, I should ask for some advice, or seek some kind of
confirmation that I'm on the right track.

To fix this, the message structures and the PO file reading and writing
routines need to be updated to handle plural forms (better). Currently
the PO reading and writing routines in gtranslator are fairly crude (in
comparison to the way the gettext library reads and writes PO files).
IMHO, gettext does this job in a much more 'proper' fashion. However,
gettext's external library API doesn't expose much (it's really crap)
and can't be used directly.

IMHO, it would be more appropriate to spend the time librarising
gettext, and making exposing all the file reading/writing code (and the
'message.h' structure etc) from there. I've currently got my head buried
in the gettext source code (and am learning quite a bit about flex!),
with this aim in mind. I mentioned it once to the gettext developers on
their mailing list, but I didn't have anything concrete, and I didn't
hear anything back. If this is an achievable goal, I can think of at
least the following benefits:

- All of gtranslator's file parsing/writing bugs could be squashed in
one hit
- gtranslator could become a GUI front-end to the all the msg* tools,
reducing the need for translators to become familiar with using a shell
- General benefits of code re-use, savings in developer time and memory
footprints etc (gtranslator on the ipaq? when?)
- gettext seems to have the ability to write out more than just PO files
(e.g. Java '.properties' files and other formats). We'd get to leverage
that flexibility too.
- knock-on effect - gettext becomes more modular

I appreciate that for most gtranslator users, a quick-fix would be
preferable and would make life easier for them when translating PO files
with plurals in. However, I've only got time to follow one path, and
(unless proven wrong) I feel that the gettext approach is the 'Right Way
(tm)' to do things.

I did ponder the quick-fix way, and (IMHO) step one would involve
updating the GtrMsg struct in messages.h to manage 'msgstr' as an array
of strings, and updating everywhere else in the code that uses 'msgstr'.
I followed this path for a bit, but it turned out to need updates in a
*lot* of places, so I abandoned it for the path of righteousness. If
anyone does go this route, and produces a working patch, it'd still be a
step in the right direction from where we are now, so please send it it.

However, either way we do the file handling, we're still faced with the
second half of the problem... How best to present plural forms to the
user that allows them to update them intuitively.

I haven't spent much time thinking about this, but I'm imagining that
whenever the user browses to a plural message, the translated panel
would split from 1 into x number of horizontal panels, each with one of
the possible translations. Can anyone see any problems with this, or
suggest a better interface? Like I said, I still haven't really thought
that part of it through yet.

So that's my apology for tardiness, and my lame excuse. Comments,
advice, guidance etc on either stage of the problem would be
appreciated.

Regards,

--
Ross

[Gtranslator-devel] Macedonian language

[<to...@us...>]

Hello list,

I noticed there is no "Macedonian" entry in the language selection
(src/languages.c). I've created a patch to fix this. Hope I got it
right. Please apply it so it will show up in the next release.

Kind Regards,
Tomislav

Re: [Gtranslator-devel] gtranslator freezes during command line autotranslate

[Ross G. <ro...@go...>]

On =E0=B8=9E., 2004-06-02 at 14:57 -0600, vijay durairaj wrote:
> Hi,
>=20
> When I use gtranslator to autotranslate in command line, it freezes.
>=20
> $gtranslator -a file.po
>=20
> If it cant do any autotranslation, it quits quietly. But, it is able to=
=20
> autotranslate some strings...it translates them and then hangs. I have =
to=20
> kill the job.
> Also, autotranslate works perfectly within the gui interface.
>=20
> I m using Mandrake Linux 9.2  and I tried gtranslator versions 1.0, 1.0=
.2 &=20
> 1.1.5
>=20
> Thanks,
> Vijay Durairaj
>=20
> PS: Sorry, if i am submitting a bug at a wrong place. If this is not th=
e=20
> place to submit the bug, please guide me.

Sounds like a genuine bug to me. Please report it against gtranslator
using the GNOME bugzilla system:

http://bugs.gnome.org/

Regards,

--
Ross

[Gtranslator-devel] gtranslator freezes during command line autotranslate

[vijay d. <vij...@ho...>]

Hi,

When I use gtranslator to autotranslate in command line, it freezes.

$gtranslator -a file.po

If it cant do any autotranslation, it quits quietly. But, it is able to 
autotranslate some strings...it translates them and then hangs. I have to 
kill the job.
Also, autotranslate works perfectly within the gui interface.

I m using Mandrake Linux 9.2  and I tried gtranslator versions 1.0, 1.0.2 & 
1.1.5

Thanks,
Vijay Durairaj

PS: Sorry, if i am submitting a bug at a wrong place. If this is not the 
place to submit the bug, please guide me.

_________________________________________________________________
Getting married? Find great tips, tools and the latest trends at MSN Life 
Events. http://lifeevents.msn.com/category.aspx?cid=married

Re: [Gtranslator-devel] Release number cock up

[Ross G. <ro...@go...>]

On =E0=B8=A8., 2004-04-09 at 12:01 +0200, Fatih Demir wrote:
> Ross Golder wrote:
> > Sorry for all the confusion.
>=20
> Well, such stuff happens :-) Is the improved plural forms support in th=
e=20
> works? I've just checked out the HEAD branch on CVS, is 1.2.x devel=20
> going on there?
>

Yep. All work is still happening on HEAD.

And if you swap 'in the works' for 'in my head', you'll be right about
the plural forms progress ;) I have a rough idea of what I think needs
to be done, but I need to do a little research on plural forms and then
a little UI hacking to see if it'll actually be a good way to do it or
not.

Regards,

--
Ross