[Waiting for user confirmation] No : in spanish translation before glossary entry

Hi Paola, sorry. My customer admins the following: Please report this to your development:

---

**Hello Frank,**

Thanks for your message. If I understood correctly, unfortunately your proposed solution is not a viable option from my side. It would just mean a lot of extra work for me, with translations that would end up being worse or even incorrect. Why?...

**General** = is used when a contextual or semantic connection of the term/entry is allowed, even within newly formed words.
(There is already a lot of extra work here, since the engine tends to use other learned terms for entries classified this way. This happens even when the glossary already specifies how it should be called.
For example: *Handrefraktometer* = *handheld* in the glossary, yet the engine still uses *hand refractometer* in about 10–20% of cases. If it's classified as “Name,” it translates almost cleanly.)

**Name** = is used when the context only applies to specific cases/devices and only for this designation.
For example: *Ablesegenauigkeit* (reading accuracy) is not a term the engine should be allowed to use in a different semantic context. It is a designation for a specific unit/attribute that only applies to certain devices. For other devices, it’s called something else. Clear distinctions are needed. I set this up very deliberately.

If I go with the proposed method, the engine would treat *Ablesegenauigkeit* as a general term and learn that it can use it in different contexts. My question: I believe I understood that correctly, right?
Then, for example, a new term like *Ablesegenauigkeit Skala* might be translated as *reading accuracy scale*. But the correct term would be *scale accuracy*.

This is even more critical for other glossary entries, like *Referenzlinie* (reference line) in flame photometers, or *Vol.-%*, *temperature measurement resolution*, *temperature control range* – these glossary entries apply only to specific devices within the context of their technical specifications and descriptions. It's also very important for *adjustment* and *calibration* – if classified as “General,” the engine often creates the wrong context, which can lead to seriously flawed descriptions in these cases.

**Conclusion**: In our analog translations done in Trados in Italy, everything works perfectly. David (Product Manager) and I also synced the software terminology GUI right away. It all worked smoothly via the Trados interface.

I think I expected too much for the website. Back in 2009, I worked on semantic applications and developed models for that. It was a completely different, very expensive and complex system. Naively, I hoped this would allow precise distinctions for our web use as well, but that doesn't seem to work with a DeepL glossary. DeepL is affordable, but also more limited.

Still, now that I understand the issue, I could try to work around it — though, as mentioned, it’s a lot of extra work. I’ll have to check with Thomas and Karin how important this is for the company or whether the focus should shift elsewhere. Unless you happen to come up with a solution that respects the “General” vs. “Name” separation.

---

Would you like help condensing this message or adjusting the tone for clarity or formality?