Let me give an example. I have an old client I'll call National Translators. Well, sometimes that's the name I use when filling in the Client field for the memoQ project. Sometimes I write Nat'l Transl, sometimes it's NatTrans or even NT. And then when my fingers get rebellious I might have the occasional NtaTarns or worse.
Despite the messy appearance of screenshots of the TM and termbase lists in my various tutorials, for the most part I follow the "Big Mama and Papa" approach to data management with a large master TM and termbase with over a decade of archived reference material. But I do occasionally like to filter those data and produce a more focused termbase or TM for a projects, such as all the NatTrans material from projects involving Poultry. That was easy with Déjà Vu. Each client had a unique, selectable code. Subjects were number coded with a sophisticated classification scheme that I adapted for my own use. With memoQ it's been a real pain in the ass.
Well, it seems that times are a'changin. A little bit at least in this respect. One change that sort of slippe under my radar in memoQ 2013 was the addition of selectable data to projects through the use of the free Kilgray Language Terminal. I almost missed it completely, because I was looking at some of the latest "innovations" there from the wrong perspective. Wrong for me at least.
|Clients list on my demo profile on the Kilgray Language Terminal. Click to enlarge.|
Kilgray recently introduced the ability to do basic project "management" on Language Terminal. Price lists. Clients lists. And more. I was appalled, or at least quite uninterested in that, though I rather like other aspects of Language Terminal. I have a good tool for quoting jobs and maintaining my client records, and I really don't think I'll be replacing that with the rather simple start that has been made by Kilgray in this area. And having lived in Germany for years, I have almost adopted the knee-jerk aversion to storing my client data online which is so common there.
But... there's another way. Better for me. I don't have to enter my clients' details. I can enter just the names. Or better yet - my preferred codes (which can protect their identities but let me sort my data better). Click on the screenshot above to see an example of this in the last two entries. You need not be as cryptic as I was in that example.
On the "Professional" page of my Language Terminal profile (the link to the left of "Clients"), I can enter my subjects. Kilgray intended this for their find-a-translator search function that they are adding to Language Terminal, but I'm probably not going to be interested in being found and approached by the sort of prospect that might use their database. My philosophy is that looking for a translator based on tool use is fundamentally backward, and I really don't want to support bad practices like that. Translators should be engaged based on subject and linguistic expertise; the translation technology involved is like a shirt, tie and a pair of shoes - you just put on what is appropriate for the occasion. But without the subject and linguistic competence, you really ought not to be part of the game at all.
So once again, I would enter my subject data on Language Terminal, not with the idea of being "found" by some Indian or Mongoloid agency to be offered the opportunity of a lifetime at 2 cents per word, but rather with an eye toward sensible data classification for use in filtering later. Here's an example of what these metadata entered on Language Terminal look like when you start a new memoQ project and mark it to be "entered" on Language Terminal.
I still like the local DVX approach better for such metadata, but this is actually an improvement, and it will help me clean up my data organization. And using these features for my purposes, rather than the purposes for which they seem to have been created, will also maintain confidentiality as I want to. In fact, the profile seen here is not even viewable by other Language Terminal users.
There are many other very useful features of Language Terminal, which make it worthwhile to get a free account, even if you don't use memoQ. The blockbuster is still the free InDesign processing service, which enables one to handle native INDD files, get PDF previews at any time and convert InDesign files to XLIFF for convenient translation in most modern CAT tools. As a memoQ user, I find the backup feature useful as well; the Resources page is starting to get a few useful things, and rumors of future plans make me think this is really something to watch closely.
But this recent "revelation" of the possibility of selectable metadata for my memoQ projects is a small but very welcome addition to my toolbox in memoQ 2013, and finding this in an area of the site that I had already written off as uninteresting to me was perhaps the most pleasant surprise. It's nice to be wrong like that.
Kevin, like you I have long lamented memoQ's inability to store this kind of metadata and make it available for selection when creating new projects and resources. I'll have to look into this Language Terminal – I admit that until now I've studiously stayed away from it, for the same reasons you've outlined.ReplyDelete
A little off topic perhaps, but the nightly builds of CafeTran just got the ability to prioritise terminology relevance (in it’s tab-delimited text glossaries) and Igor (the developer) is currently also working on selectable metadata + lists of clients/subjects stored in text files.
Although I still own memoQ, I do most of my work in CafeTran these days. I got sick of waiting for Kilgray to implement (basic, missing) features I have been asking for, for over two years. Igor, on the other hand, usually only needs a day or two to add the things we ask him for!
I will keep my memoQ licence current, just in case, but to be honest I am starting to lose faith in Kilgray. Don’t get me wrong, memoQ is still an amazing tool, but it just feels like it is slowly being taken over by the big server boys.
Still, using a separate on-line service for something as simple as maintaining a short list of strings is rather an overkill (and makes even less sense if you have to obfuscate the names or make them human-unreadable). I am disappointed this basic functionality is not available off-line in the tool itself.ReplyDelete
Tomasz, of course this is disappointing, and such a feature ought to be included in the offline version and include other metadata possibly. But for years no reasonable response (if any) has been made to such requests, and we'll have to take what functional crumbs we can which fall from the table. What I did fail to mention above is that this metadata in lists is only available within a project, so if you want to use it when creating termbases or TMs in another context, you are out of luck.ReplyDelete
Michael, I'm not too worried about the terminology "relevance" or priority at this point - it has been a thorn in my side for years now, but I think we'll see a resolution of some kind for this before long. And although I have heard good things about CafeTrans from one of the people whose opinion I value most for translation technology, I simply can't see the value of disrupting my processes and upending my ergonomics and be cut off from projects like the one I'm doing today on a friend's server. I also simply can't expect a single developer to keep up with the range of function required by a growing user base and still maintain his health and sanity.
Igor seems to be keeping up quite well. Whether he’s sane or not is hard to say though. Incidentally, he also just added selectable metadata lists of clients/subjects (stored in simple text files) to CafeTran, among ‘a few’ other things: http://cafetran.wikidot.com/pre-release-version
Regarding CT’s term prioritisation for auto-assembly, you can now prioritise:
1. an entire glossary (3 priority levels),
2. a term inside a glossary, based on its Subject/Client field, or
3. a term inside a glossary, based on its context* (specific words in the same segment).
CafeTran’s auto-assembling features are getting better and better all the time. Although DVX is always toted as the undisputed king of auto-assembly, I think CT might already be in a position to give it a pretty good run for its money.
I agree that switching over is a bit of a pain in the ass, but so far it has been more than worth it.
*Context-aware Auto-assembling (C-3A): http://cafetran.wikidot.com/using-context-aware-auto-assembling