| Pages in topic: < [1 2 3 4 5] > | DVX versus MemoQ Thread poster: Wolfgang Jörissen
|
|---|
Loek van Kooten wrote: As for Powerling, the address for DVX support, AFAIK, is [email protected] I've already forwarded other complaints about this company to Daniel, and he's looking into it.
In addition to my comments?
| | | | | Thanks, Loek | May 15, 2009 |
Loek van Kooten wrote:
I'll get back to you about that API. Today.
If you can't for whatever reason, that's OK too. I know you always make your best effort, and sometimes there are unavoidable roadblocks.
I actually tried to fiddle with the API for DVX on my own using the object browser in Visual Studio. Perhaps I'm getting old and stupid besides being out of practice as a programmer, but I couldn't make heads or tails of most of the objects and their methods. Usually I can peek inside DLLs and a lot makes sense to me, but I had the feeling I was looking at the aftermath of a cluster bomb falling on a kindergarten. Maybe that's why there is no documentation forthcoming.
[Edited at 2009-05-15 08:29 GMT]
| | | | XX789 (X) 
Netherlands
Local time: 15:05
English to Dutch
+ ...
Yes, I've literally forwarded those.
Please note though that responses (at least from me) are only *guaranteed* if your concerns are posted on the forum. If I ever respond to forums on Proz.com or the DVX mailing lists, it's merely because I spotted something by coincidence.
| | | | XX789 (X)
Netherlands
Local time: 15:05
English to Dutch
+ ...
| Okay, no answer yes | May 15, 2009 |
So I'll stick to my words and say that Atril's support sucks just as much as MemoQ's.
There, I've said it.
| | |
|
|
|
| Hey, it's Friday | May 15, 2009 |
Loek van Kooten wrote:
So I'll stick to my words and say that Atril's support sucks just as much as MemoQ's.
There, I've said it.
They're all human... and all better than You-Know-Who
| | | | Herbert Eppel
United Kingdom
Local time: 14:05
German to English
+ ...
| XX789 (X)
Netherlands
Local time: 15:05
English to Dutch
+ ...
Probably, but I made a promise and I couldn't keep it. I hate that.
| | | | | You're forgiven, but just this once ;-) | May 15, 2009 |
Loek van Kooten wrote:
Probably, but I made a promise and I couldn't keep it. I hate that.
I understand, but no need to look at it in such a binary way, especially when it is something literally out of your control. A good rule: promise nothing and deliver all you can. It won't work when selling translation projects most of the time, but in cases like this it's the best course and one that no one should throw eggs at you for. You've added your voice to the chorus and gone on record as having done so. That's a good contribution in any case.
| | |
|
|
|
XX789 (X)
Netherlands
Local time: 15:05
English to Dutch
+ ...
| Thank you Kevin | May 15, 2009 |
Thank you Kevin, I really appreciate that.
That said, MemoQ got back to me today after having read my responses in this thread. The bugs were confirmed and they promised to fix them promptly. Today the response was absolutely outstanding.
I'm a very demanding user, but once more, I must say I am really impressed by MemoQ, besides the few points I mentioned.
I may even consider using it for certain projects if they manage to speed up the software when lin... See more Thank you Kevin, I really appreciate that.
That said, MemoQ got back to me today after having read my responses in this thread. The bugs were confirmed and they promised to fix them promptly. Today the response was absolutely outstanding.
I'm a very demanding user, but once more, I must say I am really impressed by MemoQ, besides the few points I mentioned.
I may even consider using it for certain projects if they manage to speed up the software when linking really large databases (> 1.000.000 entries). ▲ Collapse
| | | | | Speed issues with databases | May 15, 2009 |
Loek van Kooten wrote:
I'm a very demanding user, but once more, I must say I am really impressed by MemoQ, besides the few points I mentioned.
I may even consider using it for certain projects if they manage to speed up the software when linking really large databases (> 1.000.000 entries).
Demanding is good. That's how things improve. What I see with the Kilgray team is a functioning dialog with the user base where even minor concerns are noted and dealt with if possible. For example, earlier this week I bitched about the fact that erasing the user name when importing termbase entries leads to an error. It doesn't crash the program, but I consider it a programmatic oversight not to put in a dialog demanding that this and possibly other fields be filled. No big deal, really. Well, today I was told that that is fixed in the next build (due sometime very soon, next few days AFAIK) along with a bunch of other stuff. I've been back from Budapest less than three weeks and there have already been at least as many updates. That's positively hyperactive and reminds me of Emilio and how things ran on his watch. It may not last if they hit the big time and can't manage the growth effectively - a common enough corporate disease - but that's the reality now, and I'm going to enjoy it while I can.
As for that database speed thing - my MemoQ Big Mama is smaller than yours (1/3 or 2/3 smaller depending on which files you counted), and it drives me a bit nuts. I am considering splitting it into smaller chunks based perhaps on date or something just to see if the performance improves. If it does I can always merge them later if I want to when/if the performance tuning for size changes.
A comment that one of the Kilgray people made about the TM strategy that many DVX users employ made me think that some of them at least don't really understand the idea behind it. They think it's because DVX Pro is limited to using two TMs. For mea t least, this is not the case. I use that strategy because I can and because the hierarchical classification enables selective application of segments based on subject area and client. I have serious issues with splitting my content up in a bunch of little databases. I don't believe it is as productive, at least not the way I work. So if I do go for the smaller DB strategy, I'll probably chop up the content by date and still keep all the subject areas classified in each database.
**********
Edited for bad grammar as usual....
[Edited at 2009-05-15 20:27 GMT]
| | | | XX789 (X)
Netherlands
Local time: 15:05
English to Dutch
+ ...
Daniel Benito replied:
Given that the API is quite large and not a lot of people use it, what we've ended up doing for customers who request the documentation is to send them the API reference and provide them with specific examples of how to use it depending on what they need (and what programming language they need them in).
That said, what the API allows you to do is to control the DVX engine from an external application, so you can automate a number of processes like creating projects, importing files, generating satellites, etc., but it doesn't really allow you to alter how DVX works internally, so the examples that Kevin cites are not things that you could achieve with the API.
[Edited at 2009-05-18 03:45 GMT]
| | | | | Or rather a non-answer | May 18, 2009 |
That's the most information I've seen to date on the API, and it is useful in an abstract way to know that there is nothing to be done with "internal" functions. Still, "external" functions such as project creation wouldn't be bad to influence since no one has seen fit to provide for templates in a formal way. If exporting is on the "go list" that wouldn't be bad either; it drives me nuts how often I export files to the wrong folder because the export folder is not created on a relative path to ... See more That's the most information I've seen to date on the API, and it is useful in an abstract way to know that there is nothing to be done with "internal" functions. Still, "external" functions such as project creation wouldn't be bad to influence since no one has seen fit to provide for templates in a formal way. If exporting is on the "go list" that wouldn't be bad either; it drives me nuts how often I export files to the wrong folder because the export folder is not created on a relative path to the current project.
Of course, if the API reference had been provided as requested and these issues are in fact documented there, all that would have been perfectly clear. Or perhaps by API reference he means specific documentation on a limited number of objects and methods deemed to be relevant to a specific stated goal. That's not really clear.
No matter. It's apparent that Atril doesn't feel comfortable with supplying the information in the way I had expected given the fact that access to the API was advertised consistently for Workgroup. That's understandable: even fairly well-organized, properly documented APIs can be nightmarish to support as I recall from my days at a German software company which sold "link objects" licenses for its archiving software and had to deal with a lot of support issues as a result. If the information is not freely available it should be removed from the advertising and mentioned only as a negotiable possibility when talking with enterprise accounts, etc.
I agree that the API appears "quite large". I wonder if he would consider it "quite organized". ▲ Collapse
| | |
|
|
|
Herbert Eppel
United Kingdom
Local time: 14:05
German to English
+ ...
| Basic DVX interface shortcomings | May 18, 2009 |
Kevin Lossner wrote:
it drives me nuts how often I export files to the wrong folder because the export folder is not created on a relative path to the current project.
Yes, this is a pain in the neck, and it keeps cropping up time and time again in the DV Yahoo group. I, too, had hoped that the API could be used to overcome such basic shortcomings (another example is the tedious way client and subject information has to be selected compared with DV3). Dare we hope that such interface issues will be resolved in the forthcoming new version?
| | | | | The API docs do exist | May 18, 2009 |
Daniel was kind enough to respond to my request from last December and supply me with the requested documentation in CHM format as well as a few examples. It seems my original request got buried and subsequent mentions of it went unnoticed. No matter; I understand as well as anyone what can happen in a busy life.
Even if the docs do not reveal something useful that I can do directly with them (assuming I still have the skill to do so after years of not programming, which is a very ... See more Daniel was kind enough to respond to my request from last December and supply me with the requested documentation in CHM format as well as a few examples. It seems my original request got buried and subsequent mentions of it went unnoticed. No matter; I understand as well as anyone what can happen in a busy life.
Even if the docs do not reveal something useful that I can do directly with them (assuming I still have the skill to do so after years of not programming, which is a very shaky assumption), they will at least allow me to get some orientation regarding possibilities and speak with some knowledge when a client asks about integration options. The details in the doc do not seem extensive, but the coverage is probably comprehensive, because there is a lot of information there, and in scanning it briefly I saw some useful notes.
So thank you very much to Daniel and the Atril team. ▲ Collapse
| | | | | DVX and MemoQ... | May 31, 2009 |
... are easily the best two TEns around, IMHO.
At first glance they look very similar but in fact you find they are quite different once you start to work with them. They both have their strengths and weaknesses and one does some things better than the other and vice versa.
These are ten things I think DVX does better than MemoQ:
1. DVX's "all files" view with alphabetic sorting, filtering on selection and selecting of rows/segments by status is better than... See more ... are easily the best two TEns around, IMHO.
At first glance they look very similar but in fact you find they are quite different once you start to work with them. They both have their strengths and weaknesses and one does some things better than the other and vice versa.
These are ten things I think DVX does better than MemoQ:
1. DVX's "all files" view with alphabetic sorting, filtering on selection and selecting of rows/segments by status is better than MQ's. In DVX, it's very easy, say, to switch between an alphabetically sorted, all files view, filtered on a source expression and a target expression, and the individual documents in a project open in natural order/sorted alphabetically, with/without filtering on selection, with row status (duplicates only/all empty rows, etc.). In MemoQ you can do the same but it's more laborious (setting up a unified files "view" which has to be closed before you can "open" individual "documents" and vice versa.
2. Lexicon/Lexicon builder. MemoQ doesn't have one, although you could assign an empty termbase in first position and use it as a project-specific glossary. In DVX, Lexicon terms are displayed in white in the AutoSearch box so it's easy to spot them as priority terms.
3. SQL power. MemoQ doesn't provide the user with SQL features. Its intuitive termbase editing/filtering/sorting environment go some way to make up for this.
4. "Nicer" editing environment with drag'n drop and ability to shift words around left/right easily. Editing in MemoQ's grid seems a tad clunky in comparison (no drag'n drop, no keyboard shortcut to move words left/right - this can be done with AHK though).
5. AutoSearch portions sorted in order of appearance in the sentence and not alphabetically. MQ's portions found window is sorted alphabetically. I just can't use it. Fortunately, terms found are highlighted in blue in the grid (and thus in order of appearance), with a tooltip showing the translation.
6. Multilingual/reversible TM's and termbases. You can do an English to French/German/Spanish/Italian job in the same project using just one TM and one termbase/lexicon for all languages. Never understood why agencies didn't go in more for this. MemoQ projects, TMs and termbases are bilingual and one direction only.
7. Real-time autopropagation of translations to all the files in the project. In MemoQ, you have to do pretranslations to update the other files.
8. AutoAssemble and EMBT to turn fuzzy matches into perfect matches. MemoQ has a fragment assemble feature but it's not very ergonomic. For some strange reason, they did away with the F4 fragment assemble button so you have to look for the assembled hit which might be out of sight in position 17.
9. External view feature. Ability to export translated rows to a Word table with comments and then import the proofread/amended EV table directly back into DVX with the grid being updated automatically. MemoQ doesn't have such a feature.
10. Reliability and stability. DVX is a much older product so Atril have had more time to iron out bugs. It seems to take several years to produce a really stable product even with geniuses like the ones at Kilgray.
These are ten things I think MemoQ does better than DVX:
1. User interface simplicity and ergonomic design. MemoQ couldn't be easier to use. The average beginner can get going without outside help. Everything is pretty intuitive. With DVX, you really need to be a power user, be good at reading long manuals or go on a training course.
2. MQ's input/output filters are much faster. In DVX, it can take hours to export a big TM. In MQ, it would usually be a matter of minutes.
3. Wysiwyg grid (bold, italic and underline displayed as such without tags). DVX uses {1}codes{2} for this.
4. Far fewer "rogue" codes or junk tags in the grid. White space trimmed left and right. In DVX, you can end up with code soup with some Word files.
5. Portions found shaded in blue in the grid with a tool-tip display of translations. DVX could do with this.
6. Dynamic translation preview feature displaying the text (Office files at least) as it is actually looks in the outside world and geared to move in sync with the text in the grid. DVX doesn't have this.
7. Translation memory and termbase maintenance environment show source and target side by side in two columns. In DVX, only one target segment is displayed at a time, making editing a real pain.
8. Superior TM and termbase matching (probably a better algorithm with stemming, etc.). Hits seem to be more relevant and intelligent. In DVX, there are too many repeated, unhelpful hits in the AutoSearch box. If the source contains a term like "matching", DVX is likely to propose the target equivalent of "matching", "Matching", "matching:", "MATCHING", "matching?".
9. Easy to use, powerful server version. Atril are still working on their server product.
10. Working XLIFF filter. Atril doesn't have one yet.
[Edited at 2009-05-31 11:23 GMT] ▲ Collapse
| | | | | Pages in topic: < [1 2 3 4 5] > | To report site rules violations or get help, contact a site moderator: You can also contact site staff by submitting a support request » DVX versus MemoQ | Anycount & Translation Office 3000 | Translation Office 3000
Translation Office 3000 is an advanced accounting tool for freelance translators and small agencies. TO3000 easily and seamlessly integrates with the business life of professional freelance translators.
More info » |
| | TM-Town | Manage your TMs and Terms ... and boost your translation business
Are you ready for something fresh in the industry? TM-Town is a unique new site for you -- the freelance translator -- to store, manage and share translation memories (TMs) and glossaries...and potentially meet new clients on the basis of your prior work.
More info » |
|
| | | | X Sign in to your ProZ.com account... | | | | | |
Login to reply/comment 
