fff654

thanks Ollie for clear answer

thanks for quick & clear response. Yes CSS trick did perfectly the job

(but not convinced by the plugin aim: it seems to me that when I install your membership plugin, it is *expected* that *all included features* work with existing users … but of course everybody want all free and you need to set the cursor somewhere for paid features)

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.