On November 6, 2026, I finally decided on my second multilingual project: World History.
This result was somewhat beyond my initial expectations.
As a programmer with over a decade of development experience, my main project right now is Go Learning & Documentation Translations (go-dev). Following my original line of thought, the second multilingual project would likely have been another programming language, such as Rust or Python.
After all, this would maximize the reuse of my existing experience in translation, quality review, and website deployment.
However, after a few days of research, I ultimately chose a non-technical field.
Why the change?
This brings me back to why I created an independent research repository for multilingual projects in the first place.
1. Starting from go-dev to think about the next project
Currently, I am still developing go-dev.
The goal of this project is to make Go language learning resources and related documentation available to a wider audience across different languages.
Initially, I thought the main work of a multilingual website was simply translation.
But as the project progressed, I found the reality to be far more complex than I had imagined.
Beyond translating the main text, it also involves terminology standardization, independent quality review, tracking source content updates, translation version management, multilingual website deployment, and search engine optimization.
For example, after the official English documentation is updated, how do I accurately identify the parts that need to be retranslated?
How do I prevent technical terms from becoming inconsistent across different language versions?
How do I ensure that the translations maintain a good reading experience even after passing automated checks?
These are not one-time tasks; they are part of long-term content maintenance.
After a period of development, I have gradually accumulated a set of practices for handling these issues.
Naturally, I began to consider:
Since I have already invested a lot of effort into building a multilingual content system, can I reuse this experience in future projects?
My first thought was to continue translating learning resources for other programming languages.
Rust, Python, and others have relatively mature official documentation and a sustained demand for learning.
From an engineering reuse perspective alone, this seemed like the most natural choice.
But later, I realized I had overlooked a more important issue.
2. The ultimate goal is not translation, but building a valuable website
I am building a multilingual website not simply to increase the volume of translations.
In the long run, what I truly hope to achieve is:
To gain stable global organic search traffic through valuable multilingual content or interactive tool websites, and to generate sustainable revenue through legitimate advertising channels like Google AdSense.
Therefore, translation is actually just one means of achieving this goal.
If a project can translate 10,000 pages, but few users actually need the content, then even if it is technically feasible, it may not be commercially worth the investment.
Conversely, a project might only have a few hundred pages, but if those pages can continuously satisfy user queries and the maintenance cost is relatively low, then it is equally worth researching.
This made me realize:
I shouldn’t default to choosing another programming language for my next project just because I am skilled at software development.
World geography, world history, public knowledge, open data, and commercial platform documentation all have the potential to become long-term content assets.
Of course, whether these fields are actually suitable for ad monetization still needs to be investigated individually.
I cannot assume they have commercial value just because I am interested in them.
So, I decided to set up an independent research project.
3. Creating the Multilingual Project Research
On November 3, 2026, I created a GitHub repository:
Its initial task was simple:
Before officially starting the second multilingual project, investigate which directions are truly worth the investment.
This repository is not responsible for large-scale translation or developing the official website.
It primarily records research results regarding market, competition, licensing, multilingual coverage, ad monetization, and maintenance costs.
I wanted to avoid the following scenario as much as possible:
Thinking Rust has great prospects today, so I start developing it.
After a while, I find Shopify might be more valuable, so I prepare to switch directions.
Later, I see AI is trending, so I start another new project.
If I keep changing directions based solely on interest or short-term impressions, I might end up investing a lot of time without ever building a website with genuine long-term value.
Therefore, I started establishing unified evaluation criteria for candidate projects.
1. Long-term market demand
Will the content still be needed in the next three to five years?
Which countries and language markets might the target users come from?
Is the demand overly reliant on short-term tech trends?
2. Search competition
What content have existing websites already provided?
Has official documentation already covered most user needs?
Is there still an opportunity for an independent website to offer a better learning, reading, or querying experience?
3. Commercial licensing
Does the original content allow for translation, modification, and commercial redistribution?
Do images, maps, code, and other third-party materials have separate licenses?
It is particularly important to note that a GitHub repository using an open-source license does not mean all content on the corresponding official website can be freely republished.
4. Advertising and maintenance costs
Will there be an opportunity to gain enough organic search clicks in the future?
How frequently will the content need to be updated?
How much ongoing effort will translation and quality review require?
Among these, the most important business metric remains the net long-term advertising profit.
But without reliable data, I must admit that it is currently impossible to determine, rather than blindly estimating search traffic and revenue.
4. An important criterion added later: incremental value of internet content
During the research process, I gradually realized that beyond commercial value, I should also consider a project’s actual incremental value to the existing content on the internet.
This point is especially applicable to multilingual translation projects.
Suppose there are two candidate projects, both targeting 66 locales.
Project A already has a large number of mature multilingual translations, with only a few regions truly lacking high-quality content.
Project B still has many languages that have not yet received complete, usable derivative translations.
Assuming other conditions are basically the same, Project B can clearly add valuable knowledge resources for readers in more languages.
For example:
If one project can provide previously unavailable reliable content to 50 locales, while another project can only provide the same increment to 40 locales, then the former is more valuable in the dimension of multilingual content coverage increment.
But there are two important prerequisites here.
First, I must verify whether these languages actually lack usable content.
I cannot assume that an entire translation does not exist on the internet just because I didn’t find one during a search.
Second, I cannot directly treat the number of newly added languages as commercial revenue.
The potential user demand, search competition, and maintenance costs for 50 locales might be completely different from those for another 40 locales.
Therefore, the number of newly added languages is just one evaluation metric, not the final ranking.
What I really want to find is:
Using reasonable translation and maintenance costs, to provide as many readers as possible with knowledge content that was previously hard to obtain or was clearly of poor quality.
This is also why I later placed increasing importance on investigating official content coverage and community derivative translations.
5. An official language option does not mean translation is actually complete
There is another area prone to misjudgment during research.
Some official websites provide a drop-down menu with dozens of languages.
At first glance, it seems these languages are all officially supported.
But upon closer inspection, the reality might be different.
Some websites simply use Google Translate to let the browser temporarily display the page in other languages.
This is completely different from a publisher independently maintaining dozens of complete translations.
For example, while investigating a world history textbook from University of North Georgia Press, I found that its official website could switch to a large number of languages via the Google Translate widget.
However, these language options do not prove that the publisher has independently released complete textbooks in those target languages.
Particularly when the textbook text is provided as a PDF, the Google Translate feature on the web page does not mean the downloaded textbook in its entirety has also been translated.
Similarly, while some official websites list community translation links, I cannot directly assume these translations are maintained by the official source or that they cover all chapters.
Therefore, I gradually established a principle:
To judge multilingual coverage, I should not just look at the language menu, but must verify the specific textbook, specific chapters, and the actual readable target language text.
For existing community translations, I should also investigate their completeness, quality, and update status.
These translations might not prevent me from retranslating the corresponding languages later, but they will affect how much new value the project can ultimately add to the internet.
6. What candidate projects were initially investigated?
Once the research began, I did not directly treat Rust and Python as the only candidates.
Instead, I simultaneously investigated several different directions.
Rust: Clear advantages in engineering reuse
Rust was one of the earliest candidates I focused on.
It has a relatively complete system of learning resources, including The Rust Programming Language, Rust By Example, Cargo, Reference, Nomicon, and Rustlings.
From a learning path perspective, this content is very well-suited for building a multilingual technical learning website.
Moreover, the engineering experience I accumulated in go-dev could be fully reused.
But upon further investigation, I found that the Rust community already has a considerable amount of actual translated content.
For several modules in certain languages, a large number of non-empty translations or exercise files can already be found.
If I were to retranslate these materials, I would need to consider how much substantive increment I could offer compared to existing community translations.
Additionally, the Rust toolchain and official documentation will continue to be updated, requiring ongoing long-term maintenance.
Therefore, I did not immediately finalize Rust as the second project just because of its high engineering reusability.
Python: Official multilingual coverage has already created competition
Python also has sustained demand.
However, the official Python documentation already has actual translated content in multiple languages.
For modules where the official source already provides complete, usable translations, the value of independently rebuilding them might be limited.
Of course, this does not mean that all Python materials and all languages are fully covered.
It just means that based on current research evidence, I have not prioritized it for now.
Shopify: Clear developer value, but licensing scope requires careful distinction
Shopify is a commercial development platform direction I am quite familiar with.
During my research, I found that some official open-source repositories, like Liquid, use the MIT license, allowing for further investigation into legally reusable content.
But I cannot infer from this that the entire Shopify development documentation permits commercial translation and independent publishing.
Therefore, the reasonable approach is to define the content scope based on specific materials and licenses.
This project still holds research value, but I need to further confirm whether the content that can be legally provided is complete enough, and whether it can build search competitiveness for an independent website.
OWASP: Security materials have long-term value, but the responsibility to update is heavy
The OWASP Cheat Sheet Series is also a candidate worth considering.
It contains many reference materials related to development security, and the main content has an open licensing foundation.
However, the accuracy requirements for security knowledge are very high.
If an important security correction occurs upstream, the multiple language versions also need to be updated in a timely manner.
This introduces some uncertainty into its long-term maintenance costs.
After dedicated research, I decided to keep this direction on hold rather than start implementing it immediately.
AI, Ethereum, DeepSeek, and other directions
AI tutorials, Ethereum development documentation, DeepSeek technical materials, and others also entered the research scope.
Some of these courses already provide a large number of language versions.
Other materials require strictly distinguishing between model weight licenses, code licenses, and the copyright terms of official API documentation.
In addition, I also researched world geography, open statistical data, and interactive tool directions.
These directions do have a market, but existing websites already offer many mature products.
If I were to develop new tools, I would first have to find specific user needs that are not yet adequately met.
Ultimately, I did not reach the conclusion that “technical projects are definitely better than non-technical projects” or that “AI is definitely the best choice.”
7. Why did World History gradually become the top choice?
World History was initially just one of many candidates.
But as the investigation deepened, it gradually became a direction quite suitable for my current goals.
I primarily considered four factors.
First, basic historical knowledge has long-term learning value
Historical content certainly requires maintenance as well.
New archaeological discoveries, research findings, and historical interpretations may all require textbook revisions.
But compared to rapidly updating API and SDK documentation, the content structure of a basic world history textbook is usually relatively stable.
From the perspective of a long-term content asset, this is an attractive feature.
However, I did not interpret this as “history textbooks don’t need maintenance.”
Historical fact-checking, cross-cultural expressions, proper names, and citation sources still require careful handling.
Second, specific, legally open textbooks can be found
I do not plan to write an original encyclopedia covering global history entirely from scratch.
That would likely require substantial specialized research and proofreading resources.
In comparison, starting with explicitly licensed open textbooks is more suitable for the current stage.
After investigation, I selected three textbooks as the initial content sources.
HIS-A: World History: Cultures, States, and Societies to 1500
Published by University of North Georgia Press, it has 12 chapters and mainly covers world history before 1500.
The main text uses the CC BY-SA 4.0 license.
Official source:
HIS-B: World History Since 1500: An Open and Free Textbook
Provided by East Tennessee State University, it has 15 chapters and mainly covers world history after 1500.
The original publication page labels the main text as CC BY 4.0.
Official source:
HIS-C: History of International Relations: A Non-European Perspective
Written by Erik Ringmar and published by Open Book Publishers.
The book discusses the history of international relations from a non-European perspective and can serve as supplementary learning material alongside the two general world history books.
The main text uses CC BY 4.0.
Official source:
https://www.openbookpublishers.com/books/10.11647/obp.0074
These three books provide a relatively clear initial research scope for the project.
However, the specific applicability of the open licenses still needs to be confirmed.
For example, third-party images, maps, and photos within the textbooks may not necessarily be freely copied or commercially redistributed along with the main text.
Third, there may be clear incremental opportunities for multilingual derivative content
This is another major reason World History appeals to me.
I specifically investigated derivative translations of these three textbooks in different target languages.
The initial sample selected eight locales:
Simplified Chinese, Japanese, German, French, Spanish, Indonesian, Vietnamese, and Hindi.
Combined, the three textbooks formed 24 investigation samples.
Among them, I found that HIS-A already has a Spanish LibreTexts derivative translation.
This translation features a table of contents corresponding to the original book’s 12 chapters, and the actual Spanish text for some chapters has been verified.
However, for the other 23 combinations, within the limited scope of investigation at the time, I did not find sufficient evidence to confirm the existence of complete derivative translations.
I must emphasize here:
The fact that complete translations were not found for 23 samples does not prove that these 23 language-textbook combinations are completely blank.
It only indicates that the multilingual coverage of world history textbooks still has room for further investigation.
There is currently no accurate number for how many effective language versions can ultimately be added to the internet.
Nevertheless, compared to some technical textbooks that already have large-scale derivative community translations, this direction has shown potential incremental value worth further verification.
Fourth, personal interest and existing engineering experience can be combined
Beyond commercial factors, I am also quite interested in world history, geography, and humanities knowledge itself.
This does not prove the website will be profitable in the future.
But for a content project that might need to be managed for years, whether I am willing to read and maintain these materials long-term is a practical factor worth considering.
At the same time, the multilingual terminology management, translation review, and website deployment experience from go-dev will still hold reuse value in the future.
Of course, World History also has its own specific issues.
Historical figures, civilization names, place names, time expressions, citations, and maps all require processing rules tailored to this field.
I do not plan to copy go-dev’s engineering system over directly without modifications.
8. Why ultimately not Rust, Shopify, or other projects?
Through comparison, I became increasingly clear about one fact:
There is currently not enough data to prove that World History will definitely gain more organic search traffic or higher net advertising revenue than the other candidates.
Therefore, this selection was not made based on a precise ranking of commercial returns.
I was actually making trade-offs between several different advantages.
Rust’s advantage is its mature learning ecosystem and high degree of engineering reuse, but it already faces competition from community derivative translations and requires continuous updates to keep up with technical versions.
Shopify’s advantage is that developer query demand is quite clear and it fits my technical experience, but the scope of content that can be legally hosted independently needs further planning.
OWASP’s security reference materials have long-term value, but the requirements for professional accuracy and update timeliness are high.
World History, on the other hand, has three specific open textbook sources, basic content with a longer lifespan, and cross-lingual content incremental opportunities worth further research.
Factoring in personal interest, future maintenance costs, and the multilingual engineering experience I have already accumulated, I ultimately leaned toward choosing World History.
However, this conclusion should be accurately understood as:
Based on the evidence and personal resources currently available, I chose World History as the second project direction, rather than having proven that it has the highest commercial return among all candidates.
The other candidate projects were not rejected as a result.
9. Officially finalizing the second multilingual project
On November 6, 2026, I officially finalized the second project as:
WORLD_HISTORY
The relevant decision has been recorded on GitHub:
Official selection of the second multilingual project: World History
This project plans to carry over existing experience in distinguishing multilingual and regional locales, with a target scope of 66 locales.
However, 66 locales is the target scope; it does not mean that all translations and deployments will definitely be completed on the same day in the future.
Additionally, whether all three textbooks need to be self-hosted for every locale will be decided individually based on official valid content coverage and the actual reading experience.
After the project was selected, I continued with preliminary investigations into official document sources, PDFs and XML, English regional variants, and the web reading experience.
This work further clarified the future content scope of the World History project.
But as of now, the project still has several unresolved business questions:
How much organic search traffic can it actually gain?
How large is the actual demand across different languages and regions?
How strong is the search competition from existing history education websites?
Can long-term advertising revenue cover translation, review, and maintenance costs?
None of these questions can be given a reliable quantitative answer at present.
Therefore, completing the selection does not mean the business model has been proven successful.
10. What is the biggest takeaway from this research?
Looking back at the entire process, I feel what is truly important is not just that I ultimately chose World History.
More importantly, my criteria for judging multilingual content projects have changed.
Previously, I might have first considered whether a project had mature English source text and whether I could reuse existing translation engineering.
Now, I believe I should also seriously answer:
Does anyone actually need this project?
How much identical or similar content has the existing internet already provided?
How much effective knowledge coverage can our multilingual version actually add?
Can we provide additional value through quality, completeness, reading experience, and long-term maintenance?
Is it ultimately possible to gain enough organic search traffic to form sustainable advertising revenue?
These questions are not easy to answer.
But at the very least, they can help me avoid immediately diving into large-scale development just because a certain open-source project is popular, a certain field is trending, or I already possess the relevant technical skills.
Just because something can be translated does not mean it is worth translating; just because a website can be built does not mean it is worth running long-term.
This is the main reason I set up an independent multilingual project research repository and ultimately chose World History.
11. After the second project was selected
Currently, World History has become the officially selected direction for the second multilingual project.
But it will not immediately enter the development phase.
My main project remains go-dev, especially the yet-to-be-completed v2.
The official development of World History will have to wait at least until go-dev v2 is completed, and possibly until v3.
The specific timeline has not been determined yet.
At this stage, work related to World History still falls under research and pre-launch planning.
Other directions like Rust, Python, Shopify, OWASP, and Ethereum are also retained in the research project.
If new evidence emerges in the future, their value can still be reassessed.
For me, the most meaningful outcome of this research is that I have finally found a clear direction for the second long-term project, and I have accumulated a reusable research methodology for selecting the third and fourth projects in the future.
Currently, World History has been officially selected as the second multilingual project, but I have no immediate plans to start development.
The reason is simple: go-dev v2 remains the most important project right now. Although I have accumulated a lot of multilingual engineering experience, fully building and maintaining a new project still requires a significant amount of time.
Therefore, I decided to keep the World History research results in the existing repository for now, and occasionally complete necessary pre-launch investigations without affecting go-dev’s development.
Once go-dev v2 is completed, I will decide whether to start the World History project based on the actual situation.
For me, researching whether a project is worth doing and deciding when to start doing it are two different things.
Now that the direction has been selected, there is no need to rush into starting two projects simultaneously. Focusing on doing the most important thing at hand right now better aligns with my long-term goals.