DOCX भाषांतर बोल्डफेस का गमावते? प्रथम रन ठेवा, आणि नंतर संपूर्ण विभाग बदलण्याबद्दल बोला.

DOCX भाषांतरानंतर बोल्डनेस, तिर्यक आणि फॉन्ट आकार गमावला आहे. सामान्य कारण असे आहे की परिच्छेद सामग्री थेट संपूर्ण मजकूरासह बदलली जाते, जे मूळ रन-लेव्हल फॉरमॅट धुवून टाकते. बऱ्याच संघांना भाषांतर मिळाल्यानंतर, एक सामान्य प्रतिक्रिया अशी आहे की वर्डमधील जोराचे स्वरूप गहाळ आहे. हा लेख DOCX प्रक्रिया करण्यासाठी python-docx वापरणाऱ्या विकासकांसाठी तसेच संपादकांसाठी योग्य आहे ज्यांना द्विभाषिक दस्तऐवज वितरित करण्याची आवश्यकता आहे.

एका परिच्छेदामध्ये Word मध्ये फक्त एक वाक्य आहे असे दिसते, परंतु DOCX मध्ये ते एकाधिक रन बनलेले असू शकते: सामान्य मजकूर, महत्वाचा मजकूर, फॉन्ट आकार बदल आणि हायपरलिंक्स आणि सामान्य रन सूचीशी संबंधित नसलेल्या इतर रचना. हे वाचल्यानंतर, तुम्हाला समजेल की समस्या कोठे असते, रनद्वारे चालवलेले भाषांतर कसे लिहायचे आणि तुम्ही स्वयंचलित बदली कधी नाकारली पाहिजे.

भाषांतरानंतर DOCX चे स्वरूप हरवले तर मी काय करावे? एका वाक्याचा निष्कर्ष

प्रथम केवळ सामान्य मजकूर रन परिच्छेदापर्यंत प्रक्रिया मर्यादित करा, मूळ रन अनुक्रम क्रमांकानुसार भाषांतर एक-एक करून लिहा, ते जतन करा आणि स्वीकृतीसाठी ते पुन्हा वाचा; जर ते एक जटिल संरचना आढळल्यास किंवा विभाग जुळत नसल्यास, थेट बदली नाकारू शकता.

समस्या कुठे आहे: संपूर्ण परिच्छेद बदलल्याने रन फॉरमॅट धुऊन जाईल

paragraph.text ला थेट मूल्य नियुक्त केल्याने परिच्छेदाची विद्यमान सामग्री नवीन मजकुरासह पुनर्स्थित केली जाईल. परिच्छेद-स्तरीय शैली कायम ठेवल्या जाऊ शकतात, परंतु मूळ रन-स्तरीय स्वरूपन स्वयंचलितपणे राखले जाणार नाही. हे वर्तन python-docx मजकूर API मध्ये स्पष्टपणे दस्तऐवजीकरण केले आहे.

भाषांतर परिणाम अचूक दिसत आहे, परंतु स्वरूप पूर्णपणे नाहीसे झाले आहे. हे बहुधा कारण असावे.

अर्जाची व्याप्ती: स्वरूप जतन केले आहे, परंतु याचा अर्थ असा नाही की इतर समस्यांचे निराकरण झाले आहे.

या लेखाच्या चाचणी नोंदी स्थानिकरित्या संश्लेषित केलेल्या DOCX वरून येतात, टाइपसेटिंग इंजिन स्क्रीनशॉट नाही. ते काय सोडवते ते म्हणजे "स्वरूप गमावल्याशिवाय प्रतिबंधित पुनर्स्थापना". हे क्रॉस-लँग्वेज सिंटॅक्स पुनर्रचना आपोआप सोडवत नाही किंवा भाषांतरानंतर पेजिंग अपरिवर्तित राहील याची खात्री करत नाही.

प्रथम श्रेणी मर्यादित करा जी सुरक्षितपणे सुधारली जाऊ शकते

हे संक्षेपित उदाहरण केवळ साधा मजकूर रन असलेले परिच्छेद स्वीकारते. जेव्हा परिच्छेदामध्ये हायपरलिंक्स, प्रतिमा, फील्ड, लाइन ब्रेक, टॅब किंवा इतर जटिल XML नोड्स असतात तेव्हा ते स्पष्टपणे नाकारतात आणि कॉलरला एका विशिष्ट प्रक्रियेकडे पुनर्निर्देशित करतात. कोड या घटकांना शांतपणे सपाट करणार नाही.

भाषांतर इनपुट ही स्ट्रिंगची अनियंत्रित सूची नाही: प्रत्येक परिणामामध्ये मूळ रनचा अनुक्रमांक असणे आवश्यक आहे आणि फेरबदल सुरू होण्यापूर्वी क्रमांक, क्रम आणि प्रकार सर्व जुळले पाहिजेत. अर्धवट अद्ययावत केल्यानंतर पुढील फील्डसह समस्या शोधू नयेत म्हणून लिहिण्यापूर्वी प्रमाणीकरण केले जाते.

एक किमान चाचणी जी वारंवार चालविली जाऊ शकते

चाचणी वातावरण python-docx==1.2.0 आहे. येथे इंग्रजी हस्तलिखित निश्चित तुलनामधून येते, जी रचना सत्यापित करण्यासाठी वापरली जाते आणि मशीन भाषांतराची विनंती करत नाही.

from docx import Document
from docx.oxml.ns import qn

def replace_plain_runs(paragraph, translated):
    if any(child.tag not in {qn("w:pPr"), qn("w:r")}
           for child in paragraph._p):
        raise ValueError("paragraph contains unsupported structures")
    runs = paragraph.runs
    for run in runs:
        if any(child.tag not in {qn("w:rPr"), qn("w:t")}
               for child in run._r):
            raise ValueError("run contains a field, image or control")
    if len(translated) != len(runs):
        raise ValueError("segment count mismatch")
    for index, item in enumerate(translated):
        if (not isinstance(item, dict) or item.get("id") != index
                or not isinstance(item.get("text"), str)
                or any(ch in item["text"] for ch in "\t\r\n")):
            raise ValueError("segment identity or text mismatch")
    for run, item in zip(runs, translated):
        run.text = item["text"]

def signature(paragraph):
    return [(r.text, r.bold, r.italic) for r in paragraph.runs]

doc = Document()
p = doc.add_paragraph()
p.add_run("请在 ")
p.add_run("周五之前").bold = True
p.add_run(" 提交报告。")
before = signature(p)
try:
    replace_plain_runs(p, [{"id": 0, "text": "Incomplete"}])
    raise AssertionError("bad segments accepted")
except ValueError:
    assert signature(p) == before

replace_plain_runs(p, [
    {"id": 0, "text": "Submit the report "},
    {"id": 1, "text": "before Friday"},
    {"id": 2, "text": "."},
])
doc.save("translated-runs.docx")
restored = Document("translated-runs.docx").paragraphs[0]
assert restored.text == "Submit the report before Friday."
assert restored.runs[1].bold is True
assert len(restored.runs) == 3
complex_p = doc.add_paragraph("keep")
complex_p.runs[0].add_break()
try:
    replace_plain_runs(complex_p, [{"id": 0, "text": "reject"}])
    raise AssertionError("line break accepted")
except ValueError:
    assert complex_p.text == "keep\n"
print("PASS count mismatch: no partial write")
print("PASS save/reopen: 3 runs, emphasis preserved")
print("PASS unsupported control: rejected")
print(signature(restored))

सेव्ह केल्यानंतर, translated-runs.docx पुन्हा उघडा आणि नंतर फक्त मेमरीमधील वस्तू तपासणे टाळण्यासाठी ते स्वीकारा.

प्रत्येक रन अनुवादकाला स्वतंत्रपणे का देत नाही?

रन ही फॉरमॅटची सीमा आहे, सिमेंटिक सीमा नाही. शब्दाचा संपादन इतिहास एका शब्दाला एकाधिक धावांमध्ये विभाजित करू शकतो. पृथक भाषांतरे संदर्भ गमावतील; वेगवेगळ्या भाषांचा शब्द क्रम वाक्याच्या सुरूवातीस किंवा शेवटी देखील जोर देऊ शकतो.

वास्तविक भाषांतर निर्मितीने संपूर्ण विभाग म्हणून संदर्भ प्रदान केले पाहिजे आणि नंतर प्रमाणित संरचित विभाग परत करावे. जेव्हा परत आलेला परिणाम मूळ लांबी सारखा नसतो, तेव्हा त्यास विद्यमान रनमध्ये जबरदस्ती करू नका. एक स्पष्ट रीफॉर्मेटिंग धोरण किंवा मॅन्युअल पुनरावलोकन आवश्यक आहे. या लेखातील साधे उदाहरण फक्त तीन तुकडे ठेवू शकते, परंतु हे सर्व भाषांमध्ये सामान्यीकृत केले जाऊ शकत नाही.

स्वीकृती तीन स्तरांमध्ये विभाजित करा

_p आणि _r हे XML तपासण्यासाठी वापरलेले अंतर्गत गुणधर्म आहेत. python-docx अपग्रेड करताना, तुम्हाला आवृत्ती दुरुस्त करून चाचणी पुन्हा चालवावी लागेल. आपण असे गृहीत धरू शकत नाही की अंतर्गत रचना कधीही बदलणार नाही. जेव्हा तुम्हाला सारण्या, शीर्षलेख, तळटीप, मजकूर बॉक्स आणि पुनरावृत्ती ट्रेसवर प्रक्रिया करण्याची आवश्यकता असते, तेव्हा तुम्ही सामग्री श्रेणी स्वतंत्रपणे गणल्या पाहिजेत, कारण document.paragraphs दस्तऐवजातील सर्व मजकूर दर्शवू शकत नाही.

डिलिव्हरीपूर्वी स्टॉप अट

असमर्थित संरचना, न जुळणारे विभाग, गहाळ फॉन्ट, महत्त्वाच्या फील्डमधील बदल, यापैकी कोणतेही स्वयंचलित वितरण रोखले पाहिजे. मूळ फाइल केवळ-वाचनीय म्हणून जतन करा, नवीन फाइलमध्ये भाषांतर लिहा आणि भाषा, प्रक्रिया आवृत्ती आणि मॅन्युअल स्वीकृती रेकॉर्ड संलग्न करा. "यशस्वीपणे जतन करा" पेक्षा हे गुणवत्तेचे चांगले सूचक आहे.

तुम्हाला दस्तऐवज अपलोड करण्यापासून भाषांतर आणि पुनरावलोकन प्रक्रियेपर्यंत जाण्याची आवश्यकता असल्यास, तुम्ही OmniDoc उत्पादन पोर्टल तपासू शकता. या लेखातील कोड उदाहरणे स्वतंत्र मुक्त स्रोत लायब्ररी शिकवण्याचे नमुने आहेत आणि OmniDoc च्या वर्तमान आयातक किंवा लेआउट इंजिनच्या अंमलबजावणीचे प्रतिनिधित्व करत नाहीत. फक्त एकच मुख्य तत्व आहे: भाषांतरित बोनस ऐवजी फॉरमॅटला डेटा म्हणून स्वीकारा.

📊 मुख्य तुलना

🎯 तुमच्यासाठी कोणती पद्धत योग्य आहे?

जर तुमच्या परिच्छेदात फक्त सामान्य मजकूर असेल तर

या लेखातील किमान उदाहरणानुसार, प्रथम अनुक्रमांक, प्रमाण, क्रम आणि प्रकार सत्यापित करा, नंतर एक-एक करून परत लिहा, स्वीकृतीसाठी जतन करा आणि पुन्हा वाचा.

जर तुमच्या परिच्छेदामध्ये हायपरलिंक्स, फील्ड किंवा इमेज असतील

स्वयंचलित प्रतिस्थापन थेट नाकारून ते एका विशेष प्रक्रियेत हस्तांतरित करा. कोड या संरचनांना शांतपणे सपाट करत नाही.

जर तुम्ही औपचारिक द्विभाषिक कागदपत्रे वितरीत करत असाल

मूळ फाइल केवळ-वाचनीय म्हणून जतन करा, नवीन फाइलमध्ये भाषांतर लिहा आणि भाषा, प्रक्रिया आवृत्ती आणि मॅन्युअल स्वीकृती रेकॉर्ड संलग्न करा. गहाळ फॉन्ट, महत्त्वाच्या फील्डमधील बदल, न जुळणारे विभाग, इत्यादी सर्वांनी स्वयंचलित वितरणास प्रतिबंध केला पाहिजे.

❓ वारंवार विचारले जाणारे प्रश्न (FAQ)

१. तुम्ही paragraph.text ला थेट मूल्य नियुक्त केल्यास धैर्य गमावले जाईल का?

बैठक परिच्छेद-स्तरीय शैली कायम ठेवल्या जाऊ शकतात, परंतु मूळ रन-स्तरीय स्वरूपन स्वयंचलितपणे राखले जाणार नाही.

२. प्रत्येक रन भाषांतरकाराला स्वतंत्रपणे का देत नाही?

रन ही सिमेंटिक सीमा ऐवजी फॉरमॅटची सीमा आहे. एकामागून एक वेगळे केलेले भाषांतर संदर्भ गमावेल, आणि वेगवेगळ्या भाषांचा शब्द क्रम देखील वाक्याच्या सुरूवातीस किंवा शेवटी जोर देऊ शकतो.

३. यशस्वीरित्या सेव्ह करणे म्हणजे फॉरमॅट ठीक आहे का?

करू शकत नाही. फाइल स्वीकृती डेटा संरचना जतन केल्यानंतर पुन्हा उघडल्या पाहिजेत; सिमेंटिक सामग्री आणि व्हिज्युअल लेआउट स्वतंत्रपणे तपासणे आवश्यक आहे.

४. python-docx अपग्रेड करताना मी कशाकडे लक्ष द्यावे?

कोड _p आणि _r च्या अंतर्गत गुणधर्मांचा वापर करतो. तुम्हाला आवृत्ती दुरुस्त करून चाचणी पुन्हा चालवावी लागेल. आपण असे गृहीत धरू शकत नाही की अंतर्गत रचना कधीही बदलणार नाही.

📝 सारांश

फक्त एकच मुख्य तत्व आहे: भाषांतरित बोनस ऐवजी फॉरमॅटला डेटा म्हणून स्वीकारा. या लेखातील कोड उदाहरणे स्वतंत्र मुक्त स्रोत लायब्ररी शिकवण्याचे नमुने आहेत आणि OmniDoc च्या वर्तमान आयातक किंवा लेआउट इंजिनच्या अंमलबजावणीचे प्रतिनिधित्व करत नाहीत.

हे आता वापरून पहा: मूळ लेआउट कायम ठेवून भाषांतर सुरू करण्यासाठी दस्तऐवज अपलोड करा