fff654

super great !

Thanks Brad

hooo, i did not look there, but in your plugin or frontend admin toolbar. OK, clear. And doc has been added in the meantime, nice
My feedback:

Short version: IT ROCKS! This should have been a 2.0, as it brings so much in usability.
(honestly the main plugin dev should have implemented himself that, instead of moving to their $$$ SaaS model copy of DeepL … but that is another debate; you took the opportunity “bring your own key” model and did it well, congrats!)

Detailed version:
The ability to select mutiple posts x multiple languages and start all in one batch = SUPER
Make this available for all CPT = SUPER ALSO

FYI, I tested on 5 big posts (normally mostly translated already) x 6 target languages = it took about 45 minutes (no problem, its automatic, with no click)

my 2 suggestions:

• in the batch window, I would suggest to add a column “strings translated”, example: 267 (string translated), between STATUS and ACTIONS, to have a basic idea of what it did. Currently there is no view if there was a lot translated or nothing new to translate.
  Idealy, it could be “strings translated / total strings”, example 267 / 300 (if 33 where already translated and skipped). That would give a far better view on what is happening behind, especially if your modified your post and run it again or if you retranslate the post again … and permit to stop the process if something is strange.
• for each provider (Gemini in my case, but question is valid for all), you should really recommend the model that works the best and is the cheapest. Because you know your prompt and context you are providing, you have made tests, and clearly big AI model for string translation is probably overkill … so the smallest model as possible -but tested-, you know already for sure.

Note: I had to register with Gemini as I was using previoulsy the Google Translate no key 100% Free method. So:

• With a Gemini key generate as per your link, I got the error “try later”.
• It did work with another Gemini key I am using for something else.

Some questions:

• does it translate only the non-already-translated strings, or the complete post content again ?
• does it skip strings with the class added in the HTML to not translate that element ? (TranslatePress permits to define a class that we can add anywhere in the page or template; and this is VERY useful to avoid stupid translation of adresses or names or original quotes or adverts or special content)
• for more advanced WP users: does it translate the custom fields attached to the post also ? (that are displayed in the frontend by the WP template)
• any plan on slug translation also ? 😉

thanks, all clear

your latest update rocks (automatic language selection and translation starting) = small bits that do increase the workflow when translating many posts in many languages. Thanks a lot.

mmmm….

3 or whatever different (fixed) prompts would still not adapt to the content ;(
It needs to dynamically take the individual h2 that are generated by the main text prompt. 3 fixed prompts will not solve that.
Like : Generate an illustrative image specifically about {current_h2} in the style blablabla (…) that is inserted in an article about {topic} and {keywords}.

Thanks Xylus team.
Some observations (and I regret this comes like that, but at least the solutions will be available for all):
– we fully agree the crap is not coming from you but from the source (not their fault either btw; their code is made for their system)
– I would not have spent time to write a long text here, if I would not think your plugin can be marvelous at the end.
– that was my emails: the modification you propose above is NOT OK. The content mod must be at IMPORT time (=calculated ONCE), just before saving into WordPress DB. Not at display time (=calculated EVERY time, minus cache). And parsing all crap cases and all REGEX, and re-formating all content, including the pictures, is very time/CPU consuming. You understand that if we use you batch import plugin, it is not to import 2-3 events, but MUCH more 🙂 And even if my blog is fully non-profit, I have MANY visitors per day. So efficiency is a must, and that should anyway be the case for all plugins, always.

(note to the support moderator: this is not a support request at all)

To summarize: "we hear your concerns" but "we currently focus on our own AI solutions"

“considering all the benefits of operating with TP AI” … you use the well known marketing technique of pilling tons of wrong arguments to invent a reality. But the true is:

• Getting an API key from any provider takes minutes
• DeepL gives for free 500.000 characters PER MONTH, so 100.000 words PER MONTH. So please do not compare with your “generous” credit per year, you’re not even close.
• not to mention that with other API than DeepL, this is even 3 to 10 times cheaper.

The reality of a decent personal blog, that translates into 4-5 languages: a couple of posts per months already exceed DeepL quota, including the unavoidable modifications that gets the string re-translated if you correct a typo, a comma or whatever.

> €240/year, not even counting additional credits needed

And that for a solution with drawbacks you “forget” to mention, that any other plugin that relies on a real post content will not benefice from the translation as it is not accessible on the backend: search plugin will not index your content; internal links automation will not link your content, SEO plugins only for basic features, any tags optimisation or classification … These compromises were acceptable if a competitive price advantage … gone now, by far. You forgot your non-pro users who help you started. Your choice.

*** That was my indeed frustrated, but kind request. Reading that you’ll do nothing in that direction anytime soon, my choice is now either to leave, or push anyone and myself to hack the code to intercept translation requests and divert them to an alternative API provider, or to interact directly with the database pairs tables (ignoring your code is probably even less headache). And put it on GitHub or as an add-on here for everybody. ***

In the plugin itself, the “attribute” lines has no “PRO” indicated, while the features above and under do have. Leading to think this feature is not PRO … while in fact, usable only with PHP.

Complicating process just for sales, especially as the support page you’ve linked to, do advise not to use PHP for that

disappointing … especially as other similar code insertion plugins permit that. Variable insertion is a basic feature in these types of plugin.

Hope it helps others to make a decision. Bye