2021 में एक German e-commerce client Seahawk के पास आया जिसका brief मूलतः यह कहता था: "हमें अपने WooCommerce store को अंग्रेजी, फ्रेंच और पोलिश में चाहिए। मार्च तक।" यह नवंबर था। और human translation के लिए बजट, आइए कहें, गलत दिशा में महत्वाकांक्षी था। हमने इससे पहले कुछ projects पर Google Translate की API का उपयोग किया था और output, ईमानदारी से कहूँ तो, button labels से परे कुछ भी करने के लिए शर्मनाक था। तो मैं ढूंढने निकल पड़ा।
तब मैंने DeepL के साथ ठीक से बैठा। मैंने इसे कुछ developer threads में mentioned होते देखा था लेकिन इसे गंभीरता से नहीं लिया था। वह पाँच साल की अवधि में मेरी सबसे बड़ी गलती थी। एक बार जब मैंने एक जैसे product descriptions को दोनों APIs के माध्यम से चलाया और side-by-side output client को दिखाया, तो कोई contest नहीं रहा। हमने German store को तीन भाषाओं में Christmas से पहले ship किया, client ने छह महीने बाद बिना किसी परेशानी के Dutch को जोड़ा, और यह project अभी भी ऐसा है जिसकी ओर मैं इशारा करता हूँ जब लोग पूछते हैं कि अच्छा API integration कैसा दिखता है।DeepL. I'd seen it mentioned in a few developer threads but hadn't taken it seriously. Biggest mistake I made in that half-decade. Once I ran the same product descriptions through both APIs and showed the client side-by-side output, there was no contest. We shipped the German store in three languages before Christmas, the client added Dutch six months later without breaking a sweat, and that project is still one I point to when people ask what good API integration looks like.
यह post एक website में DeepL को wire करने की व्यावहारिक वास्तविकता के बारे में है। Marketing copy के बारे में नहीं। वास्तविक implementation decisions, cost model, gotchas, और मैं अपने पुराने self को शुरुआत से पहले क्या बताता।
DeepL वास्तव में विकल्प को क्यों हराता है
मैं सीधे कहूँ: European languages के लिए, DeepL एक अलग tier में है। यह model Europarl corpus और अन्य high-quality parallel texts पर भारी रूप से trained था, और आप इसे German, French, Spanish, Italian, Dutch, Polish, और Portuguese के लिए output में तुरंत महसूस करते हैं। sentence structure word-swapped होने के बजाय विचारशील लगता है।
Google Translate का API (v2 और v3) सस्ता है और ज्यादा भाषाओं को कवर करता है। mid-2024 तक 133 vs DeepL के 29 समर्थित भाषाएं। अगर आपको स्वाहिली या बंगाली चाहिए, तो DeepL आपका जवाब नहीं है। बस इतना ही। लेकिन अगर आपका क्लाइंट यूरोप में या जापान में विस्तार कर रहा है (DeepL जापानी को शानदार तरीके से संभालता है), तो आप आदत के बाहर Google को डिफ़ॉल्ट करके उन्हें नुकसान पहुंचा रहे होंगे।
दूसरी चीज जिस पर कोई काफी बात नहीं करता: DeepL का formality parameter। आप formality=more या formality=less सेट कर सकते हैं और API आउटपुट के register को तदनुसार समायोजित करेगा। यह जर्मन के लिए भारी मायने रखता है, जहां du/Sie एक मामूली शैलीगत पसंद नहीं है। एक DTC फैशन ब्रांड चाहता है एक अलग register एक B2B SaaS कंपनी की तुलना में। मेरे क्लाइंट्स ने इस भेद को अपनी translated copy में बिना मुझे इशारा किए ही देख लिया है।formality parameter. You can set formality=more or formality=less and the API will adjust the register of the output accordingly. That matters enormously for German, where du/Sie isn't a minor stylistic choice. A DTC fashion brand wants a different register than a B2B SaaS company. I've had clients notice this distinction in their translated copy without me even pointing it out.
प्रतिबद्ध होने से पहले Cost Model को समझें
DeepL अनुवादित प्रत्येक वर्ण के लिए charge करता है। मुक्त API योजना (DeepL API Free) आपको प्रति माह 500,000 वर्ण देती है। यह बहुत कुछ लगता है जब तक आप WooCommerce कैटलॉग को 800 उत्पादों और लंबे विवरणों के साथ अनुवाद नहीं कर रहे हैं।
Pro योजना लगभग $6.99/माह से शुरू होती है 500,000 वर्णों के लिए और वहां से बढ़ता है। अधिकांश एजेंसी परियोजनाओं के लिए जो मैं चलाता हूं, लागत कैटलॉग आकार और अपडेट आवृत्ति के आधार पर $15 और $60 प्रति माह के बीच कहीं बैठती है। पेशेवर मानव अनुवाद दरों की तुलना करें (आमतौर पर UK बाजार में £0.10 से £0.18 प्रति शब्द) और API पहले 200 शब्दों के भीतर अपने लिए भुगतान करता है।
एक चीज जिसने मुझे जल्दी जला दिया: HTML handling। DeepL raw HTML प्राप्त कर सकता है और tags को अनुवाद करने के बजाय संरक्षित करने का प्रयास करेगा। आप अपने अनुरोध में tag_handling=html पास करते हैं। लेकिन अगर आपका HTML malformed है या आपके उत्पाद विवरणों में inline scripts हैं (कुछ WooCommerce plugins को देख रहे हैं), तो आउटपुट खराब हो सकता है। मैंने content को API से पहले sanitise करना सीखा, बाद में नहीं।HTML handling. DeepL can receive raw HTML and will attempt to preserve tags rather than translate them. You pass tag_handling=html in your request. But if your HTML is malformed or your product descriptions contain inline scripts (looking at you, some WooCommerce plugins), the output can get mangled. I learned to sanitise content before it hits the API, not after.
दो Integration Paths: WordPress और Custom Builds
WordPress Sites
WordPress के लिए, सबसे सीधा रास्ता जो मैंने उपयोग किया है वह WPML integration है। WPML के पास उनके Translation Management module में एक native DeepL connector बना हुआ है। आप WPML की settings के अंदर अपनी DeepL API key को authorize करते हैं, select करते हैं कि किन content types को auto-translate करना है, और यह queue को संभालता है। यह जादू नहीं है, एक मानव review step अभी भी workflow में बनाने के लायक है, लेकिन एक 300-page site के लिए यह हफ्तों की बचत करता है।WPML integration. WPML has a native DeepL connector built into their Translation Management module. You authorise your DeepL API key inside WPML's settings, select which content types to auto-translate, and it handles the queue. It's not magic, a human review step is still worth building into the workflow, but for a 300-page site it saves weeks.
विकल्प है Polylang Pro with the DeepL add-on। थोड़ा सस्ता licensing, translation management side पर थोड़ा कम polished। मैंने पिछले साल एक French restaurant group site पर Polylang का उपयोग किया। उस scale के लिए ठीक है। लेकिन custom post types और ACF fields के साथ कुछ भी के लिए, WPML मेरे अनुभव में edge cases को बेहतर तरीके से संभालता है।
अगर आप headless WordPress बना रहे हैं (Gatsby या Next.js फ्रंट-एंड GraphQL के माध्यम से WP से डेटा ले रहे हैं), तो DeepL API को सीधे अपनी build pipeline या serverless function से कॉल करें। इस architecture में इसे किसी प्लगइन के माध्यम से शामिल करने की कोशिश न करें। यह cleanly स्केल नहीं होगा।
Custom / Non-WordPress Builds
यहीं चीजें दिलचस्प होती हैं। DeepL Python, Node.js, PHP, Ruby, .NET, और Java के लिए official client libraries प्रकाशित करता है। Node.js लाइब्रेरी बेहतरीन है। मैंने इसे एक Next.js project पर use किया जहां हमने repeated strings पर redundant API calls से बचने के लिए Redis में translations को cache किया।official client libraries for Python, Node.js, PHP, Ruby.NET, and Java. The Node.js library is solid. I've used it on a Next.js project where we cached translations in Redis to avoid redundant API calls on repeated strings.
एक basic Node.js call ऐसा दिखता है:
`` const deepl = require('deepl-node'); const translator = new deepl.Translator('YOUR_AUTH_KEY'); const result = await translator.translateText('Hello, world', null, 'fr'); console.log(result.text); // 'Bonjour le monde' `` const deepl = require('deepl-node'); const translator = new deepl.Translator('YOUR_AUTH_KEY'); const result = await translator.translateText('Hello, world', null, 'fr'); console.log(result.text); // 'Bonjour le monde' ``
सरल। असली architecture का सवाल caching है। हर page load पर API को hit न करें। अपने database या cache layer में translations store करें (Redis अच्छी तरह काम करता है, छोटी sites के लिए simple JSON file भी काम करती है)। जब source content बदले तो cache को invalidate करें। बस इतना ही। complexity का अधिकांश हिस्सा cache invalidation logic में होता है, API call में नहीं।
Placeholders और Dynamic Content को Handle करना
यह Seahawk में एक SaaS project पर मेरे एक developer को confuse कर गया जहां UI strings में {{user_name}} और {{count}} जैसे variables थे। उन्हें raw DeepL को दें और यह कभी-कभी variable names को translate कर देगा। जब {{nombre_de_usuario}} आपके Spanish UI में आए तो यह ideal नहीं होता।{{user_name}} and {{count}}. Feed those raw to DeepL and it'll sometimes translate the variable names. Not ideal when {{nombre_de_usuario}} ends up in your Spanish UI.
समाधान: DeepL की XML handling का use करें और अपने placeholders को ignore tags में wrap करके भेजें।XML handling and wrap your placeholders in ignore tags before sending.
`` <deepl:ignore>{{user_name}}</deepl:ignore> has {{count}} new messages. `` <deepl:ignore>{{user_name}}</deepl:ignore> has {{count}} new messages. ``
अपने request parameters में tag_handling=xml और ignore_tags=deepl:ignore सेट करें। API इन tags के अंदर की किसी भी चीज़ को preserve करता है। यह DeepL के API reference में documented है लेकिन पहली बार पढ़ने में मिस हो जाता है। उस SaaS project पर मुझे इसकी वजह से तीन घंटे debugging में लगे। उम्मीद है कि आपको कोई न लगे।tag_handling=xml and ignore_tags=deepl:ignore in your request parameters. The API preserves anything inside those tags. This is documented in DeepL's API reference but it's easy to miss on a first read. Cost me about three hours of debugging on that SaaS project. Hopefully it costs you none.
एक sensible Review Workflow बनाना
Machine translation publishing button नहीं है। मैं कभी DeepL output को अपने सीधे live site पर भेजने की recommend नहीं करूंगा, कम से कम एक native speaker pass के बिना नहीं, खासकर कुछ भी customer-facing के लिए। लेकिन workflow को दर्दनाक होना ज़रूरी नहीं है।
यहाँ वह है जो मैंने ज्यादातर client projects के लिए सेट किया है:
- DeepL API के through initial translation चलाएं।
- Output को एक staging translation table में push करें (WPML में यह automatic है; custom builds में मैं एक translations DB table में लिखता हूँ जिसका status column default से pending होता है)।
translationsDB table with astatuscolumn defaulting topending). - client के in-market reviewer को एक link भेजें (अक्सर client की अपनी local team या ProZ से एक freelancer)।ProZ).
- Reviewer CMS में या एक simple review interface में directly edit करता है जो मैं बनाता हूँ।
- Status को approved पर flip करें, content live हो जाए।
approved, content goes live. - String को lock करें ताकि अगली API sync पर यह overwrite न हो।
वह आखिरी कदम महत्वपूर्ण है। मैंने ऐसे सेटअप देखे हैं जहाँ स्रोत भाषा पर कोई कंटेंट अपडेट पूरे अनुवाद को ट्रिगर कर देता है और सभी मानव सुधार मिटा देता है। कुछ और बनाने से पहले लॉक मेकेनिज्म बना लो।
बहुभाषी साइटों के लिए SEO विचार
अकेले अनुवादित कंटेंट रैंक नहीं करेगा। आपको हर भाषा वेरिएंट के लिए अपने HTML <head> में hreflang टैग की जरूरत है, और वे सही होने चाहिए। गलत hreflang सेटअप आपके अंतर्राष्ट्रीय पेजों को सर्च रिजल्ट में दबा सकता है। मैंने एक क्लाइंट को यह होते हुए देखा है जिसके पास एक खूबसूरत अनुवादित फ्रेंच साइट चार महीने तक अस्पष्टता में पड़ा रहा क्योंकि किसी ने भाषा कोड गलत कर दिए थे ( fr-FR बनाम fr)।hreflang tags in your HTML <head> for every language variant, and they need to be correct. A mismatched hreflang setup can actually suppress your international pages in search results. I've seen this happen to a client who had a beautiful translated French site sitting in obscurity for four months because someone got the language codes wrong ( fr-FR vs fr).
hreflang से परे: अनुवादित URLs। आदर्श रूप से आप स्लग्स का भी अनुवाद चाहते हैं, /fr/how-to-cook-pasta नहीं बल्कि /fr/comment-cuire-les-pates। DeepL स्लग्स का अनुवाद कर सकता है लेकिन आप उन्हें अनुवाद के बाद एक स्लग फॉर्मेटर से गुजारना चाहेंगे (लोअरकेस, हाइफन, विशेष वर्ण हटाएँ)। WPML यह स्वचालित रूप से करता है। कस्टम बिल्ड्स में, इसे मैनुअली संभालें।/fr/how-to-cook-pasta but /fr/comment-cuire-les-pates. DeepL can translate slugs but you'll want to run them through a slug formatter afterwards (lowercase, hyphens, remove special characters). WPML does this automatically. In custom builds, handle it manually.
और मेटाडेटा। पेज टाइटल्स, मेटा डिस्क्रिप्शन्स, इमेजेस पर alt टेक्स्ट। सब कुछ को अनुवाद ट्रीटमेंट की जरूरत है। मैं मेटाडेटा को पाइपलाइन में अलग से DeepL के माध्यम से चलाता हूँ, बॉडी कंटेंट बैच के भाग के रूप में नहीं। इस तरह करैक्टर लिमिट को कंट्रोल करना आसान है।
DeepL की कमियाँ
सच्चा जवाब: ब्रांड-विशिष्ट शब्दावली। DeepL को नहीं पता कि आपका क्लाइंट अपनी प्रोडक्ट फीचर्स को क्या कहता है। अगर कोई fintech क्लाइंट "Smart Vault" को प्रोडक्ट नाम के रूप में उपयोग करता है, DeepL इसका अनुवाद कर देगा। हर बार।
समाधान DeepL की glossary फीचर है। आप API के माध्यम से टर्म पेयर्स को परिभाषित करते हैं (स्रोत टर्म, टार्गट टर्म, भाषा जोड़ी) और अपने अनुवाद अनुरोधों में glossary ID को संलग्न करते हैं। वह Smart Vault हर भाषा में "Smart Vault" बन जाता है क्योंकि आपने इसे बताया है। आप glossaries को प्रोग्रामेटिकली या DeepL के डैशबोर्ड के माध्यम से प्रबंधित कर सकते हैं। मैं अब हर प्रोजेक्ट किकऑफ के भाग के रूप में glossaries सेट अप करता हूँ। इसमें 20 मिनट लगते हैं और त्रुटियों की एक श्रेणी को रोकता है जो अन्यथा रिव्यू में पकड़ने के लिए घंटों खर्च करते।glossary feature. You define term pairs via the API (source term, target term, language pair) and attach the glossary ID to your translation requests. That Smart Vault becomes "Smart Vault" in every language because you've told it to. You can manage glossaries programmatically or via DeepL's dashboard. I set up glossaries as part of every project kickoff now. It takes 20 minutes and prevents a category of errors that would otherwise cost hours to catch in review.
दूसरी सच्ची सीमा: DeepL की भाषा कवरेज। 29 भाषाएँ वाकई प्रतिबंधात्मक हैं अगर आपके क्लाइंट के यूरोप और पूर्वी एशिया से परे की महत्वाकांक्षाएँ हों। अगर आपको Arabic की जरूरत है, तो आप एक हाइब्रिड अप्रोच की ओर देख रहे हैं: यूरोपीय भाषाओं के लिए DeepL, बाकी सब कुछ के लिए Google Cloud Translation या Microsoft Azure Translator, एक एकल आंतरिक API परत के पीछे unified जो भाषा जोड़ी के आधार पर रूट करता है। एक बार बनाना कष्टप्रद है। मेंटेन करना बहुत सुविधाजनक है।
FAQ
क्या DeepL API का उपयोग मुफ़्त है?
500,000 वर्णों प्रति महीने के साथ एक मुफ़्त स्तर है, जो परीक्षण और छोटी परियोजनाओं के लिए उदार है। मुफ़्त योजना के लिए फ़ाइल पर क्रेडिट कार्ड की आवश्यकता होती है लेकिन जब तक आप सीमा से अधिक न हों या अपग्रेड न करें, तब तक आपसे शुल्क नहीं लिया जाएगा। किसी भी वास्तविक ट्रैफ़िक या सामग्री वॉल्यूम वाली प्रोडक्शन साइटों के लिए, आप लगभग निश्चित रूप से एक भुगतान योजना चाहेंगे। Pro स्तर लगभग $6.99/माह से शुरू होते हैं और वर्ण उपयोग के आधार पर स्केल करते हैं।
क्या मैं WordPress के साथ प्लगइन के बिना DeepL का उपयोग कर सकता हूँ?
तकनीकी रूप से हाँ। आप wp_remote_post() का उपयोग करके WordPress कस्टम प्लगइन या functions.php से सीधे REST API को कॉल कर सकते हैं। लेकिन जब तक आपको पहिया दोबारा आविष्कार करने का शौक न हो, WPML या Polylang इंटीग्रेशन आपके लिए अनुवाद कतार, स्ट्रिंग सिंकिंग और सामग्री लॉकिंग को संभालते हैं। मैं WordPress में केवल कस्टम-API-डायरेक्ट का उपयोग करूँगा यदि आपके पास कोई बहुत ही विशिष्ट आर्किटेक्चर कारण हो।wp_remote_post(). But unless you enjoy reinventing wheels, the WPML or Polylang integrations handle the translation queue, string syncing, and content locking for you. I'd only go custom-API-direct in WordPress if you have a very specific architecture reason.
मानव अनुवाद की तुलना में DeepL कितना सटीक है?
यूरोपीय भाषाओं के लिए, DeepL नियमित रूप से BLEU स्कोर बेंचमार्क पर मानव अनुवाद के कुछ प्रतिशत अंकों के भीतर स्कोर करता है। व्यावहारिक रूप से: उत्पाद विवरण और UI स्ट्रिंग्स के लिए काफ़ी अच्छा, कानूनी दस्तावेज़, रचनात्मक प्रतिलिपि या कुछ भी जहाँ टोन और सांस्कृतिक सूक्ष्मता पूरा मुद्दा हो, के लिए काफ़ी अच्छा नहीं। क्लाइंट परियोजनाओं में हमेशा एक मानव समीक्षा चरण बनाएँ।
क्या DeepL अनुवाद SEO को प्रभावित करता है?
मशीन-अनुवादित सामग्री जिसकी समीक्षा नहीं की गई है, विशेष रूप से यदि यह अप्राकृतिक रूप से पढ़ी जाती है, तो सर्च इंजन द्वारा कम-गुणवत्ता के रूप में फ़्लैग की जा सकती है। Google ने कहा है कि वे स्वचालित-अनुवादित सामग्री को दंडित नहीं करते, लेकिन पतली या विकृत सामग्री कम प्रदर्शन करेगी। मेरा नियम: इंडेक्सिंग से पहले समीक्षा करें, बाद में नहीं।
जब स्रोत सामग्री बदलती है तो अनुवाद अपडेट को संभालने का सर्वोत्तम तरीका क्या है?
अपने डेटाबेस में प्रत्येक अनुवाद के साथ एक सामग्री हैश (स्रोत स्ट्रिंग का MD5 ठीक है) ट्रैक करें। जब स्रोत सामग्री अपडेट की जाती है, तो हैश बदलता है, जो अनुवाद को पुराना के रूप में फ़्लैग करता है। आपकी पाइपलाइन तब पूरे पृष्ठ के बजाय केवल बदली गई स्ट्रिंग्स को फिर से अनुवाद करती है। यह API लागतों को कम रखता है और उन स्ट्रिंग्स पर अनावश्यक चलन को रोकता है जो पहले से ही मानव-समीक्षा की गई थीं।
---
DeepL API उन उपकरणों में से एक है जिसने मेरे बहुभाषीय प्रोजेक्ट्स के दायरे को वास्तव में बदल दिया। इसलिए नहीं कि यह मानवीय निर्णय की ज़रूरत को खत्म करता है, बल्कि इसलिए कि यह काम को नीरस पहली-ड्राफ्ट अनुवाद से हटाकर सार्थक संपादकीय समीक्षा में बदल देता है। यह सभी का समय बेहतर तरीके से लगाना है, आपके क्लाइंट के बजट सहित। इसे सावधानी से तार करें, आक्रामक रूप से कैश करें, दिन के पहले दिन से ही समीक्षा चरण बनाएं, और यह आपकी अच्छी सेवा करेगा।