robert

PromptAI v1.2 is out! New stuff: Repeater field support (including Repeater Matrix) – see the Readme for details Better config format using JSON and IDs instead of names Auto-migration handles the upgrade for you Your existing configs will automatically convert to the new format, so everything should just work. Still worth making a backup though 😄

PromptAI Module Update V1.1: New Config UI & Individual Buttons! 🎉 Hey everyonre, I just pushed an update to the PromptAI module that replaces the old textarea configuration with a proper form interface at Setup > Prompt AI. No more typing template::source::target::prompt manually – now you get actual fields and buttons like a civilized person! 😄 I also added an "Individual Prompt Buttons" option that lets you create separate "Save + [Custom Label]" buttons for each prompt configuration instead of one generic button. So you can have "Save + Create Summary", "Save + Generate Alt Text", etc. and run just the specific prompt you want. Existing configs migrate automatically, so updates should run smoothly. Feedback welcome as always. The module has now been added to the ProcessWire module list: https://processwire.com/modules/prompt-ai/

I created a successor for my module PromptChatGPT (https://processwire.com/talk/topic/28311-processchatgpt/) with the even more creative name PromptAI. It is more or less a complete rewrite based on the Neuron AI framework. Short description: PromptAI is a Processwire CMS module that utilizes AI to process text fields upon saving. The processed text can be saved back to the original field or a different one on the same page. For image fields, the AI can write image descriptions or populate custom image subfields. The main additions are: Multiple prompt support Provider select support System instructions Support for Image fields All infos can be found here: https://github.com/robertweiss/PromptAI Use cases could include text summaries, proofreading, or generating alt texts for images. Happy prompting 😊

Hello everyone, I'm excited to announce that Version 1.0 of ProcessTranslatePage is now available on GitHub: https://github.com/robertweiss/ProcessTranslatePage Please note that there are some breaking changes in this update. I recommend uninstalling and then reinstalling the module to ensure everything works smoothly. You can use the same DeepL API key that you use with Fluency. After installation, you will (hopefully) see two new fields for the language template. However, only the ⁠'translate_locale' field is required for the module to function properly. Thanks for your patience, I hope you find this update useful!

Hi @Ivan Gretsky and @FireWire, Sorry it took me so much time to respond to the big Fluency update. To be honest, I already refactored my module a couple of months ago to work without any dependencies (except the DeepL API), so Fluency is no longer necessary to use it. Since I only did this refactor for one client, I need to remove some customizations before I can push the new version to Github. I don’t expect this to take too long, so I’m hopeful that I’ll be able to release Version 1.0 for you to test tomorrow or thursday 😊. Thanks for your patience!

Yes, this seems to be the problem. ProcessTranslatePage works with the latest Processwire version, but not with Fluency V2 (yet). @FireWiresorry for the long wait, I did not have time to merge your PR yet, but thanks a lot for your effort!

I think I should add some infos about generating a working API key in the readme ?

Ok, I created a new account at Open AI and generated a test API key, then I got the same error message as you. After adding a payment method, still no luck. But then I generated a new key AFTER adding the payment method, and now it works. Could you check if that works for you too?

Hmm, this is weird. Does the error message already show up on the module config page or while saving a ›real‹ page and choosing ›Save + send to ChatGPT‹? For reference, the attached screenshot shows my feedback which works without errors.

Thanks for all of your comments and suggestions. I renamed the module to PromptChatGPT (thank you @gornycreative for the input!). The renamed repo can be found here: https://github.com/robertweiss/PromptChatGPT Additionally, I have included the composer vendor folder by default, which seems to be a better and easier way to distribute modules. Thanks to @wbmnfktr for bringing this to my attention. Regarding the curl/ssl errors, as you have already deduced, these seem to be linked to the external dependency https://github.com/orhanerday/open-ai. Therefore, if the issues you mentioned persist, we should consider creating a new Github issue there. For easier debugging, I have added a ›test settings‹ option to to verify if ChatGPT responds correctly. I have also included a new option to select templates that should include the dropdown option.

Valid point, I have to admit I never really noticed this was the reason for the ›Process‹ in the modules names. Thanks for the hint!

I couldn’t resist the hype and created a simple module using the ChatGPT API to process field values. You can find it on GitHub here: https://github.com/robertweiss/ProcessChatGPT ProcessChatGPT is triggered upon saving, if you select it in the save dropdown. It processes the value of a page field, which can be set in the module config, using ChatGPT. The processed value can be saved back to the same field or to another field on the same page, which can also be set in the module configuration. You can add commands to the value that will be prefixed to the source field content. This way, you can give ChatGPT hints on what to do with the text. For example, you could add ›Write a summary with a maximum of 400 characters of the following text:‹. One of my clients is already using the module to summarise announcement texts for upcoming music events on their website (Let’s face it, nobody reads them anyway ?). If anyone finds it useful, I would be happy to submit it to the official module list.

Translating only changed fields is quite a good idea, I just added it in v0.7 ? New radio option: Write Mode (replaces the checkbox Overwrite Existing Translation) Translate only if target field is empty Translate only changed fields Overwrite all target fields Caution: the »Changed fields«-option support is currently only one level deep. If you change any value inside a Repeater(-Matrix) or FieldsetPage field, the complete field will be translated. If anybody knows how to get the names of nested fields that changed inside the afterPages::saved hook, please let me know ?

@bernhardSure ? Module Config (sorry for the mixed labeling, I have the german language pack installed ? ): Publish + Translate to all target languages at once: Publish + Translate to single languages (on the left side of the arrow: source language, right: all available (aka not excluded) target languages):

v0.6 is released with the following changes: New setting: Source language (thx for the idea to @Ivan Gretsky and for the pull request to @theoretic) Languages for source and exclude can only be selected if they have been defined in the fluency config first I had to do some refactoring of the translation strings and the module config, so please validate/correct your settings after the update to v0.6!

@studioweb I had a deeper look into the page->name feature request and decided to not include the automatic translation of this field. As I suspected in my last post, there exists already a better solution for this ? If you install the module https://processwire.com/modules/process-setup-page-name/ and activate its option ›Update the name of existing pages‹, the name field will be updated in all languages whenever you change the corresponding field (normally title).

@studiowebThanks ? To prevent possible misunderstandings: you’re talking about the $page->name field, right? This is indeed a special case as it is the only translatable system field I could think of. I would suggest the following mechanism: only translate the page name if the target language name is identical to the source language (and therefore: not translated yet) – and allow users to switch it off in the settings to prevent possible conflicts with other modules modifying the name field on save (e.g. ProcessSetupPageName).

Oh cool, sounds good ? Your addition might be a good fit for the open issue by Ivan Gretsky: https://github.com/robertweiss/ProcessTranslatePage/issues/3 – would it be an option for you to fork my repository on Github so we can merge via a pull request?

Just released v0.5 which includes the following new features: Exclude fields: choose fields which should not be translated Exclude languages: choose languages which should not be translated to Show Single Target Language Buttons: Show all target languages as single buttons in the save dropdown instead of having only one button for all translations Thanks to @Ivan Gretsky for proposing these additions!

Hi Roych, thanks for your feedback! I found the bug – I falsely assumed that the default language id in processwire is always 1022 (which is obviously not the case …). I pushed a bugfix to the github repo (https://github.com/robertweiss/ProcessTranslatePage) and changed the version to 0.0.3. Could you try the bugfix and see if it works for you now?

I created a companion module for Fluency to translate all fields on a page at once: https://github.com/robertweiss/ProcessTranslatePage You can find the corresponding conversation about it in the Fluency thread (link below), but I decided to add the module to the official list so others who have a need for this have an easier time finding it.

Thank you, this would not be possible without your excellent module! I just pushed a new version to Github. The module got some additional features: A config page where you can exclude templates and toggle whether you want to overwrite already existing translations The language selection now uses the settings made in the Fluency config instead of having to configure it twice ? Support for more than one target language (I never needed that but thought it would be nice to have in the future) Support for the ProField Table About the performance: I share your concerns, but my client still forced me to do it ? The largest page I tested had 63 fields (25 textfields, 14 file-descriptions, 24 richtext-fields) and took about a minute to translate, so you really have to take care of the php timeout-settings. To bypass that, I added a small external translate-pagetree script to the repository which can be used in the command line, so you can batch-translate multiple parts of the website (or all of it) at once. As this is not tested very well, a database-backup is recommended before trying!

I’m not quite sure if this is of interest for anyone and if this is the right forum for my post, but I got the client request to build a module extension for Fluency which translates all the text fields in a page with only one click. The module is not really ready for public (or the modules section), as it has no config page yet and was only tested in one ProcessWire installation, but maybe it is useful as a starting point for anyone who is in the same situation as me: https://github.com/robertweiss/ProcessTranslatePage The module checks for fluency-translate permissions and adds a ›Translate and save‹-button to the edit-page. It supports all core language fields, Repeater, FieldsetPage the pro modules Repeater Matrix, Combo and Functional Fields. Caution: for now, the (language-)settings have to be manually edited in the hookPageSave-Method (Lines 64–69).

Hi @adrian, I changed the autoload to true according to your suggestion, so the properties will be added to the $page in the admin as well. Now I get the following error message from Tracy Debugger every time I open an admin page (no error shows up in the frontend): The weirdest thing is: when I duplicate my module and change the classname to something else (TestModule or similar), uninstall the original module and install the copy instead, the error is gone. And when if I remove all the code from the original class except the getModuleInfo method, the error is still there. I checked the behaviour in two other installations, they show the same error. Maybe this is some sort of race condition with autoload modules? I tried to understand the OutputDebugger class mentioned in the error, but did not yet figure out what it does or how it can help ? This issue has no priority at all, but maybe you have an idea where I could look further. Debugging the debugger … ?

Hi @adrian, first of all thanks a lot for your fast and nice reply, this community is always so helpful and motivating! 1) Good idea, I never really used it that way, but I definitely will check it out and change the autoload setting. 2 & 3) Thanks for the hints, I changed the code as you suggested. 4) You are right – in combination with Tracy and usual field configurations, the difference is mostly a formatting preference. As I like using Ray in an external window for debugging, the module helped me to always get identical informations in different environments. Another thing which was important to me is the support for ›subfields‹, so that I can immediately see the content of repeater matrix items inside repeaters inside fieldset page fields etc. etc. (you see the point … ?). The third thing is – as you already mentioned – the support for all kinds of fieldtypes in a more or less consistent and simplified way.