Some observations on Felix 1.5.2

[S. Patrick Eaton]

Hello, everyone.

First off, many thanks to Ryan for the many improvements in this
version! It's great to see how rapidly Felix is acquiring useful new
features.

That said, however, I have a few observations I would like to make about
the current version.

1.) But there is no [New] glossary!

In the glossary window, all matches appear with something like this in
the left-hand column:

1.
[E]-[D]-[M]
[New]

2.
[E]-[D]-[M]
[New]

Shouldn't this be something more like this:

1.
[E]-[D]-[M]
[Glossary1]

2.
[E]-[D]-[M]
[Glossary2]

Similarly, "Memory: New" appears in the memory window as well. Shouldn't
this be "Memory: Memory1" (or whatever the memory happens to be named)
instead?

I thought I remembered reading about a fix for this in a previous
version, but perhaps I am mistaken?

---

2.) Search Memory window returns no results

I think the Search Memory command may have actually been added in the
previous version, but I've never been able to get it to work. The Quick
Search and Concordance commands in the same menu work just fine, but
Search Memory merely brings up a search window that shows no results no
matter what search strings are entered (and yes, I've read the listed in
the Search Help section).

I'm wondering if the Search Memory function might not be compatible with
Memory Serves or something....

---

3.) Background color preferences not reflected in glossary window when
changing preference files

In order to make sure I don't mistakenly start translating with the
wrong memories/glossaries, I've created two preference files, one for EJ
translation and another for JE translation. The background color is
supposed to be different for each, to serve as a visual cue to let me
know which I have selected at the moment. When I change the preference
files, I've noticed that the background color changes for the memory
window, but not for the glossary window.

---

4.) Terms that mix languages seem to be missed during translations sessions

I've noticed that, in some cases, terms in the glossary that start in
one language but end in another do not seem to show up in the glossary
window when those terms are found in segments being translated.

Today, for example, I haven't been able to get Felix to show a match for
"CMYK分解," which we have in our glossary as "CMYK separation". This
term comes up normally if I search for it using the Search form in the
Memory Serves interface, but it does not show up in the glossary window
during translation sessions or even if I search for it using the Quick
Search command in the glossary window's Edit menu.

Although I don't have any other specific examples at the moment, I seem
to recall having similar problems with other terms that have characters
from both languages in the source (which happens often in the case of
abbreviations like the one above).

---

Like I wrote above, these are just observations about the current
version, but if anyone has any suggestions about things that can be done
to improve any of these, I would be very glad to hear them.

Best regards,

Sako Eaton

[Charles Aschmann]

S. Patrick Eaton wrote:
> 1.
> [E]-[D]-[M]
> [New]
>
> 2.
> [E]-[D]-[M]
> [New]
>
> Shouldn't this be something more like this:
>
> 1.
> [E]-[D]-[M]
> [Glossary1]
>
> 2.
> [E]-[D]-[M]
> [Glossary2]
>
> Similarly, "Memory: New" appears in the memory window as well. Shouldn't
> this be "Memory: Memory1" (or whatever the memory happens to be named)
> instead?
>
> I thought I remembered reading about a fix for this in a previous
> version, but perhaps I am mistaken?
>
> ---
>
>

Though I had this problem in a previous version, I do not have it with
1.5.2. The glossaries appear properly for each entry displayed as a
match. I do not remember the fix for that problem, but if you search the
archives of this list it might be there.

Charles Aschmann

[Ginstrom IT Solutions]

Thanks a lot for reporting this problems, Sako. I hate having bugs in my software, but I hate even more having bugs that I don't know about!

> From: S. Patrick Eaton [mailto:eaton...@canon.co.jp]
> 1.) But there is no [New] glossary!

> I thought I remembered reading about a fix for this in a previous
> version, but perhaps I am mistaken?

Right, I thought I had fixed it, and closed the ticket on it. But as you found, there are still places where the names of remote memories/glossaries show up as "New." I'll try to have this fixed in the next release.

> 2.) Search Memory window returns no results

Initially, I didn't add support for remote memories, because it would have delayed the feature even more (it took several months to implement as it was...). Although it's inconvenient, you have essentially the same feature from the Web interface in Memory Serves, so I thought it could wait. I will be adding support for remote memories/glossaries in the near future, however.

> 3.) Background color preferences not reflected in glossary window when
> changing preference files

Thanks for pointing out this bug. I've added a ticket, and hope to get it fixed in an upcoming release.

> 4.) Terms that mix languages seem to be missed during translations sessions

I've confirmed this bug. It appears to be limited to Memory Serves, because when I try the same thing in a local glossary, the match is found. I'll try to track down the cause of this.


Regards,
Ryan

=================================
Ryan Ginstrom
Felix Translation Memory Software
sup...@felix-cat.com
http://felix-cat.com/
+81-(0)98-958-1297
=================================

[S. Patrick Eaton]

Thank you for responding to these things, Ryan. (And thanks to Charles
as well for his response!)

Quoting Ginstrom IT Solutions:

>> 1.) But there is no [New] glossary!
>

> Right, I thought I had fixed it, and closed the ticket on it. But as
> you found, there are still places where the names of remote
> memories/glossaries show up as "New." I'll try to have this fixed in
> the next release.

That would be great. At the moment it is not such a big problem, but at
some point we will want to start prioritizing matches from specific
glossaries, so it will be very helpful to be able to see at a glance
which glossary produced which terms.

>> 2.) Search Memory window returns no results
>
> Initially, I didn't add support for remote memories, because it would
> have delayed the feature even more (it took several months to
> implement as it was...). Although it's inconvenient, you have
> essentially the same feature from the Web interface in Memory Serves,
> so I thought it could wait. I will be adding support for remote
> memories/glossaries in the near future, however.

I kind of thought that might be the case. You are right: We can do the
same thing using Memory Serves, so this functionality can wait until you
have a chance to add it.

>> 4.) Terms that mix languages seem to be missed during translations
>> sessions
>
> I've confirmed this bug. It appears to be limited to Memory Serves,
> because when I try the same thing in a local glossary, the match is
> found. I'll try to track down the cause of this.

Great! Thank you.

I couldn't think of very many examples yesterday (apart from the one I
mentioned), but we have a lot of terms like this that are not being
picked up during translation sessions.

Examples include the following:

AFカスタム機能
AEB撮影
CFカード
C.Fn設定
HDMIミニ出力端子
ISO感度
JPEG画像
WBブラケッティング

At the moment, I don't think any of these terms are being picked up
correctly, so if you could fix this bug for us, that would immediately
make our glossaries much more useful.

Best regards,

Sako Eaton

[S. Patrick Eaton]

Hello, again.

This afternoon I encountered some additional oddities that I thought I
might pass along for consideration/discussion. Both of these relate to
registering terms after recording new translations.

1.) Color-related behavior in the Add Glossary Entry window

This issue has two parts.

Part 1: Record Source and Record Translation copying behavior differs

This afternoon I translated a sentence that was written in red. After
recording the translation and clicking the Register Glossary link in the
memory window, the Record Source and Record Translation both appeared in
red in the Add Glossary Entry window.

After highlighting a term in the Record Source and clicking the Source
button to move it over to the Glossary Source side of the window, the
term appeared in red as you would expect, appearing like this in the
Source tab:

<FONT color=#ff0000>プリンタドライバ</FONT>

The same thing did not occur, however, when clicking the Trans button to
move a highlighted term from Record Translation to Glossary Translation,
even though the text displayed in the Record Translation area was also
red. In the Glossary Translation Source tab, the translation looked like
this:

printer driver

That was unexpected, but it was actually fine with me. It was the term,
not the color associated with it in this particular instance, that I
wanted to add to the glossary. So I manually removed the <FONT> tags,
leaving the Glossary Source Source tab looking like this:

プリンタドライバ

Upon clicking the Glossary Source Editor tab, however, I noticed that
the term was red again! Sure enough, when I clicked back to the Glossary
Source Source tab, the <FONT> tags were back:

<FONT color=#ff0000>プリンタドライバ</FONT>

I eventually just registered the term that way and edited it later to
get rid of the red color.

Part 2: Once you try red, you never go back?

After registering terms from that first red sentence, I noticed that
subsequent attempts to register terms from other sentences (which were
written in black, not red) also had the text in Record Source and Record
Translation appear in red. In most of these cases, clicking on either
the Source or Trans button resulted in the highlighted text being copied
over in black, so no problem there. Also, clicking on the Source tabs in
either the Record Source or Record Translation areas would show no
<FONT> tags for that particular text, and clicking the Editor tab again
would display the text in the correct color (black).

Why the text originally appears in red in the first place is something I
can't quite figure out.

2.) Advanced Context information never dies

When registering terms from another translation, I clicked the Advanced
button because I wanted to add some information to the Context for that
particular term. After doing so, the same Context information was added
to every subsequent term added to the glossary (using the normal Add
Glossary Entry window, not the Edit Record window you get after clicking
the Advanced button), even though the context was not appropriate for
those terms.

While in the middle of a rush assignment, I just deleted the erroneous
Context information from each new entry after registering them, but now
that I have some time, I find that I cannot delete the text in the
Context area of the Edit Record window! Selecting the text in the Editor
tab and pressing the Delete key does nothing. Selecting the text in the
Source tab and pressing the Delete key results in the following error
message:

---
Failed to edit record.

The entry must not have an empty source.

Please try again.
---

Okay, so it doesn't want to let me make changes to the Context for
records with no Source or Translation. I can understand why that is, but
if that's the case, why does the no-longer-relevant Context information
appear anyway?

Best regards,

Sako Eaton

[Ginstrom IT Solutions]

> From: S. Patrick Eaton [mailto:eaton...@canon.co.jp]

> 4.) Terms that mix languages seem to be missed during translations sessions
>
> I've noticed that, in some cases, terms in the glossary that start in
> one language but end in another do not seem to show up in the glossary
> window when those terms are found in segments being translated.

I think I have found the answer to this. It appears to happen when there's a mismatch between your Felix and Memory Serves preferences. Namely, if you set one of them to normalize case, and the other not.

Please try this: from the Memory Serves web interface, go to the home page, then click "Preferences". Select the "Normalize case" checkbox if it is not selected, clear it otherwise. Next, click "Submit".

Now connect to your remote glossary, and try a search for a sentence containing the string "CMYK分解". It should now work both from Word, and the Felix "Quick Search" feature.

If this does fix it, I'm going to add a ticket so that when Felix does a search on Memory serves, it uses the Memory Serves preferences instead of the local preferences.

[Ginstrom IT Solutions]

> From: S. Patrick Eaton [mailto:eaton...@canon.co.jp]

> Part 1: Record Source and Record Translation copying behavior differs

I think this has more to do with where in the string you selected the text, rather than a difference between the source and translation. If the string you selected is in the middle of red text (there is red text on either side of the selection), then it will be copied as plain text. If your selection extends to the end of the red text or encompasses it, then it will be copied as red text.

You can probably call this a bug (or at least unexpected behavior), and I've had it on my to-fix list for a while. If you copy and paste that same text, it should be done as expected, so the information is in there -- I just need to dig it out.

> Part 2: Once you try red, you never go back?

I've confirmed this. This looks like a side effect of switching from the DHTML edit control to the MSHTML edit control.

I'll look for a way to clean up this behavior.

<grumble>Microsoft depreciated the DHTML edit, which is why I've stopped using it, but after five-odd years it's still more functional than the replacement control in certain ways, when it comes it editing HTML.</grumble>

> 2.) Advanced Context information never dies

The requirement for a source and translation is a stupid error on my part. I re-used the Edit Record dialog for this, and failed to take out the requirement to have a source and translation. That's easily fixed.

The problem with undead context is a little more complicated. Some users want to be able to set a single context value that gets added to all glossary entries they register. Others, like you in this case, just want to add a context value to a single record.

I think I can resolve this conflict by adding a "Make these values the defaults" checkbox.

[S. Patrick Eaton]

Thank you very much, Ryan!

Quoting Ginstrom IT Solutions:

>> I've noticed that, in some cases, terms in the glossary that start
>> in one language but end in another do not seem to show up in the
>> glossary window when those terms are found in segments being
>> translated.
>
> I think I have found the answer to this. It appears to happen when
> there's a mismatch between your Felix and Memory Serves preferences.
> Namely, if you set one of them to normalize case, and the other not.
>
> Please try this: from the Memory Serves web interface, go to the home
> page, then click "Preferences". Select the "Normalize case" checkbox
> if it is not selected, clear it otherwise. Next, click "Submit".
>
> Now connect to your remote glossary, and try a search for a sentence
> containing the string "CMYK分解". It should now work both from Word,
> and the Felix "Quick Search" feature.

That does indeed fix the problem we were having. Normalize case was not
selected before, but now it is and all the terms that start with English
abbreviations are now showing up during translation sessions and when
using the Quick Search feature. That makes our shared glossary much more
useful. Thank you!

Is it safe to assume that the preferences on the Memory Serves side
apply to all users? Is there any reason not to check all three boxes
(Normalize case, Normalize hiragana/katakana, and Normalize width)?

> If this does fix it, I'm going to add a ticket so that when Felix
> does a search on Memory serves, it uses the Memory Serves preferences
> instead of the local preferences.

This sounds like a good idea to me. In cases where it makes sense to do
so, it would be very convenient for the settings on Memory Serves to be
the default for all users.

Now, is there any reason one of our users might want to clear those
settings in the Memory Serves interface? Is that something that should
be permissible? I get the impression that any setting that affects all
users might be best if kept in the administrative interface, rather than
being accessible to anyone, but perhaps there is a good reason to leave
it this way?

Best regards,

Sako Eaton

[S. Patrick Eaton]

Thanks for the response, Ryan!

Quoting Ginstrom IT Solutions:
>> Part 1: Record Source and Record Translation copying behavior
>> differs
>
> I think this has more to do with where in the string you selected the
> text, rather than a difference between the source and translation. If
> the string you selected is in the middle of red text (there is red
> text on either side of the selection), then it will be copied as
> plain text. If your selection extends to the end of the red text or
> encompasses it, then it will be copied as red text.
>
> You can probably call this a bug (or at least unexpected behavior),
> and I've had it on my to-fix list for a while. If you copy and paste
> that same text, it should be done as expected, so the information is
> in there -- I just need to dig it out.

I see. As you note above, this less of a bug than it is simply
unexpected behavior. What I would consider a bug, though, is when I
manually removed the <FONT> tags to get rid of the red text only to have
them come back when I switched back to the Editor tab.

>> Part 2: Once you try red, you never go back?
>
> I've confirmed this. This looks like a side effect of switching from
> the DHTML edit control to the MSHTML edit control.
>
> I'll look for a way to clean up this behavior.
>
> <grumble>Microsoft depreciated the DHTML edit, which is why I've
> stopped using it, but after five-odd years it's still more functional
> than the replacement control in certain ways, when it comes it
> editing HTML.</grumble>

I understand your frustration and don't find this to be a significant
problem, but if you can find a way to clean it up, that would be nice.

>> 2.) Advanced Context information never dies
>
> The requirement for a source and translation is a stupid error on my
> part. I re-used the Edit Record dialog for this, and failed to take
> out the requirement to have a source and translation. That's easily
> fixed.
>
> The problem with undead context is a little more complicated. Some
> users want to be able to set a single context value that gets added
> to all glossary entries they register. Others, like you in this case,
> just want to add a context value to a single record.
>
> I think I can resolve this conflict by adding a "Make these values
> the defaults" checkbox.

I can see how that kind of thing would be useful, so this kind of
checkbox might be very handy.

Thanks, Ryan!

Best regards,

Sako Eaton

[Ginstrom IT Solutions]

> From: S. Patrick Eaton [mailto:eaton...@canon.co.jp]

> Is it safe to assume that the preferences on the Memory Serves side
> apply to all users? Is there any reason not to check all three boxes
> (Normalize case, Normalize hiragana/katakana, and Normalize width)?

Yes, the settings in Memory Serves apply to everyone.
I personally normalize all three. One reason why you might not want to normalize case is when you have proper names and generic words that are only distinguished by capitalization (e.g. a company name Innovative Solutions vs. the phrase "innovative solutions").

> Now, is there any reason one of our users might want to clear those
> settings in the Memory Serves interface? Is that something that should
> be permissible? I get the impression that any setting that affects all
> users might be best if kept in the administrative interface, rather than
> being accessible to anyone, but perhaps there is a good reason to leave
> it this way?

I think you're right: that having them in the admin interface would probably be wiser, because the settings do apply for all users.

(It wouldn't be feasible to let each user have different settings, because that would blow up memory usage; the reason is that a "normalized" version of each source and translation is pre-generated in order to speed up lookups.)