Use special QA termbase for QA checks
Would like the ability to choose a special termbase (eg, a subset of the termbase assigned to the project) instead of only being able to select from termbases assigned to the project for WB QA checks. This "QA check termbase" would be available as a termbase in WB.
We need to use a subset of the main termbase because the main termbase gives us too many false positives in a check. For example, the term in the termbase is a verb with the dictionary form (eg: "verify"), but the term used is the noun form (eg: "verification").
Also, our main termbase sometimes has more than one entry for the same term (same source term translation, but several different possible translations of the term). Such entries would be removed in the QA check termbase to prevent excess false positives in the QA check.
Thanks,
Mike
-
Official comment
Hello Mike,
You can achieve this by creating a new termbase as a subset and attaching it to the project. Once attached, you need to activate the Terminology check only for this resource.
Regarding the issue with false positives, you can do the followings:
- Add those entries to the termbase as terms. Most of the time, terms are entered in substantive form, sometimes as verbs or adjectives.
- If you have the Terminology Management module, you could enter all these forms inside the same concept entry and by means of TBX fields define what is the use-case (the "property part of speech" can be set as noun, verb, adj, adv).
In any of the cases above, the system will work fine and will not return a false positive.
Kind regards,
Andrea Benedetti -
Hi Andrea,
Thanks for getting back to me.
1. Creating a new termbase as a subset
This solution won't work because we need the new termbase (QA termbase) to be available to all and some users may not have the rights or just may not want to go to all the trouble of adding a termbase to each project just for a QA check.
2. False positive countermeasure: Add those entries to the termbase as terms
I don't think this would work because we don't have the resources (time) to add entries for all of these. I think it would be better to have some function built into the QA checker that would enable us to add different forms of the verb in the QA function as needed to reduce false positives. That seems to be the way most dedicated QA check tools do it. (Or at least have the ability to easily exclude certain terms [eg, terms that have several translations depending on the sense].)
3. Terminology Management module solution
This seems like it would to require us to change the configuration of our main termbase that we attach to each project as the termbase resource. How much effort do you think that would require for say 25000 terms? Not sure how many of these terms would require this work, but a significant number. But if you have any details on this 3rd solution, could you send them to me?
If you have any other ideas, please let me know.
Thanks,
Mike
0 -
Hi Mike,
Thanks for these clarifications.
I'm afraid these are the only workarounds I can propose at this stage. I am adding here links to our documentation on the structure of terminology databases in Wordbee and on adding concepts, terms, and properties to databases:
https://wordbee.atlassian.net/wiki/spaces/WBT/pages/35979543/Database+structure
https://wordbee.atlassian.net/wiki/spaces/WBT/pages/29622441/Add+concepts+and+terms
I hope this may help you.
Kind regards,
Andrea Benedetti0 -
Hi Andrea,
Thanks for the links.
Is there any way to add a special terminology QA check termbase (which would act like a QA check dictionary) to a project but prevent that project from searching it when you open a segment? The idea is to provide a 2nd termbase (the QA check dictionary) but prevent hits from it from appearing when you are translating (because it would be redundant and just slow down processing). Our main termbase contains lots of short entries like abbreviations and acronyms, and these tend to cause some false positives (because they are embedded in longer strings). Using the QA check dictionary (which has these short strings mostly removed), can reduce false positives to some extent.
However a major problem that remains is that the termbase often has the singular form of a noun (like "screw") and the translation has the plural form ("screws"), so even though "screws" is correct, it is flagged as an error. At least one standalone QA check app handles this by allowing you to enter an alternative version of say nouns (like versions with an "s" added, or "ing" for verbs) to handle this situation. Then, no more false positives for that term. Any chance of WB adding such functionality in the future?
Thanks,
Mike
0 -
Hi Mike,
There is no option available currently to add a termbase to a project without searching it when opening segments.
Regarding having alternative versions of nouns, verbs, etc. The recommended approach is using the terminology manager and adding these variants as terms. On the term-level for example, you can define as TBX fields the grammatical number (singular, plural,) as well as the part of speech (noun, verb, adjective, etc.). In this example, it is possible to create several entries in the termbase for “screw”, “screws”, and "screwing". You would also add the corresponding translations, and if one of these terms is detected during translation, the QA check would not flag it as an error.
The issue here is, as you pointed out, that you would need to update your main termbase which would require a lot of work. Unfortunately, this is the only solution I can propose for now.
I hope this helps.
Kind regards,
Andrea Benedetti0 -
Thanks, Andrea
Thanks for the information.
It would be helpful if WB developed some solution for this in the future.
Thanks,
Mike
0 -
Hi Andrea,
Just curious, but what benefits, in addition to the ability to improve term QA performance, would be gained by updating our main termbase? For example, easier termbase management (by using the terminology manager), or better performance in term searches? Anything?
Thanks,
Mike
0 -
Hi Mike, I am glad you are asking,
In addition to improving QA performance, there is a variety of benefits of using the terminology management module:
The module uses TBX 3.0, being able to work with this standard allows you to edit the various TBX fields to define the structure of your termbase. This allows importing and exporting TBX files created in other tools without worrying about the structure of your termbase or loss of information. This structure allows you to add term variants and support the various part of speech, abbreviated forms, term types, etc. All in concept-based terminology databases.
You can also use custom fields at the term- or concept-level. If a specific field is not available in the system just using TBX fields, you can still have your own custom information for each term in the termbase. These can images, URLs, or any metadata that can be helpful to linguists.
The terminology management module also allows you to define permissions for individual or groups of users. This allows you to collaboratively work on the maintenance of your termbases and set up a terminology review workflow using term status labels to indicate whether a term is under review, approved, rejected, etc.
From the translation editor, linguists can use the terminology lookup tool to access the details of the terms. All term-level information is displayed in a dedicated pop-up window that users can resize or move to another screen. This generally means more information for linguists who can quickly confirm they are using the right terminology, which means less time searching the right terms, and more time to focus on the translation work. From this window, authorized users can also quickly edit or update a termbase entry as they are working in the editor.
These are some examples, I am adding here the link to the terminology management module documentation where you will find more detailed information: https://wordbee.atlassian.net/wiki/spaces/WBT/pages/22020295/Wordbee+s+Terminology+Management+Tool
Active Terminology Recognition and Terminology Lookup:
https://wordbee.atlassian.net/wiki/spaces/KB/pages/861274185/How+to+use+Active+Terminology+Recognition+and+Terminology+LookupKind regards,
Andrea Benedetti0 -
Hi Andrea,
In addition to the above-mentioned issues with using the Wordbee terminology management module (large effort modifying our current main termbase to make it compatible), I think the last time we tested the module, the following problems were revealed. Do these issues still exist?
1. TBX field changes are made globally to all termbases using the module. This makes it impossible to have separate termbases (with differing configurations, say for different companies using the same Wordbee platform).
2. Changes made to termbase configurations could affect layout of translation memory metadata fields.
3. No required field functionality. This would allow users to enter terms without any required information. (We require users to fill in certain fields [required fields] when entering new terms.)
4. No default setting for pick list fields. (Need to be able to set default settings)
Thanks,
Mike
0 -
Hi Mike,
Let me answer on the different items you mentioned:
- The behavior here hasn't changed. TBX fields are configured globally. You can then decide which fields you want to fill when working on the term entries.
- I am not sure to understand here what you mean here. The changes to termbases should not have an impact on the translation memories metadata fields.
- It is possible to create required/mandatory fields for termbases. You can create a segment custom field that will apply to terminology databases and tick the mandatory option:
Then, you can activate this field in the Terminology Management configuration screen. - It is not possible currently to define a default value for picklist custom fields.
Best,
Andrea Benedetti0 -
Hi Andrea,
When we discussed your suggestion of adding all the forms of a term (eg, machine, machining, machined, machines, say using the new WB terminology editor) would be too time consuming, so an unacceptable hit to productivity.
There would have to be some other perhaps AI driven solution that could analyze a sentence and determine whether the term was a real mistake or just an alternate (but correct) form of the term.
So, no workable solution at the moment.
Thanks,
Mike
0
Please sign in to leave a comment.
Comments
11 comments