Glossary pane configurable using Groovy

Note. This page describes changes made in DGT-OmegaT 3.2; some more improvements have been done in release 3.4, making the scripting language a little bit different.

Recently a RFE was opened in OmegaT's SourceForge to change the layout of the glossary pane. I answered to it proposing our glossary pane layout to OmegaT 5. As an answer, Didier Briel says that it "should be an option", because of problems on "long descriptions".

We agree that our presentation may cause lot of carriage returns, and for that reason, may use too many space for long lists. For that reason, we thought that the proposal made by another user is not bad at all, this is probably even better compromise that what we did. But then comes the impression that any presentation we could choose would become controversial.

For that reason, we have studied the possibility to make this presentation configurable. We initially thought about using a template, like for the matches pane, but if you want to have the possibility to configure complex cases such as merged entries, the resulting language would have been really complicated (we did implement it and can produce such a version if you don't beleive it!). So, instead, we used a language which is already used inside OmegaT : Groovy.

So, this takes the form of an added configuration zone in the glossary configuration dialog:

As suggested here, in new version DGT-OmegaT update 18, the diferent layouts are in a directory and you see only a combo box: if none of the presentations make you happy, go in the directory scripts/layout/glossary, edit an existing one or write a new one. Actually we do not provide a way to go to the directory and edit the script: use your favorite editor instead. New scripts are visible once you restart the application.

Note: Since this directory is a part of "scripts" directory, the list will only be filled if this directory is correctly configured in the scripting window. Also in the future, make sure you are not using those from a previous version!


Actually available layouts:

result.appendSource(entry.srcText).append(" = ");
def map = entry.translationWithComments
if (map.size() == 1) { 	// keep OmegaT's original presentation in this case
	map.each { 
		result.appendTarget(it.key, entry.hasPriorities(it.key));
		it.value.eachWithIndex { com, j ->
			result.append("\n" + (j+1) + ". ").appendComment(com).append("\n")
		}
	}
} else {
	map.eachWithIndex { e,i ->
		result.append("\n" + (i+1) + ". ").appendTarget(e.key, entry.hasPriorities(e.key));
		e.value.eachWithIndex { com, j ->
			result.append("\n" + (i+1) + ". " + (j+1) + ". ").appendComment(com).append("\n")
		}
	}
}
result.append("\n");

Cybersecurity = Cibersegurança
1. Exemple

IN = 
1. IN
1.1. Abbreviation
1.2. Sigle
2. Indiana
The original presentation of DGT-OmegaT, making distinction between non-merged and merged entries
result.appendSource(entry.srcText).append(": ");
def map = entry.translationWithComments
def count = map.size() - 1
map.each { tra,commentsList -> 
	result.appendTarget(tra, entry.hasPriorities(tra));
	for (com in commentsList) {
		result.append("\n -> "); result.appendComment(com); 
	}
	if (count-- > 0) result.append(",");
}
result.append("\n\n");

citizen: cidadão
 -> Singulier
 -> Nom,cidadãos
 -> Pluriel

citizens' summary: resumo para o cidadão

summary: epítome,extrato de conta,nota de síntese,resumo,sumário,síntese

A presentation very similar to this, but without origin, for the moment.

We have set it as a default.

result.appendSource(entry.srcText).append(": ");
def map = entry.translationWithComments
def count = map.size() - 1
map.each { tra,commentsList -> 
	result.appendTarget(tra, entry.hasPriorities(tra));
    if (commentsList.size() > 0) {
        result.append(" (");
	    for (com in commentsList) {
		    result.appendComment(com).append ("; "); 
	    }
        result.append(")");
    }
	if (count-- > 0) result.append(",");
}
result.append("\n\n");

citizen: cidadão (Singulier; Nom; ),cidadãos (Pluriel)

citizens' summary: resumo para o cidadão

summary: epítome,extrato de conta,nota de síntese,resumo,sumário,síntese

The same, a little bit compacted

result.appendSource(entry.srcText).append(" = ");
def map = entry.translationWithComments
def count = map.size()
map.keySet().each { 
	result.appendTarget(it, entry.hasPriorities(it));
	if (count-- > 1) result.append(",");
}
map.keySet().eachWithIndex { e, i ->
	map[e].each {
		result.append("\n" + (i+1) + ". ").appendComment(it)
	}
}

result.append("\n");


citizen: cidadão,cidadãos
1. Singulier
1. Nom
2. Pluriel

citizens' summary: resumo para o cidadão

summary: epítome,extrato de conta,nota de síntese,resumo,sumário,síntese

The presentation actually used by OmegaT.

Note the presence of two loops, making comments totally unlinked with the translations.

Note the fact that this is absolutely not incompatible with use of colors: that is the reason why, inside the script, you must use result.appendSource, result.appendTarget and result.appendComment instead of simple result.append. And priorities are also supported, either by adding boolean parameter to appendTarget/appendComment, or by calling result.markBoldStart() / result.markBoldEnd().

We are prefectly conscient that this language is not simple. But the problems it is designed to solve are not simple at all. And this is something we do not change every day: if we later implement this in standard OmegaT, we have no doubt that people who are able to write such a script will share with others, and most users will only choose one of the existing ones instead of trying to write their custom one. Now the correct question is not whenever this language is the good solution, but whenever it is possible to make this window highly configurable without making the configuration screen difficult to use. The question remains open.

 

Comments

Hi Thomas,
thank you for liking or even considerung my suggestion. I was afraid I was making a fool of myself ;-)

I downloaded update 18 and played around with it a bit.

If I may, I have two remarks:
1. The glossar settings window doesn't behave as it should. When I change the size of the window, everything enlarges as well, except the coding/scripting zone. This is not even adjustable, it just remains a very narrow space. This makes scripting very unpleasant.
2. The glossary pane when editing, doesn't behave well when scrolling.
It keeps jumping back to the top, no matter how I scroll.

Best Regards
Konstantin

PS
I hope Didier and everyone else are not mad at me for posting this here, when I could/should post it on the DGT Site.

Hi all

I finally published version 3.0 update 18, where layout scripts are in a dedicated directory, as suggested by Konstantin.
You can test and tell me if this feature would be acceptable like that.

About point 1. As I said, this was mainly experimental so I did not take care about the visual aspect. Now that scripts are in a drop-down list instead of big editable text area, you should not have anymore reason why to increase the size of this window.
About point 2, I did not success to reproduce it. For me, it goes back to the top only when I change segment, in which case the list of glossary entries is totally new, that's why it makes no sense to stay where it was before. But maybe it is another use case? Is it a problem specific to DGT-OmegaT or do you have the same with OmegaT 3.6 or 4.1? Did you encounter it in previous versions?

Regards
Thomas

Hi Thomas,

I just downloaded update 18 and here are my comments:

When I go to the glossary pane settings, there is only one entry in the drop-down list ("hardcoded default"). The other files included in the layout-subdirectory are not listed. It seems the script doesn't read this subdirectory.

about point 2. of the previous posting

To reproduce it, you need a larger list in the glossary pane, if necessary make the pane shorter in order to make scrolling possible/necessary.
It is a problem specific to DGT-OmegaT only.

Best Regards
Konstantin

> When I go to the glossary pane settings, there is only one entry in the drop-down list ("hardcoded default"). The other files included in the layout-subdirectory are not listed. It seems the script doesn't read this subdirectory.

Probably a configuration error. Go to Tools->Scripting window and check where does the Scripts folder point to.

> To reproduce it, you need a larger list in the glossary pane, if necessary make the pane shorter in order to make scrolling possible/necessary.

Yes, I understood that the problem can only appear when there is a scroller (question: horizontal or vertical ?)

But I never saw the scroll pane going back to top, except when I go to another segment (which refreshes completely the glossary pane)

Does it occur when you type something? Is your cursor in the editor or in glossary pane?

Thomas

> Probably a configuration error. Go to Tools->Scripting window and check where does the Scripts folder point to.

 

OK so I just did the test and realizes that the application seems to fail interpreting the variable %OMEGAT_DIR%

Will be corrected for the next version.

Where is the download link?

Thank you

Hi Thomas,

1. I am sorry, it was my mistake, I forgot to check the scripts directory under settings. Now the list appears as supposed to.

2. It happens with vertical scrolling. There is no horizontal scrolling bar even when I make the window very narrow.
a. I grab the vertical scroll bar with the mouse and pull it down
b. I keep the mouse button pressed down
c. and still even so, after a second the glossar list jumps to top (the mouse button still pressed down).

Konstantin

"after a second the glossar list jumps to top"

Did you check that the contents changed or if it is the same as before the move?

My hypothesis is the following. When you go to a new segment, a search is done in the glossaries and screen is refreshed. But this operation can be slow, one second is not surprising for me. If in the meantime you used the scroller, once the task is finished the screen is refreshed and moved to the top.

To check this hypothesis, I just published an update 19 where the screen is cleaned in the beginning of the search and filled only once finished. So each time you change segment, there will be a small amount of time (probably 1 second in your case) while the screen contains only the string "Searching...". This version replaces the previous one, so the download link does not change.

In case I am wrong, if you encounter new jumps to the top even when no new searches have been started, then just in case I re-published the previous version here (only the JAR, and only for debug - this will be deleted once we find the solution). Rename the file to OmegaT.jar and replace the existing one in your distribution. Then you are back to update 16, the one before I implemented the configuration using Groovy. Now tell me whenever, in this version, you still have the problem you mentionned. This is for me to know whenever the problem is linked to Groovy or not.

 

Regards

Thomas

 

Hi Thomas,

I am afraid it is becoming a habit of mine lately, telling you I am very sorry all the time...
First of all, my main working system is Linuxmint Mate 18.3 with the latest Oracle Java as default Java.
I downloaded the newest update and tested it. The problem still existed.
Then I had a suspicion that it could be something with Java (or something else on my system) .
So, I put DGT-OmegaT on a clean version of Linuxmint Mate 18.3 with the default openjdk in a Virtualbox as well as on Windows 7 Ultimate (in Virtalbox too) and neither of them had problems with scrolling.
I tested both Versions the one of today and the previous one. Both had no problems.

I am really very-very sorry for wasting your time and for making you coding a new version.
I should have thought of testing it on a clean system earlier.

Thank you for all your efforts and time Thomas.

Best Regards
Konstantin

Hi Konstantin

Thanks for your feedback.

My clients use Windows but I don't remember exactly whenever it is with Oracle JDK or Open JDK. Unfortunately I won't be at work during the two next weeks so no possibility to check.

I keep your messages here as an example of potentially different behaviour between different JDKs.

Regards

Thomas

Hi Thomas,

it has been a while. I am back with a question again. :-)

I want to use your glossary pane on a fresh install of Linuxmint with OmegaT_4.1.5, unfortunately I do not remember at all, if I ever did that half a year back, and if so, how I did it.

Could you please help me out here?
1. Is this possible?
2. What steps do I have to take?

Best Regards
Konstantin

Hi Konstantin

Unfortunately this is not a plugin usable with OmegaT 4.1, this is a feature of DGT-OmegaT (the fork). For the moment all what you can do is to replace (or use for some projects) the fork instead. You can download the last version here (note that only version 3.2 includes this feature)

That is true, however, that this feature came after reading a RFE from standard OmegaT. If you want to have it added in OmegaT 4.1, all what you can do is try to convince Didier Briel about its utility: I am ready to create the equivalent feature for their version, but since I would not be able to add it in their Subversion/Git, I won't do the effort if I am pretty sure that it will never be included.

Reading in the ticket, I now remember that initially it was about including our variant of glossary pane which was initially not configurable. But Didier said that it would accept it only if it is configurable. So you can let him notice that after my modifications it is as configurable as possible, so I could not give a better response.

Regards

Thomas

Add new comment