Feature request: Mark CamelCase mismatches as "OK"


#1

Hi,

Would it be possible to add a feature that allows to mark CamelCase mismatches in the QA view as “OK” for all future projects?

Example:

START_LINKLearn moreEND_LINK
START_LINKWeitere InformationenEND_LINK

This string should not show up during QA as the translation is correct. Thanks.

Doreen


#2

You can uncheck the CamelCase mismatches checkbox in the Content section. Once you have run a QA with this checkbox unchecked, future QA runs will have the box unchecked as well.


#3

Hi pcondal,

Thanks for your answer. Please note that I do not want to uncheck the CamelCase mismatches feature completely. I just want to mark the false positives as OK, like adding alleged spelling mistakes to an addendum.

Best,
Doreen


#4

Hi Doreen,

I had a similar problem to yours the other day. It was a large project and the CamelCase false positives were just a couple of terms (easily excludable, then).

Assuming the ONLY false positives you get are something similar to “WordSTART”, “WordEND”, “LINKWord” and so forth, you could do the following:

  1. Disable CamelCase Mismatch check.
  2. Create and use in your automated quality checks a checklist item as follows:
    Source: "(<[A-Z]*[a-z]+[A-Z]([A-Z]+)?[a-z]+>|<[A-Z][A-Z]+[a-z]+>|<[a-z]+[A-Z][A-Z]+>)=1" -"[a-z]%+(START|END)" -"LINK[a-z]%+>"
    Target: -@1
    PowerSearch: ON
    Search Mode: Regular Expressions

This way, you will get instances of CamelCase mismatch with words like “iPhone”, “CamelCase”, “camelCASE”, “CAMELcase” and so forth, but excluding anything like “WordSTART”, “wordEND”, “LINKword” and anything else involving “START”, “END” and “LINK” within the same word.

The obvious drawback of this approach is that if there was a DNT product name like, say, “LINKProduct” in source and you incorrectly deleted or adapted it in target to “LINKProdukt” (for instance), you would not get any hit of this offending CamelCase mismatch.

In case there were more similar and recurrent false positives involved, you would just need to edit the -"[a-z]%+(START|END)" -"LINK[a-z]%+>" part of the source search accordingly.

BTW, I would swear that the example you showed comes from a XBGTT file, is that right? If that is the case, perhaps it would be advisable to kindly request the ApSIC guys to fine-tune the Xbench Chrome Extension for Google Translator Toolkit works so that inline elements are properly managed and reproduced in exported XBGTT files. If I am right (and I remember well), these “START_LINK” and “END_LINK” would look in GTT editor something similar to “{0}” and “{1}”. Is that possible?

Hope it helps!

Best,

Manuel


#5

Hi Manuel,

Thank you so much for your reply, I will definitely try this out. And yes, you are right, the example is from a XBGTT file (“START_LINK” and “END_LINK” correspond to “{0}” and “{1}” in GTT). I will forward your suggestion to the ApSIC support. Thank you!

Best,
Doreen


#6

@germantranslator, @Manuel, which is the source format for which the START_LINK and END_LINK placeholders appear in .xbgtt files?

We were not able to reproduce it for example uploading an HTML file with inline links to GTT.


#7

Hello,

I’m sorry, I don’t know. Last time I spotted a similar issue on a XBGTT file, it was quite a while ago. Since I luckily do not work much with GTT and I was a bit in a rush back then I did not give it much thought. Perhaps Doreen can help with this.

Anyway I’ll be more attentive in future GTT jobs I might translate and, should I come across a similar issue, I will let you know.

Thank you.


#8

Hello,

Sorry for my late reply. I just had a look at the source file format and it is indeed html but it might originally come from another source (UI).

Doreen


#9

I have just come accross a small GTT project where this error is reproduced. I will report it with screenshots through a support ticket.