Would we need a dedicated QA for non-breaking spaces?
A little off-topic, but I think the CafeTran community of users (especially if you include the ProZ Plus members that at least make some use of it) might be a lot bigger that the community of users actively participating in this forum. The fact so few are participating just baffles me.
The SCATE report you shared (from the Tool Box Journal) hints at this. It even hurts the credibility of the report, since they have not included the tool in the rest of their metrics.
Yes, as the LT community is at least a bit bigger than the CT community.
By the way: In the very short term, the integration of checking words in the target segments ("Check target segments for words...") with a fixed list into the "regular" QA would be great (e.g. to find ",,", ".,", typical typos or undesired terms etc, that are hard to spot with manual PR).
LanguageTool is licenced under the GNU LGPL v2.1+, which allows its inclusion in proprietary software,
I too think it may be the best solution. Even in languages where the rules are not very refined yet, this open source project will only improve.
The Hunspell spellchecker on which CafeTran relies upon uses a similar licence.
The GNU Lesser General Public License (LGPL) is a free software license published by the Free Software Foundation (FSF). The license allows developers and companies to use and integrate software released under the LGPL into their own (even proprietary) software without being required by the terms of a strong copyleft license to release the source code of their own components. The license only requires software under the LGPL be modifiable by end users via source code availability. For proprietary software, code under the LGPL is usually used in the form of a shared library, so that there is a clear separation between the proprietary and LGPL components. The LGPL is primarily used for software libraries, although it is also used by some stand-alone applications.
;-) (… finally the wheel gets its way …)
Other tools do not have it hard-coded either (this might be impossible), but they rely on certain settings file for each language, this is why I proposed the two points above. LT for DE finds really many things, IIRC even the missing non-breaking spaces mentioned above, so this may be the most reliable solution from the beginning.
Reformulating my personal, non bureaucratic answer:
I have already seconded in the past the inclusion of the LanguageTool at segment level or at the QA stage. For me, non-breaking space checks belong to grammar-aware QA and should not be integrated unless such a solution is included in CafeTran.
> Since CafeTran's QA doesn't check grammar rules, no, I don't think a non-breaking spaces check is needed.
Maybe you are right, but this is a bureaucratic answer (same as some thousands years ago: „you invented what? a wheel? come on, nobody needs that!“).
There are two and a half kinds of scenarios for grammar check QA
The use of non-breaking spaces is mostly dependent on language grammar as well as style guides.
Since CafeTran's QA doesn't check grammar rules, no, I don't think a non-breaking spaces check is needed.
Possible tip for checking non-breaking spaces that are present in source:
Add the non-breaking space to non-translatables for the duration of the QA check. All on-breaking spaces except the leading and trailing ones are detected as non-translatables in the source segments. Just run a QA for non-translatables. QA for Leading and Trailing spaces already exist.
The point is that a technical manual contains many of them, so it makes more sense to check for non-breaking spaces in front of units (and to alarm when there is none) and somewhere in the text (to alarm when there is one where it does not belong).
This is where my proposal pointed to, I am rather sure that it fits your needs.
>When working with a technical manual with tons of non-breaking spaces, I cannot see the point.
Sorry, I fail to understand ... Exactly there I'd need this check.
This will depend on the context.
When working with a technical manual with tons of non-breaking spaces, I cannot see the point. On the other hand side nothing is more annoying than a non-breaking space where it does not belong.
A kind of "check on non-breaking spaces, with the exceptions in front of: km, cm, U/min, km/h" in combination with "check on non-breaking spaces in front of: km, cm, U/min, km/h" would be nice, though (but complex).