Re: Gtranslator: Present and Future

["Pablo Sanxiao" <psanxiao gmail com>]

Hi:

    I've been speaking with Ignacio quite a bit recently on IRC (in
#i18n on GimpNet) and in our discussions we've come up with a number of
things that should be addressed. I'd like to get the ball rolling and as
such I intend this email to be a very general discussion of where things
are at now and where they're going. (I will stick to talking about the
GOBJECT_WORK branch as that's what I've been working on.)

    It was mentioned earlier today that Pablo had commented on lack of
communication. As such, I think I'll make it my first priority to
address what I've been doing and what my immediate plans are. (I know
I'm not really a dev for gtranslator but I'd like to continue
contributing.) Largely my focus has been making improvements to
functionality that I feel is necessary to my own translation work and
making gtranslator fit in with the GNOME desktop better. To this end,
I've been cleaning up strings and trying to bring the interface together
a little better. For the next little bit, I intend on continuing this
sort of cleanup work. Following is a list of things I plan on doing and
some notes, in no particular order:

It's very important the communication. I was working on the preferences dialog
when you did the commit with the new one therefore I had to rewrite some lines.
This happened because only Nacho and you knew what you were doing.
I'm so glad that you want to improve gtranslator and you did a excellent work with
the preferences dialog. Nacho is opening bugs when he wants to work on something.
That could be a good way of work.

        * Put some sort of distinguishing string in the tabs so that
translators can tell open files apart. Currently, I'm thinking that the
contents of Project-Id-Version in the PO header is a good way to go.
Filenames are too ambiguous. Every file I work on is going to be named
ga.po so having five tabs that all say that won't be helpful.
Project-Id-Version will give at least a semi-unique name to each open file.

I like this idea. It's essential can identify the tabs.

        * Preferences could probably do with a bit of attention. We
should look at key names, contents and location and clean up where
things are stored in GConf. Additionally, we should take stock of which
preferences we really need and see if anything is missing right now. I
plan on getting header related things working shortly unless someone
else is working on this right now. One thing I'd like to address right
now is the necessity of specifying the number of plurals. I think we
should obtain this programmatically from the Plural-Forms string.
Additionally, I'd like to see the Plural-Forms string parsed out so that
we can give the user a hint as to which plural form he's currently
translating for. (Irish has a large number of plural forms and I can't
always remember which corresponds to what. poedit does a nice thing
here.) gettext provides no external API for this, it seems, and their
internal stuff appears to handle things with bison. What do others think
about this?

I'm working on preferences dialog now . I'm implementing the profiles.
You can see bug 115249. When the new feature is done we'll can review the
dialog.

       * The Page Up and Page Down key bindings for next and previous
messages interferes with normal behavior of those keys on the message
table. I accidentally made a commit that killed those bindings (I
removed them locally) so I think this is a good time to bring this up.
Web browsers and various other applications make use of Alt+Left and
Alt+Right to navigate between pages. This seems most intuitive to me but
I'd like to see what others think about this.

I agree,  we must be very careful choosing the keyboard shortcuts to those
things doesn't happen.

    The other thing I'd like to see discussed is plans for release. As
Nacho brought up previously, it seems like a good time to merge
GOBJECT_WORK into trunk. Are there any plans to do anything more than
maintenance and bugfix releases from trunk? If not, work on current
stable could be done out of a branch and work on the next major version
could be done in trunk.

Our plan (Juanjo Sánchez an me) as mantainers is to do a new maintenance release
right now. We're preparing it in branch gtranslator_1_1_8. We hope finish it in a few days.
We fixed some important bugs so that people can use a reliable version of gtranslator
whereas gtranslator 2.0 isn't ready.
After doing the new release we're going to work on new gtranslator 2.0. Before merging
GOBJECT_WORK into trunk we must discuss about the way of work and how to divide the work.

Beyond that, what is still missing from
GOBJECT_WORK before an alpha can be released? We should take stock of
what features are necessary and what needs to be done. We should comment
out all unnecessary, unimplemented features in the UI and try to bring
together something we can release for people to use. My personal list:

       * We need to track when a file has been modified and take
appropriate action.
       * PO headers should be properly written on save. This includes
the PO revision date, as this isn't currently set when we save.

I'm working on that. I've done a commit with the new header dialog and one
function to read the header into an object. Now I have to put the values in the header
dialog and update the header when the file is saved. I''ll try to finish all this part a.s.a.p.

Regards,
             Pablo.