Forum Replies Created

Viewing 15 replies - 1 through 15 (of 67 total)
  • Plugin Author Gerard Kanters

    (@gkanters)

    Good observation about numeric values on product pages — this is not actually a bug and not a provider issue. Converting digits to Eastern-Arabic numerals (Arabic) and applying local number formatting (Russian) is linguistically correct localization, which is why Gemini and Groq give the same result: every provider does this by design.

    Whether it’s undesirable depends on what the numbers mean. For measurements/quantities it’s correct. For product codes, SKUs or technical reference values it’s better to keep them verbatim — and you can do exactly that without any code change: the plugin skips any element with the CSS class notranslate. In TablePress, open the table, go to “Table Options” → “Extra CSS classes” and add notranslate. That table (numbers and text) will then stay exactly as-is in every language.

    Plugin Author Gerard Kanters

    (@gkanters)

    Thank you for the detailed test report — it was very helpful in pinpointing the exact issues.

    I have released an update that addresses all the routing problems you reported:

    Fixed in this update:

    “Keep URL slugs in English” now works reliably, including when translated slugs were already stored from a previous run. Previously the setting was only applied to pages that had never been translated. Old translated URLs (e.g. /fr/product/sorciere/) will automatically redirect (301) to the English slug version — no manual cleanup needed.

    French/accented slugs no longer cause a redirect loop. Slugs like cannelé are now correctly transliterated to cannele (matching how WordPress itself handles post names). This resolves the “page isn’t redirecting properly” error on products with accented characters in their name.

    404 on previously-translated product URLs is fixed. If a product slug was re-translated after the source slug changed, the old translated URL is now recovered from history and redirected (301) to the current correct URL instead of returning a 404.

    Regarding your feature request — a checkbox to skip translating WooCommerce product names: that is a interesting request, especially for shops with brand names and product codes. I have noted it as a feature request .

    Please update the plugin, clear your site cache, and test again. Let me know if you run into anything else.

    Remark: WordPress recently introduced a 24 hour time lag for updating plugins to be able to scan for security issues. So you need to use the development version for now. Tomorrow v2.3.7 will be available.

    Plugin Author Gerard Kanters

    (@gkanters)

    You are absolutely right on both issues. I have investigated it and fixed them along with some other issues with WooCommerce like translating the shopping-cart and your account. Which are not very likely to happen, but anyway.

    The  “Keep URL Slugs in English”  is fixed also, but is not advised to use. The URL is translated now for products and it is better for SEO to have a translated slug.

    Please update the plugin to v2.3.6 and let me know if all is fine now and close the ticket.

    Plugin Author Gerard Kanters

    (@gkanters)

    Works as designed

    Plugin Author Gerard Kanters

    (@gkanters)

    Ah, I see the problem now. You have added a new post and that is not showing up on the front page, because the front page is not an actual page, but the “latest blogs”

    That is a very common setting in WordPress, but the plugin was not taking into account that the front page should expire in that setting.

    I changed it, so when you publish a new post, the front page will expire. But only if your homepage is actually a list of blogs. Latest version 2.3.5 now supports this.

    Please test it by creating another blog and see if the homepage cache expires.

    Plugin Author Gerard Kanters

    (@gkanters)

    The issue is that Elementor is using iframes. It happens when you have a different language cookie as admin then the default language. Which off course can happen when testing multiple languages on your site.

    It is however a broader issue with page builders and great that you found this one. I released a new version of the plugin which fixes the problem.

    Let me know if it works and if it does, please close the ticket.

    Plugin Author Gerard Kanters

    (@gkanters)

    Thanks 🙂

    Plugin Author Gerard Kanters

    (@gkanters)

    There is no need to clear it manually. If a page is changed and saved, the cache expires immediately. You might want to warm the cache though, but it is not required.

    Plugin Author Gerard Kanters

    (@gkanters)

    I tested it and it works as designed. If you visit the site and use the switcher to switch to english. The next visit, the site will show english. This is because the plugin will use cookies to remember the users preferred language.

    If you switch back to french using the switcher. The next time you visit the site, it will use french.

    There is still a problem with other languages. Which model do you use for translation ? Or is translation disabled in the admin panel now. If so, disable all “Detectable Languages”. Otherwise users get a 404

    Plugin Author Gerard Kanters

    (@gkanters)

    The plugin sets a cookie if you switch to English and so it is intended behavior that it will redirect to /en

    The 404 is off course not intended. Is that for the homepage (/en) or other pages ?

    Can you provide the site name so I can take a closer look and please use the latest version of the plugin. Version 1.x had some issues with page routing which would cause 404 in some cases.

    Plugin Author Gerard Kanters

    (@gkanters)

    No response, closing ticket.

    Plugin Author Gerard Kanters

    (@gkanters)

    This message does not come from the AI translate plugin. Do you have the plugin: Asset CleanUp: Page Speed Booster ?

    I did a search and this is a known bug of that plugin. You might want to contact the plugin owner.

    Plugin Author Gerard Kanters

    (@gkanters)

    The plugin search translation is implemented like this: If you search something in for instance German language. The plugin translates that to the site language (say English) then uses WordPress search to find the results and displays back the translated pages.

    It is maybe a little bit different from what you describe, since it is possible that some words are translated different in this proces. But it is not possible to use WordPress to search through the translated pages directly, since they are not in the database, but cached on disk and in memory after translation.

    Plugin Author Gerard Kanters

    (@gkanters)

    Thanks for reporting that. The issue seems that custom post type (CPT) and WooCommerce both use archives for pages and products. That type was blocked for translation in the plugin, since translating archives post types is usually not useful and only cost you money.

    I made an exception now for CPT and WooCommerce.

    I also use CPT myself and what I did is make a page for the CPT overview , e.g. products and services. All posts with this type will be translated anyway, since they are not archived pages. See https://netcare.nl/en/products/ as example.

    Anyway, the new release 2.3.1 should solve the problem too ! Please give the plugin a 5 star rating if you like it. It will help spread the word 🙂

    Plugin Author Gerard Kanters

    (@gkanters)

    Sure, no problem. I will include it in the next release. If you are in a hurry, you can use the development version on github https://github.com/gerard-kanters/ai-translate

Viewing 15 replies - 1 through 15 (of 67 total)