Martin1

If you want to avoid the extra burden of maintaining this on multiple translation services, I think it's best as an add-on. Although I've made everything baked-in for now, I'm looking at the api reference for google and we could abstract and make a DTO for both, however it looks like the implementation would be way more complex on google's side, starting by the fact that the endpoint is not even the same api version. The more I think about it, the more I think I'm overcomplicating things. The way I see it that would be the easiest: I would make a new client for deepl and can already access the account type and api key from your package's config. I would not need to hook into Fluency for managing it. Anything done programmatically to translate, I already can use the public translate() method by adding the glossary id to the options['requestParameters'] The only thing I need to hook on in Fluency would be the "Translate to all languages" field link and rebind a new ajax call with the glossary id to the request parameters, I have not tried but it seems feasible. So then there should not be any need to make anything public or hookable!

Hey @FireWire First of all, thanks a lot for this amazing module! I'm currently working on a project with Fluency + DeepL that needs the glossary feature: https://developers.deepl.com/docs/api-reference/glossaries/openapi-spec-for-glossary-management Since glossaries created on the DeepL website cannot be accessed by the API, they need to be sent to the API with ProcessWire, and translation calls need to have a param with the glossary id for every language pairs. I have most of the work done, and I'd be willing to share it once I clean it up, however I'm not sure how to go about this. My first instinct was to do a stand-alone module with Fluency as a dependency, however I can see that it is heavily locked down with final classes + private and unhookable methods. I'm wondering if there's some interest for this, and if yes, you'd rather have a pull request with the DeepL Glossary feature baked-in, or a pull request which would open up some classes / methods to be extendable, which would allow me to make a new module? Thanks!

Here I was referring here to the Stripe package for Form Builder, but I searched a bit more and he also made another solution with the GoogleClientAPI: https://github.com/ryancramerdesign/GoogleClientAPI/blob/master/GoogleClientConfig.php @markus_blue_tomato if there was a way like this to install the dependency from the module's config screen, would you accept a pull request for this?

Hey I've made a pull request for ratio issues. ? For composer I've seen your post regarding this, personally I'm not a big fan of the solution. Having this 2 separated ways to install a module makes it so that if you require dependencies, an installation from modules.processwire.com would fail, a zipped upload would fail, and an exported site profile with this module would also fail (And it's a no-brainer to include this module for a basic install). Personally, I would include the dependency directly (even Ryan does this), at least until there's a better solution for this problem.

Ok I get it. The Page Reference field as a selected "Parent" to allow an easy Page List selection option, this is what affect the search here. If I remove the selected parent, only keep the template and use the AsmSelect instead, then it doesn't affect the search. It's a little less convenient to select in the admin, but I can deal with it.

Hi! I have a "company" template with a Page Reference field "sectors" which is linked to a tree of nested pages which all have a "sector" template. It is possible to link to any nested "sector" and, after selecting pages in the admin, the PageArray field doesn't seem to have knowledge of the hierarchy for the selected pages. However, when I search companies using a subfield search ex: $pages->find("template=company, sectors.title*=$search"); I'm only getting results of companies when I search the title of any root sectors, and I'm not getting any results when I search the title for any of the nested sectors. It seems that the PageArray field is just looking for the top sectors even though nested sectors are also selected, they all share the same "sector" template and the Page Reference field shouldn't have knowledge about the hierarchy. Is there something I'm misunderstanding? Thank you

Hi, I've come across this problem or a similar one. For me it was because I've added the "page-publish" permission. To allow a user to edit a page, the "page-publish" had to also be checked. However I am using ProDrafts and didn't want to allow this. Finally saw that @ryan published a dev version of ProDrafts about a week ago and installing it completely solved the issue.