Create a Dedicated ChatGPT Project to Optimize English Blog Translation: Organize Past Sessions and Standardize Evaluation

Recently, I have been adjusting the English translation workflow for my Chinese technical articles on WordPress.

I initially used AutoPoly, then started testing SlyTranslate, and subsequently conducted practical translation comparisons between Zhipu GLM 5.2 and DeepSeek.

So far, I have reached a fairly clear preliminary conclusion:

Under the current test articles and evaluation criteria, DeepSeek’s English translation quality is inferior to that of GLM 5.2, so there is no need to continue testing DeepSeek at this stage.

The next direction worth considering is testing OpenAI in a local environment and comparing the results with GLM 5.2. If OpenAI’s translation quality shows a significant improvement, I will further evaluate the deployment challenges caused by the Alibaba Cloud Hangzhou production server’s inability to directly access foreign APIs.

As the volume of testing increases, the related conversations have also started to scatter across standard chat logs:

• AutoPoly alternative plugin selection
• SlyTranslate installation and configuration
• GLM 5.2 translation quality testing
• DeepSeek API integration and translation comparison
• Long article translation stability
• Gutenberg block and code block protection
• Prioritizing translation quality versus ad platform applications

Although these conversations all relate to English translation, they were previously mixed into standard chat logs.

If I continue this way, when comparing OpenAI later, it will be easy to lose track of previous testing processes and interim conclusions, or to redundantly discuss issues that have already been verified.

Therefore, I decided to create a dedicated ChatGPT project for this work:

English Blog Translation Quality Optimization

During this organization process, I also encountered an issue related to the project memory mode.

1. Why Create a Dedicated Project?

Creating this project was not to translate a specific article, but rather to solve the following issues long-term:

1. Determine an automatic translation tool suitable for a WordPress technical blog.
2. Compare the English translation quality of different large language models.
3. Ensure that Gutenberg blocks, HTML, shortcodes, and code blocks are not broken.
4. Reduce the manual review and correction time per article.
5. Control API costs, translation time, and server maintenance costs.
6. Ultimately form a stable, simple, and sustainable English content production workflow.

Currently, the comparison between DeepSeek and GLM 5.2 is complete.

Based on actual test results, DeepSeek has not yet demonstrated enough value to replace GLM 5.2. Therefore, the focus of the next stage is no longer testing domestic models, but rather considering whether it is necessary to include OpenAI for comparison in a local environment.

This is no longer a one-off article translation task, but a long-term project requiring continuous evaluation, ongoing adjustments, and eventual deployment to a production environment.

Consolidating related chats into a single project makes it easier for subsequent conversations to reference previous configurations, test results, and decision rationales, while also avoiding the need to re-explain the website environment and translation requirements every time.

2. Selecting “Project Only” Memory When First Creating the Project

When I first created the project, I selected the “Project only” memory.

According to the interface description, this mode offers strong isolation:

• The project can only access memory within the project itself.
• Chats outside the project cannot reference project content.
• Chats inside the project will also not reference external chats.
• The memory mode cannot be modified after the project is created.

This mode is suitable for independent projects that require strict context isolation.

However, my actual need was not complete isolation.

I wanted to move previously completed AutoPoly, SlyTranslate, GLM 5.2, and DeepSeek related conversations into the new project to serve as reference material for the next stage of testing OpenAI.

When I tried to move existing chats into the project, the interface prompted:

Chats cannot be moved into or out of projects using project-only memory.

In other words, in the ChatGPT interface I am currently using, selecting “Project only” memory prevents migrating existing conversations into it.

This conflicted with my original intention for creating the project.

3. Deleting the Original Project and Re-selecting “Default” Memory

Since the memory mode cannot be modified after project creation, I did not keep the original empty project. Instead, I deleted it and created a new one.

When creating it the second time, I expanded the memory settings in the top right corner and selected:

Default

The interface description stated:

This project can access memory from external chats, and vice versa.

This better matched my current needs.

My main goal was not to build a completely closed translation testing environment, but to consolidate existing AutoPoly, SlyTranslate, GLM 5.2, and DeepSeek test conversations, and to continue advancing based on previous conclusions.

It is important to note that the project memory mode is determined when the project is created.

At least in the interface I am currently using, once the project is created, you can only view the current memory mode and cannot directly switch it.

Therefore, before creating a project, it is best to determine whether you need to move existing chats.

If the main purpose is to organize past conversations, selecting “Default” will be much more convenient.

4. Adding Dedicated Instructions in Project Settings

After recreating the project, I entered the project settings and placed the previously organized translation rules into the “Instructions”.

These instructions are not for a specific article, but serve as the long-term background, constraints, and evaluation criteria for the entire project.

Since DeepSeek has already completed testing, the project description should no longer list it as a “model to be tested”.

The adjusted project instructions are as follows:

This project is used to continuously improve the English translation quality of Chinese WordPress technical articles and to determine a stable, long-term automatic translation solution.

Currently using SlyTranslate, with GLM 5.2 as the primary production model at this stage. DeepSeek has completed comparative testing; in existing test articles, its English translation quality is inferior to GLM 5.2, so testing is suspended for now. The next stage may involve comparing OpenAI in a local environment.

Do not consider the current tools and models as permanent solutions; adjustments should be made based on actual test results.

When processing translations, evaluations, and technical solutions, please follow these requirements:

1. Preserve Gutenberg block structures, HTML tags, shortcodes, image placeholders, links, tables, and code blocks.
2. Do not translate code, commands, parameters, file paths, domain names, URLs, product names, or plugin names.
3. Technical terms should be accurate and natural, avoiding literal translations and obvious machine translation artifacts.
4. Maintain the authentic, restrained, and credible tone of a personal technical blog; do not add exaggerated or overly promotional language.
5. When evaluating models, focus on comparing technical accuracy, English naturalness, structural integrity, long article stability, processing speed, and API costs.
6. Apply consistent evaluation criteria to the same test article; do not change the judging standards just because the model is different.
7. The current production server is located in Alibaba Cloud Hangzhou; network connectivity and deployment feasibility must be considered when calling foreign APIs.
8. During troubleshooting or configuration, advance only one clear step at a time. Wait for me to return the execution results before providing the next step.
9. Do not introduce numerous plugins, complex code, or high maintenance costs for minor theoretical improvements; prioritize stable, simple, and sustainable solutions.
10. The ultimate goal is not to pursue perfect English for a single article, but to establish a long-term production workflow that approaches the quality of manual re-translation at an acceptable cost and operational volume.

These rules basically cover the aspects I care about most right now:

• WordPress content structures must not be broken.
• Technical content must be accurate.
• English phrasing must not show obvious machine translation artifacts.
• Model evaluations must use consistent standards.
• Do not introduce overly complex maintenance solutions for minor improvements.
• The final solution needs to be suitable for long-term production, not just optimizing a single article.

The project settings also allow you to control file library access permissions.

I have kept it enabled for now. Later, if I need to upload model test results, translation samples, Markdown reports, or local test scripts, I can continue analyzing them directly within the project.

5. Why Keep DeepSeek Related Conversations

Although it has been confirmed that DeepSeek’s translation quality is inferior to GLM 5.2, this does not mean the DeepSeek related conversations are no longer valuable.

On the contrary, they remain an important part of the project.

These conversations record:

• The DeepSeek API application and integration process
• How to run the local test scripts
• The method for comparing with GLM 5.2 using the same articles
• The basis for concluding that its translation quality is inferior to GLM 5.2
• Why testing DeepSeek has been temporarily paused

If these records are not kept, the same question might arise again after a while:

Is DeepSeek worth retesting?

Keeping the complete testing process clearly shows that this direction was not unattempted, but rather compared using actual articles, leading to an interim conclusion.

Therefore, the DeepSeek conversations should be retained as “completed model evaluation records” rather than “next steps to be tested”.

6. Not All Translation Conversations Need to Be Moved into the Project

After the project was created, the next question was: which existing chats should be moved in?

My website already has a large number of Chinese and English articles. Moving every standard article translation conversation into the project would not only be too numerous, but also might not improve the quality of subsequent judgments.

Therefore, I prioritized moving “solution-oriented conversations” with long-term reference value.

This time, I first organized the following types of content.

1. AutoPoly Alternative Plugin Recommendations

This part records why I decided to abandon the original AutoPoly workflow and the background of choosing SlyTranslate.

It can help with future judgments regarding:

• What problems the current solution solves.
• Why the old plugin was no longer used.
• What the core requirements for an automatic translation tool are.

2. Suggestions for Improving Translation Quality

This part mainly discusses the GLM model, prompts, and room for improving translation quality.

It contains interim judgments on the current production solution and serves as an important foundation for the subsequent comparison with OpenAI.

3. Translation Optimization Suggestions

This part records the actual test results of GLM 5.2, including how it handles different content like titles, summaries, and body text.

Compared to merely discussing model capabilities, these actual operational records are more valuable for reference.

4. DeepSeek API Operation Steps

This part records the DeepSeek API application, invocation, script testing, and final comparison results.

DeepSeek is no longer a model to be tested, but this test proved:

At least under the current articles, prompts, and evaluation criteria, DeepSeek’s translation quality is inferior to GLM 5.2.

Therefore, this conversation should be retained as a completed evaluation archive.

5. Translation Optimization and Ad Selection

Although this part also involves ad platforms, the core issue remains related to English content quality:

Should I apply for a new ad platform first, or improve English translation quality first?

This decision will affect the work focus for the next period, so it is also suitable to keep in the translation project.

The main items I do not plan to move into the project are:

• Standard single-article translation conversations
• Chats that only organize summaries and tags
• CDN troubleshooting unrelated to the translation system
• Client quotes and ad collaboration records unrelated to the project
• Completely abandoned, repetitive attempts with no reference value

This prevents the project content from becoming increasingly cluttered.

7. Moving Existing Chats to the New Project

After re-selecting “Default” memory, the “English Blog Translation Quality Optimization” option in the “Move to project” menu became clickable.

The specific operation is quite simple:

1. Find the conversation you want to organize in the chat list on the left.
2. Click the three dots on the right side of the conversation.
3. Select “Move to project”.
4. Click “English Blog Translation Quality Optimization”.

Once moved, these chats will leave the standard recent conversations list and enter the project page.

The original titles and content of the chats are preserved, requiring no re-copying and pasting.

8. Initial Organization Results in the Project

After completing the first round of organization, the project already contains the following conversations:

• Translation Optimization and Ad Selection
• DeepSeek API Operation Steps
• Translation Optimization Suggestions
• Suggestions for Improving Translation Quality
• AutoPoly Alternative Plugin Recommendations

Currently, these conversations cover the main stages of the entire translation optimization process:

1. Why the original translation plugin needed to be replaced.
2. Why SlyTranslate was ultimately chosen as the current testing tool.
3. What translation quality level GLM 5.2 can currently achieve.
4. Why DeepSeek did not replace GLM 5.2.
5. Why OpenAI needs to be considered in the next stage.
6. The sequence between English translation quality and ad monetization.

Subsequently, if testing OpenAI locally, I can directly create a new chat within this project instead of going back to the standard chat list to reorganize background materials.

9. After Establishing the Project, the Next Step Is Not Continuing to Test DeepSeek

Now that the project is set up, the subsequent direction is fairly clear.

DeepSeek testing is complete, and there is no need to spend time repeating the verification.

The more reasonable tasks for the next stage are:

1. Organize a Unified Test Article

Select a representative long WordPress technical article that ideally includes:

• Gutenberg blocks
• HTML tags
• Bash or PHP code
• Links
• Image placeholders
• Tables
• Longer Chinese technical explanations

This article should preferably use the content previously used for testing GLM 5.2 and DeepSeek, to avoid making fair comparisons difficult after changing the sample.

2. Test OpenAI Locally

Since the Alibaba Cloud Hangzhou production server cannot directly access foreign APIs, the first round of OpenAI testing is better suited for a local computer.

This stage only needs to determine:

• Whether technical accuracy is significantly better than GLM 5.2
• Whether English naturalness has significantly improved
• Whether Gutenberg and HTML structures are stable
• Whether long articles can be processed completely
• Whether the API cost is acceptable

3. Then Decide Whether to Solve the Production Server Network Issues

Only if OpenAI’s translation quality is significantly better than GLM 5.2 is it necessary to continue investigating:

• How the Alibaba Cloud Hangzhou server can access the OpenAI API
• Whether a relay service needs to be added
• Whether translation tasks need to be moved to another server
• Whether it is worth bearing the additional network and maintenance costs

If the quality improves only slightly, there is no need to add complex deployments for a minor theoretical optimization.

10. Subsequent Model Evaluation Status in the Project

Based on the current testing phase, the model statuses can be temporarily summarized as follows:

GLM 5.2

Currently the most stable performer, and the primary translation model in use at this stage.

Advantages include:

• Relatively accurate processing of technical content
• Good English naturalness
• Can be called directly via domestic servers
• Compatible with the existing SlyTranslate and custom plugin workflows
• Low deployment and maintenance costs

The main issue currently is that the translation quality may still not reach the level of manual re-translation via ChatGPT Plus, but the room for significant improvement through further prompt fine-tuning is already quite limited.

DeepSeek

Testing completed.

Under the same test articles and evaluation criteria, the overall English translation quality is inferior to GLM 5.2, so testing has been temporarily suspended.

The experience with DeepSeek’s API integration is still worth keeping, but it is not considered as the primary production model at this stage.

OpenAI

API comparison testing has not yet been completed.

The next stage may involve testing on a local computer first. Whether to further resolve the production server access issue will depend on the actual magnitude of quality improvement.

This kind of status summary is more accurate than simply listing “models to be tested” and can prevent redundant time investments later.

11. A Lesson Learned from This Organization Process

The operation itself was not complicated, but two details were quite important.

The first is the selection of the project memory mode.

If you are just creating a completely independent new project and do not need to import any historical chats, “Project only” memory provides good isolation.

However, if the main purpose is to organize existing conversations and continue advancing based on past discussions, then “Default” memory is more suitable.

At least in the ChatGPT interface I am currently using:

After selecting “Project only”, existing chats cannot be moved into or out of the project; and once the project is created, the memory mode cannot be changed.

The second is updating project instructions in a timely manner.

Project instructions cannot remain stuck in the state they were in when the project was just started.

For example, since DeepSeek has already completed testing and been confirmed as inferior to GLM 5.2, it should no longer be written as “planning to test DeepSeek next”.

Otherwise, subsequent new conversations might still treat DeepSeek as an unverified candidate, leading to redundant discussions and repetitive operations.

12. Summary

English blog translation quality optimization has been ongoing for some time, but previous test records were quite scattered.

By creating the “English Blog Translation Quality Optimization” project this time, I completed the following work:

1. Created a dedicated project for translation quality optimization.
2. Discovered that “Project only” memory is not suitable for migrating existing chats.
3. Deleted the original project and recreated it using “Default” memory.
4. Wrote long-term translation rules into the project instructions.
5. Moved core conversations related to AutoPoly, SlyTranslate, GLM 5.2, and DeepSeek into the project.
6. Clearly recorded that DeepSeek has completed testing and its translation quality is inferior to GLM 5.2.
7. Adjusted the focus of the next stage to local testing of OpenAI.
8. Initially formed a unified workspace for translation optimization and model evaluation.

The completion of the project does not mean the translation solution is finalized.

What can be confirmed right now is:

GLM 5.2 remains the model more suitable for production use at this stage, and DeepSeek testing is temporarily suspended.

What needs to be verified next is not whether DeepSeek can catch up to GLM 5.2, but whether OpenAI’s translation quality can deliver a significant enough improvement to justify further resolving the network and deployment issues for foreign APIs on the Alibaba Cloud Hangzhou production server.

This dedicated project will be used to preserve subsequent testing processes, unify evaluation criteria, and ultimately help me determine a stable, simple, and cost-controlled long-term translation solution for the English blog.

系列导航