A Paradigm Shift in Intelligent Translation Architecture: Direct-Preferred, Hub-Enabled

For a long time, the industry generally believed that English was the natural hub for multilingual translation, and all non-English pairs could be efficiently processed via English as an intermediary. However, this assumption has been repeatedly challenged in practice, with data showing a significant decline in translation quality when models trained with English as the central language process non-English pairs. [Verified] Another misconception was that building a direct translation system implied N(N-1) independent bilingual systems, with costs increasing quadratically with the number of languages. However, advanced many-to-many single-model technologies like Meta NLLB have reduced the marginal cost of adding new languages to a linear increase, completely overturning this perception. [Verified]

Furthermore, the view that 'zero-shot translation' could replace hubs has not held up. Although multilingual models claim to cover arbitrary language pairs, actual evaluations show that the quality of zero-shot translation is generally inferior to hub-mediated translation, and in the absence of sufficient training data, it is prone to outputting incorrect target languages. [Verified] This not only impacts user experience but also exposes its limitations in complex contexts. Finally, the old notion that 'language coverage equals competitiveness' is also being challenged. With the increasing ubiquity of multilingual support in models, the core value of translation services has shifted towards routing accuracy, terminological consistency, and stringent quality assurance mechanisms. [Inferred]

The new paradigm no longer views the hub as the endpoint of the translation process but elevates it to a critical layer for 'routing and quality assurance.' Its core strategy is 'direct-preferred, hub-as-fallback': For resource-rich language pairs with high model confidence, such as Chinese↔English, English↔Arabic, and Chinese↔Arabic, direct translation is prioritized to ensure the highest quality; only for low-resource or long-tail languages like Turkish (tr) is an English hub used as a fallback solution. This layered strategy aims to maximize the utilization of existing high-quality models while providing flexibility for integrating new languages.

Another critical role of the hub in this new architecture is that of a 'data factory.' By generating pseudo-parallel corpora via hub translation, and then using this data to fine-tune direct translation models for target language pairs, their performance can be significantly improved. Research by Imamura et al. (MTSummit 2023) has confirmed that fine-tuning models with pseudo-translations generated by machine translation can effectively improve the quality of hub translation. [Verified] This marks an innovative path of 'hub-first, then direct,' meaning using the hub to accelerate the maturation of direct translation models.

In terms of scalability, many-to-many single models (e.g., Meta NLLB/M2M-100) are key to achieving linear growth in the number of languages. These models, trained with a non-English-centric approach, have improved direct translation quality for non-English directions by over 10 BLEU points, and versions like NLLB-200-distilled-600M can even be deployed locally, covering 200 languages, significantly reducing the engineering cost of integrating new languages. [Verified] Regarding cost considerations, although the token cost of a single LLM direct translation might seem higher than traditional NMT APIs, a two-hop hub translation could incur double the token consumption. Therefore, actual cost calculation requires precise evaluation. Third-party data (e.g., Google Cloud around $20/million characters, DeepL around $25/million characters, Google LLM adaptive translation around $50/million characters) indicates that direct translation is not necessarily more expensive, but depends on the specific model and billing method. [Verified (Third-party summary)]

Numerous pieces of evidence support the superiority of direct translation in specific scenarios. For instance, Meta NLLB's non-English-centric training strategy has improved translation quality for non-English language pairs by over 10 BLEU points. [Verified] Third-party evaluations also generally indicate that LLMs, when handling Asian languages like Chinese, Japanese, and Korean, have surpassed the performance of traditional Statistical Machine Translation (NMT) models. However, Arabic, due to its Right-to-Left (RTL) script, complex gender system, and formality requirements, is widely considered one of the most challenging languages to process, posing unique challenges for direct translation while simultaneously highlighting the value of high-quality models. [Verified (Third-party evaluation)]

Nevertheless, hub translation remains indispensable in certain domains. Multilingual NMT survey reports explicitly state that the quality of zero-shot translation is generally inferior to hub mediation, and its effectiveness heavily relies on the scale of training data; otherwise, it is highly prone to outputting incorrect languages. [Verified] Furthermore, research by Cheng et al. (IJCAI 2017) reveals that the hub's 'joint training' mechanism can further improve translation quality by sharing language representations and knowledge, particularly for resource-scarce language pairs, where the hub can provide an acceptable performance baseline. [Verified]

However, hub translation also has significant counterexamples and boundaries. For instance, reciprocal translation between Arabic and Turkish, a low-resource and morphologically rich language pair, even through a hub, requires complex back-translation and linguistic feature engineering such as 'morphology-driven vocabulary compression' to establish a baseline. This indicates that hubs are not a panacea and cannot replace a deep understanding of linguistic characteristics. [Verified] Concurrently, the inherent error propagation issue of hubs, where errors generated during the intermediary step are difficult to fix in the second hop, can lead to systemic quality degradation. [Inferred] Google's feat of adding 110 languages in 2024 further confirms the commoditization trend of language coverage itself, urging the industry to shift its focus towards deeper value in translation services. [Verified]

This paradigm shift in translation architecture has profound implications for business models. Enterprises' core competence is no longer merely 'how many languages are supported,' but has shifted to refined management capabilities such as 'routing accuracy, terminological consistency, and closed-loop quality assurance.' This transformation creates new arbitrage opportunities: price differences (e.g., Azure around $10/million characters compared to DeepL around $25/million characters) and quality variations among different translation providers for the same language pair offer market opportunities for 'translation routing middleware' as a lightweight asset product, enabling enterprises to dynamically select the optimal service provider based on real-time evaluations. [Inferred]

At the organizational level, traditional language-grouped translation and review teams will gradually decline. In their place, the 'language operations' function will rise, whose responsibilities include maintaining high-quality frozen evaluation sets, establishing and managing glossaries, and devising flexible routing strategies. Taking OPC research as an example, its 41 Arabic business frozen test items represent the Minimum Viable Asset for building this function, ensuring quantifiable and traceable translation quality. [Inferred] For individuals, the focus of value shifts from 'being able to translate' to 'being able to evaluate.' Experts with bilingual domain knowledge will be more competitive in MQM (Machine Translation Quality Matrix) quality assurance, terminology management, and prompt engineering, while roles solely relying on sentence-by-sentence translation skills will face obsolescence. [Inferred]

A true 'architectural revolution' is not merely simple optimization; it requires simultaneously meeting three stringent criteria. First, the quality dimension: direct translation's COMET score for non-English pairs must improve by at least 3 points compared to the hub, and not be inferior to the hub by more than 2 points. Second, the cost dimension: the unit character cost for a new language should be less than or equal to 1.2 times that of the hub solution, while also delivering higher quality. Finally, the scalability dimension: the human engineering effort required to add a new language should be controlled within 1 person-day, and should not cause the COMET score of existing language pairs to decrease by more than 1 point. Only when these conditions are simultaneously met can we declare a breakthrough in translation architecture.

For the practice of research-oriented One-Person Companies (OPCs), we propose building an intelligent routing layer with 'direct-preferred + hub-as-fallback,' rather than adhering to a single English hub. This routing layer will make intelligent decisions based on language pair characteristics, specific domains, and cost-effectiveness, rather than a global 'one-size-fits-all' strategy. To effectively control token cost fluctuations, OPCs should fully utilize efficient models like Meta NLLB-200-distilled-600M as local hubs or fallback solutions, prioritizing higher-cost LLM resources for high-value direct translation scenarios.

Taking the integration of Turkish (tr) as an example, this process should be divided into three rigorous steps. First, using an English hub solution, baseline tests should be run on the existing 41 frozen test items and the FLORES dataset, quantifying COMET scores to establish an initial performance reference. Second, pseudo-parallel data should be generated using hub translation, and combined with efficient fine-tuning techniques like LoRA, to fine-tune the direct translation model for Turkish. Finally, only when this direct model passes the aforementioned quality, cost, and scalability criteria of the 'architectural revolution' can it officially 'graduate' to a direct translation solution.

To ensure continuous optimization and maintainability of the translation system, OPCs need to establish a comprehensive language pair scorecard system. This system should include automated evaluation metrics such as COMET, BLEU, and chrF, supplemented by sampled manual MQM (Machine Translation Quality Matrix) quality checks, to comprehensively measure translation quality. This will transform routing strategies from empirical judgment into regression-testable software assets. Furthermore, building Translation Memory (TM) and caching mechanisms is crucial to effectively prevent re-payment for duplicate content, thereby further improving translation efficiency and cost-effectiveness.