You are currently working on UAT 

Broken segmentation in recent Studio updates (newer than 2015 SR3 and 2017 SR1 onwards)

I'm creating this separate thread for paragraph based segmentation issues I mentioned elsewhere:

https://community.sdl.com/solutions/language/translationproductivity/f/90/p/13299/46835#46835
(additional info in https://community.sdl.com/product-groups/translationproductivity/f/90/p/13299/48428#48428)

I'm attaching test files here:
5383.testfiles.zip

ZIP contains:
IAD_Pseudo-HTML.sdlftsettings - file type definition
test_en-US_de-DE.sdltm - testing TM with the additional Line break segmentation rule
test_English.txt.html - source file to test with
test_English.txt - original client's source format for reference only (it's very weird hybrid of plain text and HTML content with some custom non HTML-compliant tags and some "Excel formulas-like code"... normally it contains more of that 'garbage', but I deleted it as it's not relevant now)

Now, already in the "working" version I see some weirdness in the LineBreak rule - the only rule which works is this weird one:
.?[\r\n][\r\n]
The logical one - .?[\r\n]+ - does NOT work for unknown reason :-O
But at least something works...

In Studio 2015 SR3 (12.3.5262.0) and 2017 CU5 (14.0.5889.5) I get this - all properly segmented as expected...

In Studio 2015 SR3 CU10 (12.3.5281.10) and 2017 SR1 CU7 (14.1.6329.7) I get this - segments broken at totally weird places in a middle of a word... but at the same time NOT broken at the line break (sometimes :-O)
It must have something to do with the inline locked content, since plaintext lines further down the test file are segmented correctly.

And more weirdly, I am not able to find regex which would make it work in these new Studio updates!
Neither the basic .?[\r\n]+ regex, nor the [\w\p{P}][\r\n]+ regex according this knowledge base article work - the basic regex produces exactly the same weirdness as above, the regex from the KB article gets better, but fails on lines with trailing spaces (and adding \s* anywhere in the regex yields again exactly the same weird result as above):

So, my conclusion is that there is (still) something broken in the segmentation rules.

Parents Reply Children
  • Hi Evzen,

    Welcome to the world of homo economicus codicus. The budget isn't big enough to solve everything and your case is unlikely to affect anyone else. So you have been given a workaround.

    My irritation with Dragon and Excel (for some reason Studio invokes Excel when it does not need to do so, thereby screwing up Dragon every once in a while) is at an even lower level. There is apparently no workaround, so I get an ignore, which does not surprise me.

    You should be happy to get a workaround. You are lucky.

    I imagine that a lot of effort is being spent on getting fragment matching and lookahead working. And given that the bug list is so long, these new bells and whistles probably only got a budget in the first place because the competition was offering something similar.

    Can't fall behind the competition.

    But now SDL has to throw even more money at these things to get them to actually work, so they won't have to advise us to turn off all the new features any more (bad marketing).

    Of course, these new bells and whistles will be great once they work, so I am looking forward to the marketing hype finally becoming reality.

    But in the meantime, unless your bug has the potential to affect a good chunk of the user base, I wouldn't hold my breath.

    Best regards,
    Bruce Campbell
    ASAP Language Services

  • The point here is that the bug DOES affect enough people... because it's about "segmentation after line break" - which is an elementary and fundamental feature - not working as it should. So it's not just "my bug", it's the silent majority's bug.

    As I mentioned elsewhere, creating "manager's new toys" can come ONLY after the foundation is solid and works as it should (not "as it was designed", since the design was apparently BAD at many places... but "as it should").
    Because then even creating the bells and whistles is much easier... since the underlying foundation WORKS as it should.

    For example, how come that after so many years "get default project template configured in Studio" via API does not return ACTUAL default template, but "Default.sdltpl" instead?!?! This is TERRIBLE ommission (the developer AND tester AND their manager should get some financial penalty) and terrible BUG!
    How can someone even try to build something on top of such BUGGY foundation?!