In my previous memoQuickie posts on QA profiles and terminology QA as well as a later post with a demo video showing terminology QA in a LiveDocs alignment/editing workflow for a dictated translation, I tried to show how one can create focused QA profiles that can accomplish specific, important tasks like verifying tag integrity or checking a translation against a list of critical, mandatory terminology, but when one of my frequent collaborators called for advice on how to use memoQ to check the integrity and format of more than one hundred footnotes in an OCR document and admitted that she still had not created a custom QA profile for tags and didn't know how, I realized that my approach up to now has probably been a colossal failure.
I keep telling people how easy it is to create some of those custom QA profiles. But why should they have to for common tasks? Why doesn't Kilgray help them out a little with some demo QA profiles than can be used for common tasks, avoiding the "noise" of the point-the-finger-at-everything default profile? After all, there are many demonstration configurations for that LQA feature that is of little or no use to the freelance community. Why not something that would benefit more users?
Well, there are now a few simplified QA profiles available on Kilgray's Language Terminal:
Language Terminal is a community resource with a growing number of features, most of which I haven't blogged about for lack of time. Its future is far more interesting to me than its present, but it currently includes a small but growing library of resources such as custom filter configurations and QA profiles which can help users with certain tasks. It also offers nice online backup integration for memoQ projects and a free InDesign server. The latter can be used by anyone (including those with other tools) to create PDF previews of InDesign files they have received or translated, and the integration of this InDesign server with memoQ desktop projects is expected to increase in the not-distant future.
The three QA profiles (MQRES files which can be imported to your memoQ installation in seconds) are the ones I use most often. "Tags only" allows me to verify that I haven't messed up my target file formatting by leaving out important tags, and "Terminology check" lets me use an approved list of terms to ensure that they are translated as agreed with the client.
The "Empty QA profile" is great for the ego. Apply that to your project, and the QA check will show no errors or warning at all. Fantastic, right? If you decide that there is some particular type of error or maybe a few types that you want to check in one go, it's a simple matter to clone this file, rename it and edit to activate the QA tests of interest. Much easier than turning off all the garbage in the default profile.
Any of those three simplified profiles might make a good basis for creating an automatic QA check that best meets your needs for a particular project. And if you want to share it with others, Kilgray's Language Terminal is a good place to do so.
Nonetheless, I do hope that future builds or releases of memoQ might include these or other QA profile examples in every memoQ installation. That would surely help more users get a proper grip on memoQ's best quality assurance features.
Thanks for these. However, I probably still won't use them until I find out how to tweak a QA profile and set it as default for ALL my projects... Any chance that information could be added?
ReplyDeleteSteven, here's an update: in July and August of 2019 I published a couple of new articles which show how default light resources (such as QA profiles) can be replaced in memoQ so that they will be substituted in all *existing* projects which use the installed defaults, unlike changing the "default" in the memoQ Options, which only affects future projects. Have a look at the date tree for the blog posts on the left sidebar and I think you'll find the posts without much ado.
DeleteSteven, what you are looking for is explained in my video tutorial on the three places to manage QA profiles and the differences between them. It's here on YouTube: http://youtu.be/H92TcwqyEiY. I actually switch between a few different simple QA profiles in a project depending on what I want to look at. I might run just term QA a few times as I work to ensure that I'm sticking to some defined usages, then at the end I'll run just the tag check or perhaps a QA profile with both tags and terms (and that only). It takes just a few seconds to switch the active profile under the project settings.
ReplyDeleteThat's indeed what I was looking for, Kevin - thanks! The main annoyance I have with MemoQ right now is that I haven't figured out how to navigate the QA screens efficiently. I don't mind "false positives", but it does get on my nerves when I have to wade through screens and screens of them. The navigation options in the QA screens seem to make checking or ignoring more difficult than it could be.
ReplyDelete> The navigation options in the QA screens seem to make
Delete> checking or ignoring more difficult than it could be.
It seems to be a common feeling that the QA configuration dialog is tough to navigate - probably because there are just so many options. Not sure how I would simplify that in its basic design. That's why I created that "empty" profile - avoids the possibility of overlooking some stupid little thing in the dialog. And the different management locations for resources can be hard to keep straight, especially when you have illogical exceptions like the Autocorrect rules where the settings for the individual project are controlled from a menu option in the translation window and not under Project home - Settings like QA and most other things.
Hi all,
ReplyDeleteI'm not sure I'll be at a liberty to comment on the "why extra QA default sets are not included by default", I'll let that to the powers-that-be if they want to explain, but on the QA "noise" in general and layout of the Resolve errors and warnings dialog (I guess it was that you were referring to, if not let me know), I do have a few suggestions and comments.
My first "generic" comment is that abundance of QA warnings, also called "QA noise" is the lot of all QA tools when used with default settings. QA is just that: helping you to pinpoint what you might have missed, nothing else. It doesn't "judge" of quality of the target text.
There are countless reasons to mark some QA warnings as "ignored" while from a purely factual POV, QA is also right displaying a warning. Let's say you're translating some marketing brochure on a product and have the company name or prdocut mentionned 10 times in the previous paragraph, you might then very well want to refer to it as "it" rather than naming it again. It is usually much better and easier to read that way. In such a case, if said name is present on source side and not target, with default settings, you would get a warning. It should be taken as a reminder and nothing else: "Are you sure you didn't forget a name here?". Changing the direction of the check might help with those (chekcing target from source and not the other way around). But that is not the default behaviour.
Default settings packaged with a product HAVE to be as encompassing as possible. Otherwise, people not bothering to edit their settings (I'd bet 90% of users) would simply miss too many potential issues/glitches.
When you think about it, it is the same for spellchecking. Dictionnaries are huge, yet do not cover everything. Would you expect users to set themselves their dictionnaries of choice by domain, saying "please don't check for medical word spellings, I'll be writing on industrial matters"? Nope, you do include a very large dictionnary to make sure most users are happy with it. Same goes for pretty much any default setting with applications.
So... back to the Resolve errors and warnings... I'd say that chances are high you find it cumbersome because you find too many results displayed. Answer here I'm afraid is to create and use your own QA set. I would even go further: prepare a QA set for translation, and another one for review. The "lighter/more forgiving" one for translation, and a more complete one for reviewing things afterwards. It has proven quite effective with some people.
You can also swith the real-time preview pane to a QA/Review pane in memoQ 2013 and later. That one is nice too. And if you take care of QA warnings "as you go" when translating, you'll certainly find that a lot less "overwhelming" than leaving everything aside and later run a full "resolve errors and warnings" with hundreds of entries (out of which many could fall in the "ignore all warnings of this kind" if you didn't set your QA settings appropriately in the 1st place.
This is a bit like segmentation rules... once you set them up to what you need, it's amazing how few join/split will be required for proper source/target segments.
KR,
Denis HAY
Well, Denis, this is more or less what I thought for several years, and this is how I've taught the QA module: help users learn to sort/ignore the big default list and show how easy it is to set up the specific profiles we both recommend. But the reason I wrote this post is that after seeing time and again how many people understand the explanations but still fail to act on them, I have to admit that this is more a problem of psychology than technology, and we'll continue to "fail" in our teaching efforts no matter how well we explain. Some other change is needed. So many people are nervous about performing even simple operations for the first time. Very little that you or I tell them is likely to change that. Maybe offering a few more "default" configurations in the shipping version of memoQ might nudge a few more users in a direction that will help them. I just try to accept that not everyone will think like me, you or G. and figure out a good place somewhere in the middle to meet them. You and a lot of others in the Kilgray team actually do that very well as you and many grateful users know, but I find it useful to question my assumptions from time to time when all my actions are not leading to the conclusion I expect with people I try to help. I got a nice note from B. at LT on this subject who indicated that the idea was passed on, so I'm curious to see what comes of that. Over the years I've had many wonderful surprises follow frustration when I thought Kilgray had ignored a problem but learn later than they just thought about it until they came up with a solution far better than anything I ever imagined. The former head of development has a particular knack for that :-)
DeleteAbout this:
ReplyDelete> The navigation options in the QA screens seem to make
> checking or ignoring more difficult than it could be.
It seems to be a common feeling that the QA configuration dialog is tough to navigate [.]
-> I'd mike to suggest that you do send any feedback or suggestions to support@kilgray.com. Kilgray does really take that feedback into account. Seriously. Not all software publishers do. Use that opportunity!
Since I'm not a Yahoogroups moderator, Denis, I won't accuse you of bias and misinformation because you happen to work for Kilgray. What you say is very true; although there was a brief period in a rapid growth phase a year or two when the ticket infrastructure for Support was getting sorted out and new staff were being trained and there were legitimate concerns about the decrease in the usually excellent responsiveness and competence of responses, things run very well now again in Support most of the time. I am very pleased with how many issues users have reported in recent months have been dealt with efficiently and appropriately, and I like being able to review the history of my "complaint tickets" and add more information, check status, etc.
DeleteSome people still seem shy about contacting Kilgray support - or support for any other provider. Many of the questions that get sent to me privately really belong with Kilgray Support but have often not been sent there. Many of these have answers waiting with staff or in the knowledgebase (not everything of course, and I don't mind hearing about things too and getting interesting problems to solve, but Support should still be contacted... if there really is a bug somewhere this is the only way to get the developers on the problem!)