projectAnonymizer bug


when using projectAnonymizer with some strings there is a bug that where does not replace the strings as it should but mixes them around instead and partly even duplicates part of the string and leaves it unchanged for 1 copy of it.

There is no difference whether to use a complex rule to catch all the strings to be converted or multiple smaller rules to catch them one by one. So I either leave these rules out or rearrange strings in Notepad++ manually...


Rules applied:

for seg 3 and 5:

{\d, date, long}|((\()?{[0-9], plural, (=1|one|other) {(#|[0-9])?)|(} other(\s)?{(#(\s)?)?)|(}}(\))?)

for seg 66:

({\d, select, (WITH_NAME|ADMIN){({\d})?)|(} other{)|(({{|{)(?!(font|page|credit)(s)?)((#)?\d+|[a-zA-Z]+((\s|_)[a-zA-Z]+)*))?(}}|})|(}}|})


Starting point:




I guess you can see what went wrong. Maybe the devs can find out why it ran wrong.

I'm setting up my regex expressions with RegexBuddy before entering them into projectAnonymizer and I also found out that projectAnonymizer sometimes seems to handle the rules differently.




30 Replies Latest Replies: 18 Jan 2019 11:44 PM by Paul < 1   2   3   4   5   6  >
  • In reply to Pascal Zotto:

    Well that's irritating! I tested the same files you gave me last time with these rules and it all worked fine. Can you give me the exact steps you are going through please because there are a few ways to work through the process and I'm clearly not doing what you have!
  • In reply to Paul:

    In fact I'm wrong... just realised you said 2017. The SDL Data Protection Suite is only available for 2019 and we have not implemented any of the fixes that went into this version in 2017. This applies to many of the enhancements we introduced prior to your posts as well. We also won't be doing this for 2017.

    The sourcecode is available if any developer wishes to do this, but we will not. The work is integrated into the SDL Data Protection Suite and we are only updating this version.
  • In reply to Paul:

    Hi ,

    That's sad as many translators will not be able to profit from these changes as they did not switch to 2019 due to too high costs for such poor/few changes made from 2017 to 2019 version. Especially those who have a professional version. It's cheaper to stick to 2017 for most translators (as you mentionned yourself in one of your blogs if I remember well (as well as some other bloggers did)). It would at least be nice to offer a 2017 version of the Suite.

    Part of the Anonymizer 2017 version has been updated though, so I don't see any point why the product would be left only partly updated and not working at all if at least partly worked before.
  • In reply to Pascal Zotto:


    I disagree with you that there was not a lot in it.

    I also think all translators should take a support & maintenance contract and then they won't even have to think about it:

    However, for us the projectAnonymizer and the TMAnonymizer really go together and we made wide reaching changes in the 2019 SDL DPS to the underlying code for these apps and only wish to maintain one app. The 2019 version we created contains things that will not work at all on 2017 so we made a decision not to provide this free app for versions below 2019.

    Right now we have responsibility for 112 applications (some in the appstore and some not) and a team who are already stretched. So supporting every version, fixing bugs in every version, is not something we can reasonably manage.

    The apps we provide in the appstore we provide for free and we make the source code available. So perhaps, the "many" translators you refer to could get together and engage a developer to create a 2017 version for you? There is nothing to stop you doing this.
  • In reply to Paul:

    Hi Paul,

    well getting the support and maintenance contract in order to get new versions is not really cheaper either. The only difference is that you pay more than the price of an upgrade to the new version stretched over 2 years (at least here in Austria as I have a professional version). So it does not get cheaper, especially if you hardly ever have any issues that need immediate solutions which the support team can care for.

    And for me as a freelancer having to pay a professional version only because I need 7 (source) languages into 3 target languages (mother tongues) instead of the 5 supported languages by freelance version does hurt compared to what I earn. And I know I'm by far not the only translator complaining about this.

    Regarding the 2019 version itself many translators I know, and from what I read on the net in various forums and in blogs in many languages, say the very same thing: too expensive for the few changes they did. Especially considering that most translators could only really use 1 or 2 of these "new" features other CAT tools have implemented as standard for years but other long requested more important improvements did not find their way to 2019. Sorry, but 2019 version was a slap into the face of many translators.

    I only hope it will get better with the next version as else I'll then unfortunately have to switch to another cheaper tool with more functionality (although I'm a real fan of Trados since 2006 and always get my clients to send me files for Trados even if they want me to translate in some other tool they use) and I know many other Trados users who have the same reasoning.

    regarding the 2017 version of the Suite, I don't know how many use it and have the same problem than me, so getting together to find someone to get it fixed does not make sense.
    I only started desktop programming a few weeks ago, so maybe I'll get to a high enough level some time to have a look at it myself, if I have the time to do so.

    Right now, I manage to get around these errors by using multiple addins and leaving the few parts that cannot get converted as they are for programming.

< 1   2   3   4   5   6  >