Submitting the WordPress AI Translation Optimization Project to GitHub: A Milestone Wrap-Up

Over the past period, I have been optimizing the English translation workflow for Chinese WordPress technical articles.

Initially, I just wanted to improve the English translation quality of SlyTranslate, but it gradually expanded to include:

• Full-article translation with GLM 5.2;
• Gutenberg block structure protection;
• Code block and inline code placeholdering;
• HTML attribute and image alt text processing;
• Placeholder duplication, omission, and collision detection;
• Category, tag, series, and featured image synchronization;
• W3 Total Cache and Polylang cache compatibility;
• Production deployment and rollback verification;
• Comparative testing of models such as GLM, DeepSeek, Gemini, and OpenAI.

As the custom code, test scripts, issue analyses, and production verification records continued to grow, the original temporary debugging directory was no longer suitable for long-term maintenance.

This time, I organized the entire project and committed it to a private GitHub repository. For the current stage, this is not just a code backup; it also serves as a phased conclusion to this round of translation quality optimization.

1. Why a GitHub Repository Was Needed

The previous project directory name was:

slytranslate-glm52-taxonomy-debug-2026-07-16

slytranslate-glm52-taxonomy-debug-2026-07-16

This name was well-suited for a temporary troubleshooting workspace because it clearly recorded:

• The translation plugin used;
• The current model;
• The taxonomy synchronization issue being investigated;
• The project creation date.

However, as the issues were gradually resolved, the project content was no longer limited to GLM 5.2 or taxonomy synchronization.

The current code actually covers a more complete WordPress AI translation pipeline, including translation requests, content protection, result verification, taxonomy synchronization, and production deployment. Continuing to use the original temporary directory name could easily lead people to mistakenly believe it was just a concluded troubleshooting effort.

Therefore, I ultimately named the repository:

wordpress-ai-translation-pipeline

wordpress-ai-translation-pipeline

The local directory was also updated accordingly to:

/home/wangqiang/code/wordpress-ai-translation-pipeline

/home/wangqiang/code/wordpress-ai-translation-pipeline

This name is not tied to a specific model or a specific date. In the future, even if I switch from GLM 5.2 to OpenAI, DeepSeek, or another model, I will not need to change the project name again.

2. Why a Private Repository Was Ultimately Chosen

Initially, I considered making the project a public repository.

To determine if it was suitable for public release, I had Codex perform a read-only sensitive information audit on the entire Git repository. The audit scope included:

• All tracked files in the current workspace;
• Untracked and ignored files;
• All reachable Git commits;
• Historical blobs;
• Branches and tags;
• Commit author information;
• Images, configurations, documentation, and test files.

The audit results showed that the repository did not contain:

• API Keys;
• Alibaba Cloud AccessKeys;
• GitHub Tokens;
• SSH private keys;
• Database passwords;
• WordPress Salts;
• Cookies or Sessions;
• Real public IP addresses;
• Database backups and SQL files.

From a credential security perspective, the results were quite ideal.

However, the repository still contained some real production environment context, such as:

• Production domains;
• WordPress server directories;
• SSH aliases;
• Local workspace paths;
• Real article, category, and series IDs;
• Production check commands;
• Source code and verification materials collected from installed plugins.

This information is not equivalent to passwords and cannot directly grant server access, but setting up a public repository would require further consideration of:

• Whether to sanitize historical commits;
• Whether to rewrite the entire Git history;
• Whether the third-party plugin source code permits redistribution;
• The licenses for plugin logos, translation files, and promotional images;
• Which files should be converted to patches instead of full source code.

Continuing to address these issues is not impossible, but for the current goal, the maintenance cost was clearly too high.

My primary needs were simply to:

• Save the project code;
• Record modification history;
• Facilitate ongoing maintenance by Codex;
• Identify the specific commit version corresponding to the production environment;
• Quickly compare and roll back when new issues arise.

Therefore, choosing a private repository ultimately better fit my practical needs.

3. Creating an Empty Repository to Avoid Initial Push Conflicts

Because the local repository already contained:

• A main branch;
• More than 10 historical commits;
• 4 existing tags;
• A complete local Git history;

When creating the repository on GitHub, I did not select:

Add a README file
Add .gitignore
Choose a license

Add a README file
Add .gitignore
Choose a license

Keeping the GitHub side empty avoids branch conflicts during the initial push of the local repository caused by an extra initialization commit on the remote.

After creating the repository, I verified the current state locally:

cd /home/wangqiang/code/wordpress-ai-translation-pipeline

git status --short --branch
git branch --show-current
git remote -v

cd /home/wangqiang/code/wordpress-ai-translation-pipeline

git status --short --branch
git branch --show-current
git remote -v

The result at that time was:

## main
main

## main
main

git remote -v produced no output, indicating that the local repository was not yet linked to a remote address.

4. Unifying the Local Directory and GitHub Repository Names

Before linking the remote repository, I first renamed the old directory:

cd /home/wangqiang/code

mv \
  slytranslate-glm52-taxonomy-debug-2026-07-16 \
  wordpress-ai-translation-pipeline

cd /home/wangqiang/code

mv \
  slytranslate-glm52-taxonomy-debug-2026-07-16 \
  wordpress-ai-translation-pipeline

Then I entered the new directory to check:

cd /home/wangqiang/code/wordpress-ai-translation-pipeline

pwd
git status --short --branch
git remote -v

cd /home/wangqiang/code/wordpress-ai-translation-pipeline

pwd
git status --short --branch
git remote -v

The output was:

/home/wangqiang/code/wordpress-ai-translation-pipeline
## main

/home/wangqiang/code/wordpress-ai-translation-pipeline
## main

Renaming the directory does not change Git commits, tags, or branches, because the .git directory moves along with the project.

However, VS Code and Codex had the old workspace open, so after renaming the directory, I needed to reopen:

/home/wangqiang/code/wordpress-ai-translation-pipeline

/home/wangqiang/code/wordpress-ai-translation-pipeline

5. Linking the GitHub Remote Repository

After confirming the local directory was correct, I added the remote repository:

git remote add origin https://github.com/用户名/wordpress-ai-translation-pipeline.git

git remote -v

git remote add origin https://github.com/用户名/wordpress-ai-translation-pipeline.git

git remote -v

The check result should look similar to:

origin  https://github.com/username/wordpress-ai-translation-pipeline.git (fetch)
origin  https://github.com/username/wordpress-ai-translation-pipeline.git (push)

origin  https://github.com/username/wordpress-ai-translation-pipeline.git (fetch)
origin  https://github.com/username/wordpress-ai-translation-pipeline.git (push)

This step only established the remote link; no content was uploaded.

6. Pushing the main Branch for the First Time

Next, I pushed the local main branch:

git push -u origin main

git push -u origin main

The initial push wrote 663 objects, totaling about 2.62 MiB of data.

After the push completed, the local main automatically started tracking:

origin/main

origin/main

This means that when executing standard git push and git pull on the current branch in the future, Git will already know the corresponding remote branch.

7. Continuing to Push Existing Tags

In addition to the commit history, the repository also contained 4 tags:

analysis-baseline-2026-07-17
draft-only-candidate-2026-07-17
installed-baseline-2026-07-17
installed-series-baseline-2026-07-17

analysis-baseline-2026-07-17
draft-only-candidate-2026-07-17
installed-baseline-2026-07-17
installed-series-baseline-2026-07-17

These tags were used respectively to record:

• Analysis baseline;
• Candidate version saved as draft only;
• Production installation source code baseline;
• PublishPress Series installation source code baseline.

Tags are not all uploaded automatically with a standard branch push, so I separately executed:

git push origin --tags

git push origin --tags

All 4 tags were successfully created in the remote GitHub repository.

8. Verifying Local and Remote Commits Match

After the initial push, I did not rely solely on the “success” message returned by the command. Instead, I ran a synchronization check again:

git fetch --prune --tags origin

git status --short --branch

echo "本地 main："
git rev-parse main

echo "远程 main："
git rev-parse origin/main

echo "标签："
git tag --list

git fetch --prune --tags origin

git status --short --branch

echo "本地 main："
git rev-parse main

echo "远程 main："
git rev-parse origin/main

echo "标签："
git tag --list

At that time, the local and remote main yielded the exact same commit hash:

d365b57244542989e2205f9a94eeb283d052f0eb

d365b57244542989e2205f9a94eeb283d052f0eb

Additionally, all 4 tags could be listed normally locally.

This step proved that:

• Local commits had been fully uploaded;
• There were no differences between the remote branch and the local one;
• No tags were missing;
• The current workspace had no pending modifications to commit.

9. Fixing Legacy Paths Left After Repository Renaming

Although the directory had been renamed, 3 references to the old workspace name remained in the project documentation.

I used an exact search to check:

git grep -nF 'slytranslate-glm52-taxonomy-debug-2026-07-16' -- . \
  || echo "未发现旧目录名称引用"

git grep -nF 'slytranslate-glm52-taxonomy-debug-2026-07-16' -- . \
  || echo "未发现旧目录名称引用"

The results showed that evidence/installed-sources.md still recorded:

• The old workspace path;
• The old SlyTranslate source code save path;
• The old MU Plugin save path.

These items do not pose a security issue, but they were inconsistent with the current directory, so I uniformly replaced them with:

wordpress-ai-translation-pipeline

wordpress-ai-translation-pipeline

After the modifications, I created a commit:

e29a3a9 docs: update workspace path after repository rename

e29a3a9 docs: update workspace path after repository rename

And pushed it to GitHub again.

10. Improving .gitignore

After establishing the repository, there was one important finalization task left: improving .gitignore.

The original .gitignore only contained:

/tmp/
/.agents/
/.codex/
*.log
*.tmp

/tmp/
/.agents/
/.codex/
*.log
*.tmp

This was basically sufficient for a temporary debugging repository, but as a long-term maintenance project, the coverage was clearly inadequate.

The new .gitignore added the following categories:

• Editor and system files;
• .env and local configurations;
• wp-config.php;
• Keys and certificates;
• Database export files;
• Logs and raw API responses;
• Backup files;
• Editor temporary files;
• Archive files;
• Python runtime files and virtual environments.

For example:

# Environment and local configuration
.env
.env.*
!.env.example
wp-config.php
wp-config-*.php
credentials.json
secrets.json
.secrets/

# Private keys and certificates
*.pem
*.key
*.p12
*.pfx
*.crt
*.cer

# Database dumps
*.sql
*.sql.gz
*.dump
*.sqlite
*.sqlite3

# Backups and temporary files
*.bak
*.bak-*
*.backup
*.orig
*.old
*.save
*.swp
*.swo
*~
*.tmp

# Environment and local configuration
.env
.env.*
!.env.example
wp-config.php
wp-config-*.php
credentials.json
secrets.json
.secrets/

# Private keys and certificates
*.pem
*.key
*.p12
*.pfx
*.crt
*.cer

# Database dumps
*.sql
*.sql.gz
*.dump
*.sqlite
*.sqlite3

# Backups and temporary files
*.bak
*.bak-*
*.backup
*.orig
*.old
*.save
*.swp
*.swo
*~
*.tmp

This does not replace manual audits, but it reduces the likelihood of accidentally committing sensitive configurations, logs, and backup files in the future.

11. Untracking Three Historical Backup Files

The sensitive information audit also revealed that three backup files already tracked by Git existed in the repository:

TranslationValidator.php.bak-20260715-093756
TranslationValidator.php.bak-restore-original-20260715-101725
TranslationValidator.php.bak-runaway-ratio-2026-07-14-134954

TranslationValidator.php.bak-20260715-093756
TranslationValidator.php.bak-restore-original-20260715-101725
TranslationValidator.php.bak-runaway-ratio-2026-07-14-134954

No credentials were found in these files themselves, but continuing to track them presented two issues:

1. It increased the scope for source code audits and comparisons;
2. Codex might later misidentify which file was the currently active version.

Therefore, I used git rm --cached to remove them from the Git index while keeping the local files.

After committing, Git showed:

delete mode 100644

delete mode 100644

Here, delete mode only indicates that they were deleted from the current version of the Git repository; it does not mean the files on the local disk were deleted.

I then performed a verification:

git check-ignore -v 文件路径

git check-ignore -v 文件路径

All three files were matched by the following rule:

*.bak-*

*.bak-*

Meanwhile, the local files still existed.

These modifications resulted in the commit:

32fd767 chore: expand gitignore and untrack backup files

32fd767 chore: expand gitignore and untrack backup files

12. Why This Counts as a Phased Conclusion

Committing to GitHub this time does not mean the WordPress AI translation pipeline will never need modification again.

In the future, the following may still occur:

• New Gutenberg block compatibility issues;
• New placeholder collision scenarios;
• Unstable output for long articles;
• Changes in model APIs;
• Internal interface changes after SlyTranslate upgrades;
• Compatibility issues with Polylang, PublishPress Series, or W3 Total Cache;
• Better translation results from OpenAI or other models.

However, compared to the beginning, a much clearer foundation has now been established:

• The code is no longer stored only in a temporary directory;
• Every fix has a distinct commit;
• Production versions can be mapped to a specific Commit;
• Key analysis nodes are preserved via tags;
• The local directory and remote repository names are unified;
• GitHub retains the complete history;
• .gitignore now covers common sensitive files and runtime artifacts;
• The production environment still strictly requires explicit authorization before deployment.

Therefore, this work marks a transition from “continuous trial and error and temporary fixes” into a stage of “long-term maintainability and gradual iteration”.

13. Future Workflow

Going forward, it makes sense to continue using the following workflow:

Discover translation or synchronization issues
→ Locate them in the local repository
→ Codex modifies the code
→ Offline verification
→ Check Git diff
→ Create a commit
→ Push to GitHub
→ Deploy to production after explicit authorization
→ Verify production results

Discover translation or synchronization issues
→ Locate them in the local repository
→ Codex modifies the code
→ Offline verification
→ Check Git diff
→ Create a commit
→ Push to GitHub
→ Deploy to production after explicit authorization
→ Verify production results

Here, GitHub is not responsible for automated deployment, nor does it directly dictate production environment modifications.

It primarily handles:

• Code version management;
• Preservation of fix records;
• Change review;
• Stable version identification;
• Basis for rollbacks;
• Synchronization across multiple workspaces.

For a translation system that is still undergoing continuous adjustments, this relatively conservative approach is more reliable than directly configuring GitHub Actions for automated deployment.

14. Phased Summary

This round of WordPress English translation quality optimization started with model selection and gradually expanded to content structure protection, placeholder validation, taxonomy synchronization, caching issues, and production deployment management.

Many issues could not be solved by simply tweaking a prompt; they required coordination among the model, plugins, WordPress content structure, and caching system.

After committing the project to GitHub, these modifications finally evolved from a scattered set of debugging results into a long-term project with history, versioning, and boundaries.

The repository remains private, and automated deployment is not enabled. For the current stage, this is sufficient.

There is no need to continue expanding code complexity for marginal theoretical improvements. A more reasonable approach is to let the current solution run stably, continue observing it in real article translations, and then fix issues one by one as they clearly emerge.

From this perspective, this GitHub repository initialization can indeed be seen as the formal conclusion of this phase of translation quality optimization.