I have another question regarding strings that contain placeholders. How does the AI handle them? Have we tested this scenario?

For example, if I have a string like "Order %s completed", where %s could be something like the order number, how is it processed by the AI?

There is no direct way, but we can still provide context for the same in the workaround way.

Left some feedback for you @mr-vara! I have an additional request, a question, and sharing a little research I did.

Thank you for the review @desrosj I'll address them and will test it in my test repositories and let you know when it is ready for re-review.

Request: Could you also open a pull request for one repo that will utilize this to demonstrate how this workflow will be called? That will help me see the full picture.

I've created one for Bluehost Plugin here.

Question: Are there any reasons why this should be done in a separate pull request than a PR? For example, if a PR changes some text strings, why would we not want the translations to be updated at the same time? If it's a cost issue (repeatedly translating a string that changes multiple times), we could set the workflow up to only run when certain actions are taken (a specific label is applied, the PR receives an approving review, etc.). That would avoid forgetting to update translations, merge them contextually with the associated code changes, make the translation changes available while testing the PR, etc.

I may not be the final decision-maker on this, but I’d like to share the current thinking and invite feedback or suggestions. There are a few reasons why translations are currently handled in a separate pull request:

1. Separation of Concerns: This approach clearly distinguishes between developer-authored code/content changes and machine-generated translation updates, making each easier to review and track.
2. Review Process Alignment: Code reviews and reviews of AI-generated translations serve different purposes and may require different expertise. Keeping them separate avoids conflating the two.
3. Error Handling: In case the translation workflow encounters issues (e.g., API failures, inconsistencies), isolating it in its own PR helps prevent delays or complications in the main development workflow.

Potential Middle Ground:
We can configure the workflow to run on demand (e.g., via a label or manual trigger) on any branch. This would allow flexibility to generate translations earlier in the process if needed—for example, to support end-to-end testing—without making it mandatory for every PR.

Open to thoughts or alternative approaches!

One thing that I considered while reviewing is that it seems odd we would need to write our own script to perform the translations. I did some searching, and there are a few actions that seem related but I don't believe fit our specific use case. I also looked at the https://github.com/Azure/cli repository, but that also does not appear to satisfy the requirements.

I agree with you regarding writing our own script. Yes, it's odd, but I feel we left with no other choices. I'm open to alternative approaches, if we have any.

@mr-vara

I've created one for Bluehost Plugin newfold-labs/wp-plugin-bluehost#283.

Thanks!

For the reasons to keep translations separate, I think all of those make sense. Especially making the review of the suggested translations from AI a separate and more intentional process. 👍

1. I have few concerns regarding two suggestions:
   Using cache for Python Setup action: The issue here is, if we use cache, it expects a python project setup, i.e., needs a requirements.txt file and it expect it in the caller repository.
2. Separating the python code to a independent file: The issue here with reusable workflow is, it expects the python script to be in the caller repository. Here the solution I can see is, we can download the script and delete it before the commit step.

And as per your suggestion in private chat, @desrosj
I'm ignoring the Python cache for the time being. And for the second one:
I'm going to add an additional actions/checkout step to checkout the workflows repository. Something like:

- name: Checkout workflow related scripts
  uses: actions/checkout
  with:
    repository: newfold-labes/workflows
    path: 'workflow-repo' 

I'll make sure to exclude the workflow-repo directory from any translation tasks, and delete the directory immediately after running the script.

I'll test this first in my personal repositories and will update here.

@desrosj I have addressed the suggestions. For the Python script separation, I've downloaded the file instead of checking out to the entire workflows repo. Please let me know if you think otherwise.

I'm hoping to re-review this today. @mr-vara I just wanted to check that you're happy with where this is at to avoid any reviews from being dismissed for other small changes.

I'm hoping to re-review this today. @mr-vara I just wanted to check that you're happy with where this is at to avoid any reviews from being dismissed for other small changes.

Yes, @desrosj In fact I have addressed all other changes as well.