Pages in topic:   < [1 2]
Recommend a good GUI-based aligner with correction features
Thread poster: Artem Vakhitov

..... (X)
Local time: 20:29
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  Identity Verified
에스토니아
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)
Local time: 20:29
@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  Identity Verified
에스토니아
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)
Local time: 20:29
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:


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

Recommend a good GUI-based aligner with correction features

Advanced search







SDL Trados Studio 2021 Freelance
The leading translation software used by over 270,000 translators.

SDL Trados Studio 2021 has evolved to bring translators a brand new experience. Designed with user experience at its core, Studio 2021 transforms how new users get up and running and helps experienced users make the most of the powerful features.

More info »
CafeTran Espresso
You've never met a CAT tool this clever!

Translate faster & easier, using a sophisticated CAT tool built by a translator / developer. Accept jobs from clients who use SDL Trados, MemoQ, Wordfast & major CAT tools. Download and start using CafeTran Espresso -- for free

More info »



Forums
  • All of ProZ.com
  • 용어 검색
  • 일거리
  • 포럼
  • Multiple search