Technical forums » CAT Tools Technical Help »
Pages in topic:   < [1 2]
Recommend a good GUI-based aligner with correction features
Thread poster: Artem Vakhitov
..... (X)
..... (X)
Local time: 04:38
Some additional updates Nov 18, 2015

Hi Artem,

Thanks for trying it out and thanks for the feedback!


- Too much space is wasted for the same UI controls and spacing, yet segment fields are too small for the text, so they get scroll bars and I often cannot see the entire content of the segment without scrolling.

- There are too few segments on the page spaced too far from each other, which hurts readability and the context, something that is extremely important when correcting the alignment results as opposed to editing a TM with a loosely related set of segments.


Good points. I just made some updates to the UI to reduce the font sizes and fit more segments in the view. Here is what it looks like now -

TM-Town Alignment Tool Screenshot


- The initial segment count difference of about 10% got my attention. I looked at the end of the document, and sure enough, it was a mess there with source and target mixed in the target column.


This is due to the target document you uploaded. The end of that document includes a mix of 2 languages. TM-Town is just extracting the text from the document.


- With operations such as segment splitting, the response time of a control was like several seconds—not acceptable.


All operations (move, merge, split, edit) are done on the client side and thus the performance will depend on things such as the browser you are using, the specs of your computer, the number of tabs you have open, etc. (i.e. nothing is being sent to the server), so your mileage will vary depending on your computer and the length of your document.

Kevin
 
Artem Vakhitov
Artem Vakhitov  Identity Verified
Kyrgyzstan
English to Russian
+ ...
TOPIC STARTER
@Kevin Nov 18, 2015

Kevin Dias wrote:

Good points. I just made some updates to the UI to reduce the font sizes and fit more segments in the view. Here is what it looks like now -

TM-Town Alignment Tool Screenshot



This looks better. Is it possible to assign the field height dynamically based on the content or would it take too much computing power in this implementation? Asking because there's still too much vertical white space.


This is due to the target document you uploaded. The end of that document includes a mix of 2 languages. TM-Town is just extracting the text from the document.


Yeah, I added a special update right away. That particular complaint was totally invalid, sorry for that.


All operations (move, merge, split, edit) are done on the client side and thus the performance will depend on things such as the browser you are using, the specs of your computer, the number of tabs you have open, etc. (i.e. nothing is being sent to the server), so your mileage will vary depending on your computer and the length of your document.


I do understand that. It's just that I was evaluating your tool as a possible competition for desktop alignment tools I have used on the same—admittedly, not very powerful— machine, so in that respect, it made sense.
 
..... (X)
..... (X)
Local time: 04:38
@Artem Nov 18, 2015

Hi Artem,


Is it possible to assign the field height dynamically based on the content or would it take too much computing power in this implementation? Asking because there's still too much vertical white space.


This is what the previous version of TM-Town's tool did. It was good for shorter documents (< 400 segments) but could not handle longer documents.

The image I attached in the last post contains mostly very short segments. You had mentioned that you didn't like having to scroll to read the longer segments - so the goal was to find a balance. You're right though, looking at it again there is too much whitespace. I just pushed an update now to reduce the height of the boxes and eliminate more of the vertical whitespace.

Kevin
 
Artem Vakhitov
Artem Vakhitov  Identity Verified
Kyrgyzstan
English to Russian
+ ...
TOPIC STARTER
About dynamical height assignment Nov 18, 2015

Kevin Dias wrote:
Hi Artem,


Is it possible to assign the field height dynamically based on the content or would it take too much computing power in this implementation? Asking because there's still too much vertical white space.


This is what the previous version of TM-Town's tool did. It was good for shorter documents (< 400 segments) but could not handle longer documents.
Kevin


Now that I think about it more like a programmer... Maybe you can introduce paging? Then you would have to calculate segment heights for the visible page only, which shouldn't tax the resources. Or not paging as such, but do that calculation and display only for the segments in the viewport, if the web environment (HTML5, Javascript, CSS etc.) allows doing that locally (I don't know much about these things).

In addition, you could add the concept of the active translation unit and avoid duplicating UI controls, which should free up additional screen real estate. To me, ideally, the segments should go as close as possible to each other, like for instance in SDL Trados Studio editor view.
 
..... (X)
..... (X)
Local time: 04:38
Good suggestions Nov 18, 2015

Hi Artem,

I like your suggestions and ideas. I've thought about paging, but I've avoided it so far as it would introduce a lot of subtle complexity around the user experience. As you mentioned previously it is important to be able to see the context (previous few segments and next few segments) and you would lose that at the end of pages and would require the user to switch back and forth between pages.

The idea of an active translation unit is interesting, but I feel i... See more
Hi Artem,

I like your suggestions and ideas. I've thought about paging, but I've avoided it so far as it would introduce a lot of subtle complexity around the user experience. As you mentioned previously it is important to be able to see the context (previous few segments and next few segments) and you would lose that at the end of pages and would require the user to switch back and forth between pages.

The idea of an active translation unit is interesting, but I feel it would take away some freedom of movement - but maybe not if done correctly.

I think your document is an outlier though for manual alignment. I analyzed the documents that have been aligned to date on TM-Town and the average number of translation units of the aligned document is 242 with the median being only 26 (on a sample of over 3,000 alignments).

Kevin ▲ Collapse
 
Pages in topic:   < [1 2]


To report site rules violations or get help, contact a site moderator:

Moderator(s) of this forum
Natalie[Call to this topic]
Peter Zauner[Call to this topic]
Prachya Mruetusatorn[Call to this topic]

You can also contact site staff by submitting a support request »

Recommend a good GUI-based aligner with correction features







Wordfast Pro
Translation Memory Software for Any Platform

Exclusive discount for ProZ.com users! Save over 13% when purchasing Wordfast Pro through ProZ.com. Wordfast is the world's #1 provider of platform-independent Translation Memory software. Consistently ranked the most user-friendly and highest value

Buy now! »
Protemos translation business management system
Create your account in minutes, and start working! 3-month trial for agencies, and free for freelancers!

The system lets you keep client/vendor database, with contacts and rates, manage projects and assign jobs to vendors, issue invoices, track payments, store and manage project files, generate business reports on turnover profit per client/manager etc.

More info »