Override/configure QA for specific strings?

General Questions
1

We’re using Crowdin’s QA checks in our project, which are helpful, but they’re somewhat hampered by what I call the “unfixable false positives”.

For example, our (Gettext .pot format) translation source has a translator-credits field that’s intended for translators to be able to claim acknowledgement of their work — it’s free-form, not used in the application UI, and the translated versions frequently contain multiple issues the QA system calls out: proper names it claims are misspelled, mismatched case, what it flags as mismatched spacing, additional formatting tags that don’t appear in the source string (which is just “translator-credits”, and only because it had to be something to make it into the file), etc…

All of that stuff is irrelevant, and should be ignored — but only for that one string.

So I’m wondering if there is, or is planned to be, any way of telling the QA system to just not check that one particular string at all? Whether through translation source file comments/options, the translation UI, the project settings, etc…

For other situations (since the “translator-credits” thing is kind of a special case), it would be handy if we could override the checks for specific QA issues, again on a case-by-case basis.

Many source-code checkers, for example, allow localized overrides:

function(s) {
    like(this) in 'javascript';
    {'can', 'be', 'annotated', 'with', ...}
    // eslint-disable
    override("comments" or "even", ...)
    /* eslint-disable specific-rule[, or specific-rules] */
    "in order to";
    do {
        no('checking');
    } while (in effect());
    /* eslint-enable */
};

class Definitions:
    """as well as other source..."""
    for code in ["Python"]:
        with unavoidable("issues") in [*lines]:
            can = "be made to"
        pass
    with something({
        like['this']:  # noqa
        "comment" or "even"
    }):
        a: list["of" | "specific"] = "rules"  # noqa: E123, E117

So, one convenient approach would be if Crowdin supporteed the moral equivalent of those eslint-disable or noqa comments. Something that could be embedded in the translation source files in a directive format that the QA system recognized. Translator comments are already picked up on scanning, associated with individual source strings, and imported by Crowdin for display in the UI; being able to embed QA directives would just make them even more useful.

But barring that, an interface in the web UI for overriding QA checks on certain strings would be just as helpful.

2

Modification of QA check can be only in Enterprise version

In general version, Crowdin Com you can either enable or disable the QA checks. Also can add some custom pre-made checks. Discover the right solution to enhance Crowdin experience

But not writing the check you’ve proposed here, unfortunately.

Still ,once something is ignored by proofreader it’s added to project ignorance list. So no need to ignore things twice. Proofreaders can ignore the QA suggestion.

3

Thanks for the info, Oleg, that makes things clearer for me, at least.

Aha! That’s the major piece I was missing. I have access to all of the roles for the project, and since they all have access to different features sometimes it’s not obvious which one to use. I hadn’t tried checking the QA issues list in the Proofreader view; now that I have, I do indeed see that there’s an option to approve translations over the objections of the QA system. So, that’s a big help.

A few things I guess I’m still not quite clear on:

  1. That’s once per-language, though, right? I still have to approve (potentially) 30 different translator-credits translations for our 30 target languages, correct?
  2. If the translation changes (say, another translator adds their credit to the translator-credits for their language), the QA system can flag the new translation again, right? Other than spelling errors (which can be ignored permanently), it doesn’t seem like approving a translation does anything but override the QA checks for the current translated string — an edit will cause it to be run through the QA checks again, won’t it?
  3. For spelling errors; I see that I can mark a spelling error “ignored” (from either the Proofreader or Translator view) by clicking on the misspelled word. That puts it on the ignore list for that language. So, something like an untranslatable proper noun has to be ignored separately for each language, right? (Be great if there was some way to centralize those when appropriate, say if there’s a certain word that should never be translated into any target language.)
4

Try to answer :slight_smile:

  1. That’s once per-language, though, right? I still have to approve (potentially) 30 different translator-credits translations for our 30 target languages, correct?

Yes, only once per language. Like I ignore “hello” in english-french pair, if wouldn’t be ignored in any other pair, and in any other configuration, like “hello, hello” or “… hello, h”

  1. If the translation changes (say, another translator adds their credit to the translator-credits for their language), the QA system can flag the new translation again, right? Other than spelling errors (which can be ignored permanently), it doesn’t seem like approving a translation does anything but override the QA checks for the current translated string — an edit will cause it to be run through the QA checks again, won’t it?

Votes don’t affect anything. It only for very big projects where are 10 volunteers and each of them would like their suggestion to be as a translation, so they vote and proofreader choses. Only new translation or approval replaces an old one. Any new translation will be followed new QA line. It’s a stand a lone thing, you did translation, you approved it, it’s all. If you write down a new one, the process will be triggered.

  1. For spelling errors; I see that I can mark a spelling error “ignored” (from either the Proofreader or Translator view) by clicking on the misspelled word. That puts it on the ignore list for that language. So, something like an untranslatable proper noun has to be ignored separately for each language, right? (Be great if there was some way to centralize those when appropriate, say if there’s a certain word that should never be translated into any target language.)

This is what glossary should fix. Create a term, so all would now it’s a term. Just add same translation to all languages. Like term Hello, and in french should still be Hello