Hi Michael Bauer (MichaelBauer)

You could add two segmentation rules to make it look like this:

Then just filter on the commas, copy source to target and lock them, then you're good to go.  The basic idea is that segmentation rules follow on sequentially so first of all create a rule to break before the comma:

break before comma rule
\w[\w]+
,

Then create a rule for after the comma:

break after comma
[,]+
[\w\p{P}]

That should be it.  I put my TM here so you can test it and inspect if you have problems.

comma segmentation.zip

Hi Michael Bauer (MichaelBauer)

You could add two segmentation rules to make it look like this:

Then just filter on the commas, copy source to target and lock them, then you're good to go.  The basic idea is that segmentation rules follow on sequentially so first of all create a rule to break before the comma:

break before comma rule
\w[\w]+
,

Then create a rule for after the comma:

break after comma
[,]+
[\w\p{P}]

That should be it.  I put my TM here so you can test it and inspect if you have problems.

comma segmentation.zip

Paul

thank you. Sometimes a closed door is a big time-saver!

Daniel

Hi Paul

I have a follow on question. The client has now started using stuff like

roses.{1}{2}daffodils.{1}{2}anemones.{1}{2}dandelions

so I've tried using the above for the same purpose but there's something it doesn't like about the {, I get a warning about 'nested quantifiers. Any ideas?

Michael Bauer

Hard to answer without seeing your rules.  However, with this example I would not use segmentation rules on the TM.  I'd just create a parser rule for the tag and set it to exclude which will have the effect of segmenting but it'll be a lot cleaner.

Looking back on this example, you might even be able to use this method for the others as well if the filetype supports it.

They're mxliff files.

I tried

break before {1}{2
\w[\w]+
\.{1}{2}

and also just

break before {1}{2}
.
\.{1}{2}

I also tried it without the \ and without the . but the same error message always appears.

Michael Bauer

ok - this will be a problem if they are xliff files... which they are.  You won't be able to segment them using a bilingual filetype... not even using the Multilingual XML.  The only way you'll be able to handle this are these:

1. prepare the file properly in memsource in the first place!
2. tackle it by creating a custom XML filetype and only translate the target.  This will work if your files are not partially translated and if the source has been copied into the target

Michael Bauer

Just on this...

\.{1}{2}

Two strange things here.  First of all a quantifier of 1 is meaningless ({1}), and second of all you can't quantify a quantifier.  If you want to mess around with this you need to escape the curly brackets as these do have a special meaning when used with a number (syntax for a quantifier).

Paul said:

• prepare the file properly in memsource in the first place!

Sadly I have no control over what the client sends, it's not me creating these xliffs in the first place.