[Branda Pro] Fix and Enhance Text Replacement

2

Please QA and enhance Branda Text Replacement. This request is only about admin/back-end text.

The Text Replacement has always been a good start but it’s never been complete. Here are some examples that anyone here can try to see the anomalies that I’m seeing:

Change the name Smush to Compression for this exercise.
– Case sensitivity needs to be used because the source text is both “smush” and “Smush”. We can’t say “match the original casing. But this also means that we need to create a case sensitive match for every usage.
– For some replacements the text replacement seems to be based on words, not plain text. So for this exercise, a separate rule is required for Smush, SMUSH, Smushed, smushing, and “smushing!”. I also had to replace “smush” and “to smush” in separate rules.

If you’re not running Smush, try Defender, which I just replaced with SecureSite. You’ll find some text is replaced, others not. This might be due to how some of the text is used in code for i18n, as constants, etc.

Specific Requests:

1) Make sure replacement works for all text types. It’s dirt-simple to test this right now and somehow QA never notices that it’s not working. Ensure the text replacement is performed during all required filter hook events in the page generation cycle. If you’re concerned about performance, give us a hook or defined constant that we can use to add or remove specific hooks for our own fine-tuning.

2) Allow for RegEx. That will help a lot. (Make sure case sensitivity checking is disabled when regex is used.)

3) Allow us to move rules around. I created a rule and then found another following rule didn’t work because the text it needed to change was no longer there. So I deleted the first rule to allow the other to process first, then I recreated the first rule afterward. (This might have been that “smush” and “to smush” anomaly.) This is too precarious. We might need to do this sort of juggle anyway, like changing text to “FOOBAR” and then later processing all FOOBAR to FooBar or something else. But that’s very difficult if we can’t move the rules around.

4) (Would be nice) Allow selection of the number of items per page. What’s the deal with 10 items?

Thanks

  • Nithin Ramdas
    • Support Wizard

    Hi Tony G ,

    I would like to update you that our Branda team do see these suggestions would be handy and will be discussing further implementing these feature.

    At the moment, there isn’t any exact time frame we could provide but can confirm the feature request has been acknowledged by our team and will be evaluating whether it could be considered for future development.

    Kind Regards,
    Nithin

  • Tony G
    • Mr. LetsFixTheWorld

    Point #1 is a request for a defective feature to be fixed. It’s a bug report, not a suggestion. Making a feature “work” shouldn’t be described as “handy”.

    To be clear: Please fix the bug that text isn’t replaced in all places, or document that specific text types are not and may never be replaced. That way people know what to expect – so that maybe they can look for another plugin that does what this plugin claims to do.

  • Nithin Ramdas
    • Support Wizard

    Hi Tony G ,

    To be clear: Please fix the bug that text isn’t replaced in all places, or document that specific text types are not and may never be replaced.

    I’m not able to replicate any issue which would point to a bug. Could you please explain further about a couple of example strings where you notice the issue?

    I suppose you are referring to the following part as a bug?

    – Case sensitivity needs to be used because the source text is both “smush” and “Smush”. We can’t say “match the original casing. But this also means that we need to create a case sensitive match for every usage.
    – For some replacements the text replacement seems to be based on words, not plain text. So for this exercise, a separate rule is required for Smush, SMUSH, Smushed, smushing, and “smushing!”. I also had to replace “smush” and “to smush” in separate rules.

    Please do note that how the Text Replacement feature works is similar to translation. It helps with translating strings which are i18n ready.

    The above workflow you notice is expected at the moment, ie if you have case sensitivity enabled with the option to replace “Smush” then it’ll only replace the exact text and not “smush”, “SMUSH” etc which would have a translation would work too.

    You’ll need to switch to “case insensitive” if you want to apply all the text types.
    [attachments are only viewable by logged-in members]

    In the above example screenshot, it should replace any text which has “Smush”, “SMUSH”, “smush” etc to “compression” and it won’t replace “Smushing”, “smushed” etc, which is an expected behaviour in translation.

    Looking forward to your response.

    Kind Regards,
    Nithin

  • Nithin Ramdas
    • Support Wizard

    Hi Tony G ,

    To be clear: Please fix the bug that text isn’t replaced in all places, or document that specific text types are not and may never be replaced.

    I’m not able to replicate any issue which would point to a bug. Could you please explain further about a couple of example strings where you notice the issue?

    I suppose you are referring to the following part as a bug?

    – Case sensitivity needs to be used because the source text is both “smush” and “Smush”. We can’t say “match the original casing. But this also means that we need to create a case sensitive match for every usage.
    – For some replacements the text replacement seems to be based on words, not plain text. So for this exercise, a separate rule is required for Smush, SMUSH, Smushed, smushing, and “smushing!”. I also had to replace “smush” and “to smush” in separate rules.

    Please do note that how the Text Replacement feature works is similar to translation. It helps with translating strings which are i18n ready.

    The above workflow you notice is expected at the moment, ie if you have case sensitivity enabled with the option to replace “Smush” then it’ll only replace the exact text and not “smush”, “SMUSH” etc which would have a translation would work too.

    You’ll need to switch to “case insensitive” if you want to apply all the text types.
    [attachments are only viewable by logged-in members]

    In the above example screenshot, it should replace any text which has “Smush”, “SMUSH”, “smush” etc to “compression” and it won’t replace “Smushing”, “smushed” etc, which is an expected behaviour in translation.

    Looking forward to your response.

    Kind Regards,
    Nithin

  • Tony G
    • Mr. LetsFixTheWorld

    From the OP: “Change the name Smush to Compression for this exercise.” Now go around your dashboard pages and look for the word Smush. That’s all I’m talking about here.

    I’m not talking about lower case “smush” that needs a separate rule for “compression”. We get that. Add another rule for that and notice that all text isn’t changed for that either.

  • Nithin Ramdas
    • Support Wizard

    Hi Tony G ,

    From the OP: “Change the name Smush to Compression for this exercise.” Now go around your dashboard pages and look for the word Smush. That’s all I’m talking about here.

    Executing this action will modify all instances of the text “smush” to “compression”. Based on my observations, once implemented, it does indeed change all respective strings as specified with “Case Insensitive” enabled . So please advise if I’m missing out on anything specific regarding this.

    The above action, won’t be changing “smushing” or “smushed” strings to “compression” which is the expected workflow since it works the same as how when a string is translated and will require different rules for “smushing”, “smushed” strings.

    If you are referring to such text types ie “smushing”, “smushed” etc as mentioned in the initial response, we’ll be checking whether different text types could be considered as a feature down the roadmap.

    If the above isn’t what you are referring then please do share a screenshot of the issues noticed, so that we could have a better idea.

    Please advise.

    Kind Regards,
    Nithin

  • Tony G
    • Mr. LetsFixTheWorld

    Examples…

    The rules, just an example that anyone can use for testing…
    [attachments are only viewable by logged-in members]

    Examples of anomalies follow. There are several more but they are just more examples of replacements not being made in the same areas of WPMU DEV Settings screens.

    [attachments are only viewable by logged-in members]
    [attachments are only viewable by logged-in members]
    [attachments are only viewable by logged-in members]
    [attachments are only viewable by logged-in members]

    I have another example of the text “re-smushing” not being replaced in the Bulk Smush page – can only add 5 images here. This just verifies that only full words are replaced, not word parts. This leads to the request for RegEx so we don’t need to know every possible combination in which text is used.

    Note, I also tried enabling the DEV Dashboard White Label feature for changing plugin names and, as expected, the text processing there is the same.

    This might be the final summary:
    Text Replacement is not getting text in WPMU Settings screens or in admin menus.

    HTH

  • Tony G
    • Mr. LetsFixTheWorld

    Just another example, same pattern.
    (No, this isn’t a real attempt to change text, it’s purely an example. :smile: )

    The rules:
    [attachments are only viewable by logged-in members]
    Confirmation that rules work:
    [attachments are only viewable by logged-in members]
    Confirmation that DEV Settings screens don’t apply the text:
    [attachments are only viewable by logged-in members]

  • Nithin Ramdas
    • Support Wizard

    Hi Tony G ,

    Thanks for the screenshot, I noticed the issue was more noticeable in Defender, I was initially testing using Smush so missed what you pointed out. Sorry about that.

    On checking further, it appears all the highlighted strings are added using JavaScript minified files which is causing the Branda to not pick such text and hence doesn’t work. I can confirm this is a bug and will be reporting this further to Branda’s team’s attention to check what could be fixed in such instances.

    I’m afraid, a workaround for now would be to translate the strings ie create a PO and MO file with all the required changes so that once the MO file is applied it will get fixed.

    It can be translated using Poedit:
    https://make.wordpress.org/polyglots/handbook/translating/glotpress-translate-wordpress-org/poedit/

    Or using plugins like Loco Translate:
    https://wordpress.org/plugins/loco-translate/

    So that the existing English PO/MO could be updated with a white-labeled translation.

    Kind Regards,
    Nithin

  • Nithin Ramdas
    • Support Wizard

    Hi Tony G ,

    I would like to update regarding the issues highlighted in this ticket, we did check further regarding this and I’m afraid the behaviour noticed is more of a limitation rather than a bug.

    This occurs specifically when the Strings are added via JS. The i18 is handled slightly differently in WordPress when it comes to JavaScript libraries/frameworks such as React, Vue, Svelte, Angular, and others.
    https://developer.wordpress.org/block-editor/reference-guides/packages/packages-react-i18n/

    So plugins which use gettext filter like Branda won’t be able to detect such strings and hence the behaviour.

    The easiest workflow as suggested would be to consider using PO/MO files for now. I’ll make sure to bring this further to our Documentation teams to highlight these in the Branda docs too.

    We’ll be looking at improving the workflow in Branda TextReplacement down the roadmap and will be considering whether this could be added as a feature in future updates.

    Kind Regards,
    Nihin