fatbones

Hi Julien,

I hope you’re doing well. I wanted to follow up with a more detailed technical explanation of an additional issue I’ve identified when using wpLingua in combination with Contact Form 7, specifically regarding how form structures are automatically translated.

Technical Report: Aggressive Auto-Translation Issues Between wpLingua and Contact Form 7

1. General Description of the Problem

wpLingua currently applies overly aggressive translation rules to Contact Form 7 forms. The plugin does not sufficiently distinguish between:

• Human-readable text strings (which should be translated), and
• Technical identifiers (which must never be translated).

As a result, wpLingua attempts to translate field names, identifiers, internal parameters, group names, and shortcode syntax, which leads to broken form logic and unexpected behaviour.

This is not a cosmetic issue; it directly affects form validation, conditional logic, submission handling, and backend processing.

2. Affected Elements That Must Never Be Translated

In Contact Form 7, many English words are not natural language, but part of the form’s internal API. Translating them breaks the form.

Examples of elements that must remain untouched:

• Field names your-name your-email your-country type-of-enquiry your-message
• Field types and syntax text* email* select* textarea*
• Parameters and directives id: maxlength: minlength: autocomplete: first_as_label akismet: data:
• Group and conditional identifiers [group other-queries-selected] [/group]
• Counter and logic shortcodes [count your-message down]

All of the above are programmatic identifiers, not translatable content.

3. Concrete Example Where the Problem Appears

In a form like the following (simplified excerpt):

[label] Full name * [text* your-name id:wpcf7-data1 placeholder "Your name here"] [/label]

[label] Country of residence *
[select* your-country data:countries.olympic
id:wpcf7-data4 autocomplete:off
first_as_label “— Select a country —“]
[/label]

[group other-queries-selected]
[textarea* your-message minlength:5 maxlength:700]
[/group]

wpLingua currently risks translating:

• your-country
• other-queries-selected
• first_as_label
• your-message

This causes:

• Conditional groups to stop working
• Required fields to fail validation
• Submitted data to be ignored or treated as empty
• Form logic to silently break without visible errors

4. Expected Translation Behaviour

From a technical standpoint, only literal user-facing strings should be translated, such as:

• Label text: "Full name" "Country of residence"
• Placeholder text: "Your name here" "--- Select a country ---"
• Option labels: "Participate in an interview" "Share a personal story" "Other queries"

In short:

Only text enclosed in quotation marks should be considered translatable.

Everything else must be treated as protected syntax.

5. Recommended Internal Safeguard (Conceptual)

From an implementation perspective, wpLingua should:

• Detect Contact Form 7 shortcodes ([text], [select], [group], etc.)
• Lock all identifiers, parameters, and attribute names
• Apply translation exclusively to quoted strings
• Explicitly ignore:
  • Field names
  • IDs
  • Parameters
  • Group identifiers
  • Conditional logic blocks

This would make wpLingua fully compatible with CF7’s internal logic while preserving translation quality.

6. Final Notes

I believe this is a critical compatibility issue, not a corner case. Contact Form 7 is widely used, and many advanced forms rely heavily on internal identifiers and conditional logic.

If you agree, I’d be happy to continue analysing this with you once my current project delivery is completed, and we can go through real-world edge cases step by step.

Best regards,

Solved. The following is the PHP source code that must be saved into /wp-content/mu-plugins folder (create if it doesn’t exist). Any name, p.e. ‘teachpress-force-id-order.php’ :

<?php
/*
Plugin Name: teachpress – Force Publications Order by ID DESC
Description: Overrides teachpress admin publications list so it is always ordered by publication ID in descending order.
Author: fatbones
Version: 1.0
*/

// ========================================================================
// This mu-plugin automatically forces TeachPress admin publication list to always use ID DESC ordering.
//
// IMPORTANT: This hook modifies the request BEFORE TeachPress processes its query.
// ========================================================================

add_filter(‘request’, function ($query_vars) {

// Check if we are in the TeachPress publications admin page
if (is_admin() && isset($_GET['page']) && $_GET['page'] === 'publications.php') {

    /* 
     * TeachPress reads ordering parameters from $_GET['orderby'] and custom SQL fragments.
     * We replace them with ID DESC.
     */

    // Force SQL-like order parameter TeachPress expects.
    $_GET['orderby'] = 'id DESC';

    // Clean potential interfering parameters.
    unset($_GET['order']);
    unset($_GET['orderbydir']);

    // Remove WP's default ordering vars if present.
    unset($query_vars['orderby']);
    unset($query_vars['order']);

    // Apply our forced ordering
    $query_vars['orderby'] = 'id';
    $query_vars['order']   = 'DESC';
}

return $query_vars;

});

Hello,

I disabled the Complianz plugin and cleared the cache on both the server and browser sides, but everything remains the same. I have another website that uses the same theme and page structure. However, that website has no issues or conflicts with wpLingua, which is why I can’t understand how the translated version of that page is behaving on this new website.

Best,

@moderator
Ok, thanks for notifying that. May the author share the screenshots thru websites like https://pasteboard.co/ avoiding to capture the website address and then post them here?

Hi Michael,

I’ve finally developed a small and working PHP code snippet to customize the publication file type icons directly from the child theme, so no changes will be made to the original teachpress plugin files. You can see the result at https://observatorio-sobre-interseccionalidad.csic.es/publicaciones/

The only previous step for those who want to achieve these results is to create a custom icon library from fontello.com

If you’d like me to provide you with these lines of code, please let me know, and I’ll be happy to send them to you privately so you can check them and add them in your next update if you deem it appropriate.

Affected child theme files: functions.php ; style.css

Hello again,

Regarding my two additional questions, the reason for the first one is that the editor is reconsidering making changes to the original texts, in terms of removing words that are currently in bold, modifying the structure of the texts, partially altering expressions and certain words used in Spanish, etc. so that the English translations are as faithful as possible and match what is really intended to be conveyed in the translated version.

Based on previous experience, I think that adding an option to the plugin that allows for a dump of some pages or all previous translations in order to perform a new scan of all pages is a smart solution. This will allow us to analyze the results obtained until we achieve the desired goal.

On the second question, my interest in being able to include <HTML> code in translated texts has to do with a situation in which I was involved with a text that included words in Spanish and also in Latin. These Latin words, being universal, must be respected and not translated into English. A practical example of what my problem was is the following:

URL: https://promujerproject.com/#welcome

Original text in Spanish:
“A través de un estudio in situ eficaz y cualitativo… “
Automatic translation into English by wpLingua:
“Through an qualitative study on-site… “
A correct translation would have been:
“Through an in-situ qualitative study… “

Also, in this case, since two text fragments have been generated (one for the normal text and one for the italics), it’s quite difficult to empty the second fragment to transfer the term “in-situ” to the first fragment and thus respect the structure of the original text, since, as the plugin is currently conceived, all fragments must have at least one content and cannot be left empty. This is another reason why IMO the plugin should support <HTML> code, in order to replace the content of the second fragment with an [ASCII] code such as Alt+255, and at the same time apply the italic style to the portion of text that I have transferred from the second fragment to the first.

I hope I have been able to explain well the situations I have faced in my first experience with your wonderful plugin. Honestly, and apart from these issues, it’s a real pleasure to observe the intelligent way in which it does this work.

I would like you to take into account the comments about my experiences in order to try to improve the functionality of the plugin as much as possible.

Best regards,