Menu
▾
▴
2 Attachments
#1386 Alternative layout for glossary pane
Right now, if you have same original term with several translations, these are consolidated in a single view, like this:
If each entry has a note/comment (ie, there is a third column in the TXT for that specific term), the comments are numbered below the entries. I don't think this is really intuitive and would prefer the glossary to display each entry (with its comment) on a separate row. At least, the current view could be optional.
A satisfactory alternative view has been implemented in DGT-OmegaT. See http://185.13.37.79/?q=/node/12 That could be a suitable option to add to the core code.
Related
If it is done, it should be an option, as you mentionned. When you have long descriptions, if you don't have all the target terms on the first line, you only see one or two of them.
Didier
Hi all
I waited a little bit before answering, in order to read other reactions, as well for the ticket or for the discussion in the users list.
First of all, I can tell you that porting what I did for DGT-OT to OT 4 would not be a problem. I remember that this is not true for other aspects of my glossaries (algorithmic part), but about visual part, this is a small set of patches with zero dependency.
But, even if not lot of work, this is work, meaning that I will do it only if I am sure that it has reasonable chances to be integrated.
Reading the discussion in the users list, it appears that most people speak about using colors, while I see other interesting proposals about other aspects. Could we at least have a consensus about this first point? The idea would be to have, as in DGT-OT, a set of 3 colors - one for source, one for translation and one for notes - while the separators (numbers, commas, and so on) would remain in black. Of course, this patch would come with the corresponding lines added in the "colours configuration" pane, meaning that people who don't like that can set all of them to black. This part of the code can be directly taken from DGT-OT, but eventually you can tell me to use different set of colors as default.
About the disposition of elements in the page, if I good understand what Didier says, what he doesn't like in my proposal is the use of carriage returns in all cases, even between terms. That is understandable. In this case, my impression is that this proposal, coming from another user in the list, is a good compromise:
Except for the origin, which is not implemented yet, this presentation would not be difficult to implement. One advantage is that it does not require to make distinction between single glossary entries and merged ones (distinction which I needed to make in DGT-OT). So, this would not need to be configurable.
On the contrary, making things configurable is not so simple: it is difficult to create a configuration window which is at same time easy to understand and with capacity to cover all cases (users may want a different presentation for small and long lists, for example)
In any case, I agree with Marc that the actual disposition can cause confusion: when you have, for one entry, lot of terms but few comments, you are required to manually "count" entries to identify which translation a comment is related to. If you want to keep this presentation, the minimum should be to find a way to make this identification easier: either adding the number in the list, like this:
source = 1. first translation, 2. second translation, 3. third proposal, 4. fourth proposal
or, alternatively, to repeat the translation, like this:
source = first translation, second translation, third proposal, fourth proposal
2 (second translation). comment for second translation
Personally my preference goes to the disposition given in the link (but with colours), I admit that this is even better than what I did for DGT-OT. Now you have all keys to take a decision.
Technically I think it would be nice to separate in 2 patches : one for colours, and one for disposition. But there will be a dependancy between them, because they modify the same part of the code, so we must decide which one comes first.
Regards
Thomas
Last edit: Aaron Madlon-Kay 2019-05-03
FWIW, I would still like each comment following the corresponding term. You can play with font size or weight, making the comment smaller or in italics; you can also separate definitions with a semicolon and put comments in brackets.
Yes, that is the case for my presentation as well as for the one in the link, but not in the original one. I totally agree, but I prefer to be sure that others agree as well before starting to write any piece of code.
Hi all,
I too wanted to post this request for some time now. I am very glad Marco Cevoli did so.
If I may, I would like to support his suggestion. Having made some test-translations with DGT-OmegaT I grew to love most of it's functionalities (mt-directory, glossary, search and replace etc.) and I would love it even more when they get ported to OmegaT in the (very-very) near future.
About the glossary window, I agree with Marco because, for me personally, it is much easier to recognize what is going on there, with just a short glance.
I have to admit, I didn't really understand much about the other (technical) aspects and arguments brought up from Didier and Thomas, but I do hope that, whatever you decide, the glossary window would hopefully look like the DGT's one.
Sincerely
Konstantin
Let's try to summarize.
Marco, Konstantin and me agree that the problem with OmegaT's presentation is that it is difficult to make the link between a comment, identified by translation number, and the corresponding translation in the list (where the number does not appear). Especially when you have lot of translations for one single term, some having comments and some not.
Didier says nothing about that: the question is whenever he understood the problem.
In my side I do not say that the presentation I adopted in DGT-OT is perfect. Not at all. It solves the previously mentioned problem, but it can cause others, such as using too much space, so that you cannot see all translations. That is not wrong, and that is why, after reflexion, I subtain the proposal from another user :
Should it be an option? That is not so easy. Which options would you like to have? I already made colors configurable, but about the layout - how elements are placed one related to another - possibilities are virtually infinite and I am sure that whatever proposal we make, you will always find a reason why not to like it. In case you don't beleive it, I just published a new version of DGT-OmegaT where the glossary pane layout is configurable using a script:
http://185.13.37.79/?q=node/78
I am perfectly conscient that using Groovy for that is not easy for everybody. But this is the only solution I see to have a fully configurable display. If you have a better solution, please let me know and I will study it.
Will it be enough to avoid any polemics? I am not even sure about that. There will always be situations - when you have very long comments, for example - where you will not be able, at the same time, to display the comment without invading the small space of this small glossary pane. Then the solution could be to introduce collapsable zones in the window, like this:
https://www.w3schools.com/howto/tryit.asp?filename=tryhow_js_collapsible
But wanting such a level of configuration, aren't we, finally, definitively making the application very complicated?
Last edit: Aaron Madlon-Kay 2019-05-03
Hi all,
Hi Thomas,
"But wanting such a level of configuration, aren't we, finally, definitively making the application very complicated?"
this is indeed a point that one should try to avoid IMHO, or at least try to keep the current balance of simplicity and functionality that OmegaT has.
Thomas, I looked at http://185.13.37.79/?q=node/78 and I find it very impressive (actually brilliant, you went way further with this).
"I am perfectly conscient that using Groovy for that is not easy for everybody. But this is the only solution I see to have a fully configurable display. If you have a better solution, please let me know and I will study it."
I don't really know if it is feasible, but what if we have a subdirectory e.g. under ~/scripts where we put files with coding for the various presentations and a drop-down selectable list in the glossary configuration zone where one can select the presentation he/she likes for any given project?
You deliver the new version with the 4 presentations you already have, you leave the coding zone for advanced users who are comfortable with scripting and coding, the average users can start with these four and advanced users can code their own presentations and (hopefully) publish them on the OmegaT Plug-In web-page, where anyone can look for them and pick a new one, which they then can copy to this directory, next time the directory is read the new presentation(s) appear in the drop-down list.
This way you do not have to deal with:
"possibilities are virtually infinite and I am sure that whatever proposal we make, you will always find a reason why not to like it",
average users (and beginners) will have more than enough options to start and to live with and advanced users, or people with special wishes, can make their own presentations without having any ground to complain about anything ever again.
I personally would be very happy to see your new version of glossary in OmegaT very soon, I would then create a file, or separate files, where I'll save the 4 presentations you already published and copy and paste the respective code in the coding zone, whenever I want to have a different view.
I wouldn't even need a drop down list, I just mentioned it just in case you want to keep it very simple for "normal" users.
Best Regards
Konstantin
Last edit: Konstantin 2018-06-21
Very good idea! I did not think about this possibility - I am better in thinking about algorithmic part than about GUI and ergonomics! You are true, this is the best compromise - basic users choose in the list, without being conscient that this list is modifiable, and advanced ones would edit the existing scripts or write a new one.
OK, I will try to do like that for update 18. In the meantime you can download and test the update 17 (simply replaced the previous version in download page). Yes for the moment you have to cut/paste the code from the web page, but consider it as temporary, now that you thought exactly the simplification I was searching for...
This does not depend from me. I promised to the core team that I am ready to help for porting all my patches to OmegaT 4, but this does not mean that I will do it if they don't express interest for it. For this particular feature, there is one more constraint: as I said, possibilities are virtually infinite so I need from them the confirmation about what exactly they would have in the next version of OmegaT 4 : probably not my original presentation, if I good understand Didier's reaction, but if we are several people speaking about the Groovy version - with your suggestion applied, of course - maybe we have a chance to convince them...
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:
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.
Last edit: Konstantin 2018-06-21
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:
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
Dear Konstantin, I made a copy of your message in our web site:
http://185.13.37.79/?q=node/78
We can continue the conversation here.
Thomas
This discussion has been brought up as an example in the development mailing list. I was wondering if there are any chances to implement the DGT-OT solution for glossary presentation, as it is (or with any needed modification), because it seems quite evident - to anybody, I'd dare say - that it is an improvement to the current visualization. If there are any steps we can take to make it happen, just comment them here.
As is basically always the case, if there is not movement on an issue you care about, then you will probably have to fund it.
Diff:
Diff:
Diff:
Diff:
I have added linked images inline. Without this it takes a lot of effort to even figure out what we are talking about.
I have no issue with improving the appearance of the glossary pane, but the Groovy implementation seems extremely over-engineered. I applaud Thomas's ingenuity in bending over backwards to try to please everyone, but it's just too much. I think we need to back things up and keep it simple. Offer the following:
The specific layout of the un-consolidated view can be tweaked as users test.
Some remarks here, I try to remain brief.
Now read what I send at same time in the dev list. Sorry to advertise about new version of DGT-OmegaT, but this is only because this is where I implemented the feature we are discussing now, so I prefer that people test them here rather than already converting my patches to OmegaT 4.
Last edit: Thomas CORDONNIER 2019-05-10
I have just found this conversation and I am very glad to see that Thomas CORDONNIER took my original idea and developed it in DGT-OmegaT.
It would be absolutely fantastic if it finally makes its way also in OmegaT, even if it has to be in a simplified form, as Aaron Madlon-Kay suggested.
Any improvement would be more than welcomed.
Thanks everyone for all your efforts!!
Last edit: Diego 2019-07-01
Just for your reference, here I reproduce my original proposal:
In general, I would try to make the Glossary pane resemble more the regular layout of a dictionary:
Last edit: Diego 2019-07-01
I am perfectly aware that in the following I will mix different requests (and, of course, that it would imply a huge amount of programming work), but in my opinion this would be the best way of action for implementig these features (I´ll try to explain my vision as clearly as possible):
1 - In Preferences - Font:
• Allow to change font type and size in every panel (what I refer to as Sections in the image).
• For Glossary, split it in three (Source, Target and Comments).
• Include a CheckBox for just using the same font type and size in the active section as in the Editor pane.
• (Besides) Include a Sample edit box so that the user can change the sample text.
• (If necessary) Include a DropDownList to select the font type and size the user wants for the tables data. Of course, include a Default or System option.
2 - In Preferences - Colours:
• Include 3 more variables, for GlossarySource, GlossaryTarget and GlossaryComments.
3 - In Preferences - Glossary:
• Add a CheckBox for allowing to sort the entries alphabetically (so much needed!!)
• Just add a DropDownList offering some 6 or 7 predefined layouts for the glossary and a sample box on the right to see its characteristics.
One can be the existing one (Clasical).
Other one can be my proposal (Dictionary style).
Other can be the one DGT-OT is currently using, etc.
(This would keep the configuration options simple while still offering a wide range of possibilites).
Last edit: Diego 2019-07-03
Good to know that you agree to "have it simple", as in Aaron's message ;-)
More seriously, your solution is not far from what I propose, in DGT there is already the "layout" combo box (you only change the names, but for me this is nothing else than changing file names so it is easy to do), so I don't consider that using Groovy makes things complicated, since only people who agree with none of the existing layouts will have to know Groovy to modify one of them, most users will simply choose in this box.
It is true that I did not think about font, but I already make the distinction between source, target and comment to apply colors which are configurable (in other terms your point 2 is already implemented), so it would simply mean that my Groovy method addSource would not only apply a color, but also a font.
About possibility to choose which glossary to write, that is another topic but what is sure is that it changes the way OmegaT works: actually it has a notion of "main" glossary which is the only one writeable, and which also has priority when displayed. Since the only possibility is to add (i.e. not modify) entries, I don't see reason why to change this. The more, not all glossary formats are easily writeable (for example TBX).
Last edit: Thomas CORDONNIER 2019-07-04
The glossary origin is now shown as a tooltip, per [#1183].
Related
Feature Requests:
#1183