#1786 Comment field always show "Comment:" field title even when no comment

[Jean-Christophe Helary]

An INI file with the followinf contents:

"test_string" = "value"

has

Key: "test_string" =

displayed in the Comments pane

but a search on "test_string" with "In comments" checked will not produce a match

[Hiroshi Miura]

Thank you for reporting this issue. However, this appears to be a misunderstanding of how the Comments pane works rather than a bug with the search functionality.

The Facts:

• The "Key:" field you see in the Comments pane is automatically populated from the entry ID, not from an actual comment
• Actual comments are displayed with the prefix "Comment: " when they exist
• When there is no comment (NULL value), no "Comment:" field is shown, which means what you're seeing as "Key: test_string =" is the entry ID, not a comment

Why "In comments" search doesn't match:

The search function is working correctly. It searches for text within actual comment content, not within the automatically generated Key/ID fields. Since "test_string" appears in the Key field (which is metadata) and not in an actual comment, the "In comments" search correctly returns no results.

Resolution:

This is working as intended. The Comments pane displays various metadata fields (ID, Path, Translation) along with actual comments when present. The search "In comments" functionality specifically targets comment content, not metadata fields.

Milestone:

Moving to 6.1 for potential UI improvement to make the distinction between metadata and actual comments clearer to users.

Recommendation:

Consider adding clearer visual separation or labeling in the Comments pane to help users distinguish between auto-generated metadata fields and actual comment content.

[Jean-Christophe Helary]

It is not a misunderstanding on how the comments pane works but a mislabelling of the pane. If it contains metadata that is not "comments" it should not be called "comments".

[Hiroshi Miura]

You get good another view from UI/UX.
You're welcome to contribute this improvement! Please feel free to:

1. Fork the GitHub repository
2. Create a topic branch for this enhancement
3. Open Bundle.properties and locate the key "GUI_COMMENTSWINDOW_SUBWINDOWTITLE_Comments" (around line 1917) and others
4. Update the title entry to better reflect the pane's contents
5. Submit a Pull Request following our standard review process

This would be a valuable contribution to improve the user interface clarity. Looking forward to your PR!

[Jean-Christophe Helary]

Do you agree with my position ?

Another solution would be to not put things that are not comments in the pane.

Did the pane contain metadata that was not comments from the beginning? I am surprised.

(I know how to create a PR. I’ll do that when we reach a conclusion.)

[Hiroshi Miura]

Alex Buloichik had changed the comments pane to show id and path in addition to comment in 12/10/2011 8:55PM 14 years ago.

A commit was "Full entry info(id,path,comment) in the comment pane"

Here is a quote from the version 2.5.0 Update 5 release changes.

 OmegaT 2.5.0 update 5 (2012-01-16)

  Other enhancements:

  - The key is now displayed in the comment pane for all ID-based filters:
Android Resources
Java Resource Bundles
Key=Value Files
Mozilla DTD
ResX
SubRip Subtitles
Windows Resource
WiX

[Jean-Christophe Helary]

Thank you Hiroshi.

• Would you mind telling me how to find that information myself so that I don’t depend on you for it?
• Thank you for the log reference. Ok so we have a UI label that’s not been relevant for 14 years... 😅

That’s obviously an issue. We can’t label the "Comment" pane that way if it also contains stuff that’s not comment. But we can’t have a "Search in comments" if comments are not properly identified and made available.

So, it’s not the pane label that is a problem, but the pane contents. We need to think about that.

[Hiroshi Miura]

Current OmegaT version 6.0 shows ID in Segment Properties pane.

The Segment Properties pane had been added by Aaron in 2016, and released as version 4.0.0
https://sourceforge.net/p/omegat/feature-requests/1198/
https://github.com/omegat-org/omegat/commit/a1075f7bd9070514c2355476c1305c8020ef8e12

Before that, in version 3.x age, ID and Path are only on Comments pane.

I think we can remove the feature that Comments pane shows ID and Path.

[Jean-Christophe Helary]

Good idea. But we can’t remove a feature, so we need to also have the Path in Segment properties.

[Hiroshi Miura]

Does the segment properties pane have a bug not to show Path?

org.omegat.gui.properties.SegmentPropertiesArea.java#334 looks like

    private void setKeyProperties(EntryKey key) {
        setProperty(KEY_FILE, key.file);
        setProperty(KEY_ID, key.id);
        setProperty(KEY_PATH, key.path);
    }

"FILE", "ID", "PATH" seems a default entry in the pane.

[Jean-Christophe Helary]

There are no problems. I misunderstood what you wrote above.

[Hiroshi Miura]

Ticket moved from /p/omegat/bugs/1044/

[Hiroshi Miura]

In search side, o.o.c.s.Searcher#checkEntry has a signature

    protected void checkEntry(String srcText, String locText, String note,
            String[] properties, TMXEntry entry, int entryNum, String intro)

That does not have a SourceTextEntry.key, that is shown as "Key:" in comment pane.

We have an option to add more checkbox "in source ID" in search window and extend the method to search SourceTextEntry#getKey() values.

[Hiroshi Miura]

Is this related or same as https://sourceforge.net/p/omegat/bugs/1018/ ?

[Hiroshi Miura]

Is this issue related or same as here? https://sourceforge.net/p/omegat/bugs/968/

[Jean-Christophe Helary]

yes. It does looks like related issues.