Some suggestions

[Tamás]

Hi, All!

I noticed some small but important features missing from OmegaT+:

1. Mark the already translated segments: This way the translator
easily can find the rest of the work. It would be great to show/hide
the translated or the untranslated segments.

2. Different segment statuses: untranslated, for review, verified or
locked to mark the status of a segment during the translation process.
These statuses could be toggled with a toolbar button.

3. Add a comments field for a document: This would be great to be able
to enter a memo for the currently translated document.

4. Show unprintable characters: It may help to find e.g. the double
spaces between the words.

Cheers,

Tamás

[Raymond Martin]

Hi Tamás,

> I noticed some small but important features missing from OmegaT+:
>
> 1. Mark the already translated segments: This way the translator
> easily can find the rest of the work. It would be great to show/hide
> the translated or the untranslated segments.

This is planned, along with the option to show the original and translation at
the same time for all segments, when both exist.

> 2. Different segment statuses: untranslated, for review, verified or
> locked to mark the status of a segment during the translation process.
> These statuses could be toggled with a toolbar button.

Had some initial plan for somethings like these, but you have some extra
ideas I did not think of yet. A couple of those ideas would be simple to
put in, but others have complications.

> 3. Add a comments field for a document: This would be great to be able
> to enter a memo for the currently translated document.

I sort of had an idea to do something like this, but it was as more of on a
segment basis, only for certain document types (ones that could actual
store the comments), and read only.

Sounds like a good idea, I am just wondering what sorts of issues I am
going to run into trying to implement it?

> 4. Show unprintable characters: It may help to find e.g. the double
> spaces between the words.

Not sure if that would be straightforward to do. You mean to somehow
highlight these characters in the text, right? I wonder if it would be
a problem dealing with different encodings, fonts, etc.

I would suggest that you file ideas that you have as feature requests
on the SF project. Go to the "Develop" section and "Tracker" to
file feature requests, bugs, and so forth. Then when can track them
properly and mark them off when they are finally done. Filing multiple
items might be better than ones with many features mixed, so they
are easier to systematically work on. Thanks.

Regards,

Raymond

[Silvermoon]

Hi,

Yes, I like Tamás' idea better (than mine): being able to color
segments according to their state is much better. In OmegaT you have
coloring for translated and untranslated segments, but having a third
option "review" would satisfy the need we translators have for somehow
marking the text whose translation is troublesome. Though being able
to color some words inside a segment would be even better.

As for the comments, what about having a window with a text area to
write the comments and segment number, then we could later click on
the segment and it would take us there?

[Raymond Martin]

Hi,

> Yes, I like Tamás' idea better (than mine): being able to color
> segments according to their state is much better. In OmegaT you have
> coloring for translated and untranslated segments, but having a third
> option "review" would satisfy the need we translators have for somehow
> marking the text whose translation is troublesome. Though being able
> to color some words inside a segment would be even better.

There will be some coloring for these features, yes. But definitely not
the awful colors they use. And eventually, allow the user to configure the
colors for these things to their liking. My initial inclination is to avoid
the ugly highlighted coloring I have seen in some of the popular commercial
CAT tools. Similar or better features are fine, does not mean they have to look
completely repulsive at the same time. Plus, consideration of ergonomics, like
eye fatigue plays a role when very LOUD colors schemes are used.

I also had the idea of a review/revision mode previously, did not think it
through that far yet. So more ideas about this are needed to make a list
of the absolutely essential features that it would encompass.

>
> As for the comments, what about having a window with a text area to
> write the comments and segment number, then we could later click on
> the segment and it would take us there?
>

I was actually thinking of a bookmarking mechanism, that you would be able to
mark a segment and at the same time add comments. Have to see if I can re-use
or improve functionality from the Documents View table for this. It is lacking
in some functionality, I know.

Anyway, I will try to get most, if not all, of these segment marking
features into the application before 1.0.M4. Probably spreading them
over a few subsequent subversions of 1.0.M3.

Raymond

[Silvermoon]

Hi,


I've been using the software for real jobs for some months now and I
wanted to tell you that the toolbars are a pretty good enhancement,
they really speed up my work.

Now I have another suggestion for the program: a button for enabling/
disabling the "original as translation" option would be good, as this
is an option I keep using for my texts.

Oh, I wanted to ask you something (out of programming curiosity): I am
currently using OmegaT+ AND GNOME, and I noticed that the weird colors
and lines that appear in OmegaT when you use GNOME are absent in this
one; what could be causing this, this problem has been around since
the beginning of the project and nobody there seems to care about it.
I understand your code is based on that, so shouldn't it have the same
problem, why does it not have it, did you use a different set of tools
fo this one's GUI?


Thanks,

[Raymond Martin]

Hi,

> I've been using the software for real jobs for some months now and I
> wanted to tell you that the toolbars are a pretty good enhancement,
> they really speed up my work.

Great!

> Now I have another suggestion for the program: a button for enabling/
> disabling the "original as translation" option would be good, as this
> is an option I keep using for my texts.

I am not sure about that. I think there might be the potential for confusion
or annoyance if that is clicked on/off by mistake when not wanted and the
output TMX is not as expected. I must admit I have not examined all the
possible sources of potential problems with that feature as of yet. It
works and I made some testing for correctness, but since I am not a
translator it is not likely I can see every corner case if I am not using
it regularly in my own work.

There is still more work on the toolbar buttons to do, so maybe it could
be an optional button that a user can enable/disable to make it visible
or not. Or it, and other features, could be on another toolbar that
can be enabled/disabled. Something like that. We'll see...

I would appreciate if you, and anybody else, could report if there are
any problems with the "original as translation" option in practice.
That would help me to narrow down problem situations and put
functionality in place to prevent it.

> Oh, I wanted to ask you something (out of programming curiosity): I am
> currently using OmegaT+ AND GNOME, and I noticed that the weird colors
> and lines that appear in OmegaT when you use GNOME are absent in this
> one; what could be causing this, this problem has been around since
> the beginning of the project and nobody there seems to care about it.

I have not seen this myself; other than checking new features occasionally,
and running on my default choice of Enlightenment desktop, I don't test OmegaT
anywhere else. Hmm, I can't remember if I even have GNOME installed, made
a fresh install on a new hard disk a few months ago and I am not sure if it
was part of the installation.

I have too many application open now to check and logout/login. Maybe later.
Send me a screenshot perhaps.

> I understand your code is based on that, so shouldn't it have the same
> problem, why does it not have it, did you use a different set of tools
> fo this one's GUI?

It could be a number of things, including better programming on my part ;)

When you run OmegaT+ under GNOME is it using the GTK Look and Feel(LaF)?
You probably realize already that you can change this within OmegaT+,
but I am curious whether it comes up using that LaF by default since
I rarely use GNOME. I did check OmegaT+ on Ubuntu and OpenSolaris many weeks
ago, I think it came up with the regular Java LaF, not GTK.

> I understand your code is based on that, so shouldn't it have the same
> problem, why does it not have it, did you use a different set of tools
> fo this one's GUI?

Both use Java, Swing, VLDocking docking desktop, etc.

The difference would be in how they each go about setting up the GUI before it
is displayed to the user at launch time. Both do some things they should not
and neglects to do other things they should in places, impossible to be
perfect. The difference is, in my opinion, that I spent a little more time and
effort to find and fix these issues once I know about them, and even some I
don't know about.

It is very hard to say where the problem is off the top of my head because
there are some many things that could make this happen (although it is
usually something simple when you understand the problem).

Ultimately, I can have a look at what you are talking about, but the
OmegaT people have to fix it. OmegaT+ source code has been available
to look at for as long as it has existed, they just haven't seen the benefit
of it by their own choice.

Cheers,

Raymond

[Silvermoon]

Well, the only possible problems of that kind that I can see are:

1. What you said about my idea.
2. Exactly the same situation, but this time with the coincidence
buttons.

Anyway, the problem you told me with the translation = source button
also happens with the menu. I have noticed that it remembers its
status, so if I forget to deactivate it (regardles of where it is) I
will have problems in my next project, so it's a matter of creating
the habit of checking it. Now, I think it would be much better if the
setting was visible in the main GUI, I would not have to open the menu
and check if it is active or not, as I would see it right away (and it
would be easier to remember). Personally I haven't had any problem
with the match buttons (from 1 to 5), they do not annoy me at all and
I use them ocassionally. I think it's ok and nice to have them there.

Another solution to the potential problem would be having the
translation = source button/option reset to an unselected/disabled
state once the translation is open. That way the translator will
always have to enable it in order to get a 100% in the metrics view.

So far I am very pleased with the translation = source option. It is
extremely useful for me. You see, when you translate some names that
are too local (institutions or places that belong only to your area or
country an have no international presence), sometime it is necessary
to leave names untraslated and provide a rough translation or
explanation in brackets. In this case the translation = option is
absolutely necessary.

[Raymond Martin]

Hi,

> Well, the only possible problems of that kind that I can see are:
>
> 1. What you said about my idea.
> 2. Exactly the same situation, but this time with the coincidence
> buttons.
>
> Anyway, the problem you told me with the translation = source button
> also happens with the menu. I have noticed that it remembers its
> status, so if I forget to deactivate it (regardles of where it is) I
> will have problems in my next project, so it's a matter of creating
> the habit of checking it. Now, I think it would be much better if the
> setting was visible in the main GUI, I would not have to open the menu
> and check if it is active or not, as I would see it right away (and it
> would be easier to remember).

Ah, okay. You are right. It should be immediately visible to a user. I am
thinking of an indicator in the statusbar then, as well as a toolbar button.

> Personally I haven't had any problem
> with the match buttons (from 1 to 5), they do not annoy me at all and
> I use them ocassionally. I think it's ok and nice to have them there.

FYI, I will get around to figuring out how to let the user select which
toolbars are open/closed, in addition to saving the user's placement of them.

> Another solution to the potential problem would be having the
> translation = source button/option reset to an unselected/disabled
> state once the translation is open. That way the translator will
> always have to enable it in order to get a 100% in the metrics view.

Might add an additional selectable option to either leave it at the last
setting or reset to off (not equal), with the default as off.

Regards,

Raymond