JSON உள்ளூர்மயமாக்கலின் போது எந்த பகுதிகளை மொழிபெயர்க்கலாம் மற்றும் எந்த பகுதிகளை மாற்றக்கூடாது?

JSON உள்ளூர்மயமாக்கலில் ஒரு பொதுவான தோல்வி: பக்க பொத்தான்கள் ஆங்கிலத்திற்கு மாற்றப்பட்டுள்ளன, ஆனால் நிரலால் தொடர்புடைய உள்ளமைவு உருப்படிகளைக் கண்டறிய முடியவில்லை. காரணம், பொருளில் உள்ள ஒவ்வொரு சரமும் செயலாக்கத்திற்காக மொழிபெயர்ப்பாளரிடம் ஒப்படைக்கப்படும், மேலும் முக்கிய பெயர், ரூட்டிங் மற்றும் வணிக குறியாக்கமும் அதற்கேற்ப மாறுகிறது. இந்த கட்டுரை டெவலப்பர்கள் மற்றும் சர்வதேச கட்டமைப்பிற்கு பொறுப்பான உள்ளூர்மயமாக்கல் பணியாளர்களுக்காக எழுதப்பட்டது. முதலில் மொழிபெயர்க்கக்கூடிய புலப் பாதைகளை எவ்வாறு வரையறுப்பது மற்றும் பின்னர் ஏற்றுக்கொள்வது எப்படி என்பதை இது விளக்குகிறது.

எடுத்துக்காட்டுகள் செயலாக்க முறைகளை நிரூபிக்க செயற்கை மாதிரிகளைப் பயன்படுத்துகின்றன, மேலும் குறியீடு தனிமைப்படுத்தப்பட்ட சூழலில் சரிபார்க்கப்பட்டது, ஆனால் இது அனைத்து உண்மையான கோப்புகள் அல்லது தயாரிப்பு செயல்திறனுக்கு உத்தரவாதம் அளிக்காது. முக்கியமான ஆவணங்களைச் செயலாக்குவதற்கு முன், அசல்களை வைத்து, உரையில் உள்ள எல்லைகள் மற்றும் ஏற்றுக்கொள்ளும் உருப்படிகளின்படி அவற்றை மதிப்பாய்வு செய்யவும்.

JSON உள்ளூர்மயமாக்கலின் போது எதை மொழிபெயர்க்கலாம்? ஒரு வாக்கியத்தின் முடிவு

முன்கூட்டியே பட்டியலிடப்பட்ட நகல் எழுதும் பாதைகள் மட்டுமே மொழிபெயர்க்கப்படும், மேலும் முக்கிய பெயர்கள், ரூட்டிங் மதிப்புகள் மற்றும் வணிகக் குறியீடுகள் அப்படியே இருக்கும், மேலும் மாறாத பகுதிகள் உண்மையில் மாற்றப்படவில்லை என்பதை உறுதிப்படுத்த ஏற்றுக்கொள்ளும் சரிபார்ப்புப் பட்டியல் பயன்படுத்தப்படும்.

அனைத்து சரங்களையும் கடந்து செல்வதற்கு பதிலாக புல பாதையில் தொடங்கவும்

நீங்கள் பார்க்கும் போது "சேமி" என்ற சரத்தை மாற்றுவதை விட buttons.save ஐ முகவரியாகக் கருதுவது நம்பகமானது. ஒரே வாக்கியம் இடைமுக நகல், பதிவு மாதிரிகள் மற்றும் சோதனை வழக்குகளில் ஒரே நேரத்தில் தோன்றலாம், மேலும் மூன்று இடங்களிலும் மொழிபெயர்ப்பு தேவையில்லை.

tuples அல்லது JSON பாயிண்டர்களைப் பயன்படுத்தி பாதைகள் சந்தேகத்திற்கு இடமின்றி குறிப்பிடப்பட வேண்டும். புள்ளிகளைக் கொண்டு எளிமையாகப் பிரிக்கும்போது, முக்கியப் பெயரிலேயே புள்ளிகள் இருந்தால் தெளிவின்மை ஏற்படும்.

பின்வரும் எடுத்துக்காட்டு இரண்டு குறிப்பிட்ட பாதைகளை மட்டுமே கட்டுப்படுத்துகிறது, மற்ற உள்ளடக்கத்தை அப்படியே விட்டுவிடுகிறது. இது இந்தக் கட்டுரைக்கான உள்ளூர்மயமாக்கல் உத்தி, JSON வடிவமைப்பின் தேவை அல்ல. செயற்கை மாதிரியானது இடைமுக உரை மற்றும் ஒரு ரூட்டிங் மதிப்பு இரண்டையும் கொண்டுள்ளது, இது எல்லை சரிபார்ப்பை எளிதாக்குவதற்கு மாற்றப்படக்கூடாது.

ஒரு நேரத்தில் வெளிப்படையாக அனுமதிக்கப்பட்ட மதிப்புகளை மட்டும் மாற்றவும்

import copy

source = {"buttons": {"save": "保存", "cancel": "取消"},
          "route": "/settings", "version": 1}
approved = {("buttons", "save"): "Save",
            ("buttons", "cancel"): "Cancel"}

def apply_texts(document, replacements):
    result = copy.deepcopy(document)
    for path, translated in replacements.items():
        if not path or not isinstance(translated, str):
            raise ValueError("invalid replacement")
        parent = result
        for key in path[:-1]:
            parent = parent[key]
        key = path[-1]
        if key not in parent or not isinstance(parent[key], str):
            raise ValueError("target must be an existing string")
        parent[key] = translated
    return result

result = apply_texts(source, approved)
assert result["buttons"]["save"] == "Save"
assert result["route"] == source["route"]
assert source["buttons"]["save"] == "保存"
try:
    apply_texts(source, {("version",): "one"})
except ValueError:
    pass
else:
    raise AssertionError("numeric field must be rejected")

உதாரணம் பொருளின் அளவை மட்டுமே காட்டுகிறது, வரிசை அட்டவணைப்படுத்தலை செயல்படுத்தாது மற்றும் மொழிபெயர்ப்பு சேவையை அழைக்காது. உண்மையான பைப்லைனுக்கு சமர்ப்பிக்கும் போது, மொழிபெயர்ப்பிற்கு முன் அனுமதிக்கப்பட்ட பாதைகளின் பட்டியல் தீர்மானிக்கப்பட வேண்டும், மேலும் மொழிபெயர்ப்பை உருவாக்கும் தரப்பு அதன் சொந்த மாற்றங்களின் நோக்கத்தை ஒரே நேரத்தில் விரிவாக்க அனுமதிக்க முடியாது.

ஆழமான நகலானது உள்ளீட்டுப் பொருள்களை மாற்றியமைப்பதைத் தடுக்கலாம், ஆனால் இது ஒரு பரிவர்த்தனை அமைப்பு அல்ல. விடாமுயற்சி இன்னும் தனித்தனியாக வடிவமைக்கப்பட வேண்டும்.

ஏற்றுக்கொள்ளுதல் மாறாத பகுதிகளைப் பொறுத்தது

"இலக்கு மொழி உள்ளது" என்பதைச் சரிபார்ப்பது மட்டும் போதாது. மூல கோப்பு ஹாஷ்கள் மற்றும் பாதைகளின் பட்டியலும் சேமிக்கப்பட வேண்டும். மூலக் கோப்பு புதுப்பிக்கப்பட்ட பிறகு பாதை நீக்கப்பட்டால், பழைய மொழியாக்கம் தானாகவே அதே புலப் பெயர்களுடன் மீண்டும் எழுத முடியாது.

அணிவரிசைகள், பூஜ்ய மதிப்புகள் மற்றும் நகல் விசைகள் தனித்தனியாக கருதப்பட வேண்டும்

• வரிசை: உறுப்புகள் மறுசீரமைக்கப்பட்ட பிறகு, குறியீட்டு அசல் நகலை இன்னும் சுட்டிக்காட்டாமல் இருக்கலாம். நிலையான ஐடி இருக்கும்போது, ஐடி முதலில் மேப்பிங்கிற்குப் பயன்படுத்தப்படும்.
• Null: null என்பது ஒரு வெற்று சரம் அல்ல, மேலும் மொழிபெயர்ப்பின் வசதிக்காக "காலி" என்று மாற்றப்படக்கூடாது.
• நகல் விசை: சாதாரண JSON பாகுபடுத்துதல் முடிந்த பிறகு நகல் முக்கியத் தகவல் தொலைந்திருக்கலாம். நீங்கள் நகல் விசைகளை நிராகரிக்க விரும்பினால், மொழிபெயர்ப்பு முடிவடையும் வரை காத்திருக்காமல், பாகுபடுத்தும் கட்டத்தில் அவற்றைக் கையாள வேண்டும். குறிப்பு பைதான் JSON ஆவணங்கள்.

இந்த எடுத்துக்காட்டு நன்கு கட்டமைக்கப்பட்ட உள்ளமைவு உள்ளூர்மயமாக்கலுக்கு ஏற்றது, தன்னிச்சையான JSON தானியங்கு மொழிபெயர்ப்பாளர் அல்ல. மொழிபெயர்ப்பை ஏற்கும் போது, முதலில் கட்டமைப்பு மற்றும் பாதுகாக்கப்பட்ட புலங்கள் மாறவில்லை என்பதை உறுதிசெய்து, பின்னர் மொழி இயற்கையானதா என்பதை விவாதிக்கவும். சரிசெய்தல் வரிசை தெளிவாக இருக்கும்.

📊 முக்கிய ஒப்பீடு

🎯 எந்த முறை உங்களுக்கு ஏற்றது?

நீங்கள் என்றால்....

• இடைமுக உள்ளமைவுக் கோப்பைப் பராமரிக்க, பொத்தான் நகல் மொழிபெயர்க்கப்படவும், நிரல் உள்ளமைவு மாறாமல் இருக்கவும் விரும்பினால், புலப் பாதை அனுமதிப்பட்டியலைப் பயன்படுத்தி, மொழிபெயர்ப்பிற்கு முன் பாதை பட்டியலைத் தீர்மானிக்கவும்.
• வரிசை உறுப்புகள் மறுசீரமைக்கப்படலாம், அட்டவணைகளை நம்புவதற்குப் பதிலாக மேப்பிங்கிற்கு நிலையான ஐடிகளைப் பயன்படுத்துவதற்கு முன்னுரிமை கொடுங்கள்.
• மூலக் கோப்பு தொடர்ந்து புதுப்பிக்கப்படும். மூல கோப்பு ஹாஷ் மற்றும் பாதை பட்டியலை சேமிக்கவும். பாதை மறைந்துவிட்டால், பிழை ஏற்படும் மற்றும் பழைய மொழிபெயர்ப்பு தானாகவே மீண்டும் எழுதப்படாது.
• உண்மையான ஆவணங்களின் விநியோகத்தை நீங்கள் செயலாக்க வேண்டும் என்றால், அனுமதிக்கப்பட்ட பாதைகள், அசல் உரை மற்றும் மொழிபெயர்ப்பின் மதிப்பாய்வு பட்டியலை உருவாக்கி, அவற்றை ஒவ்வொன்றாக மதிப்பாய்வு செய்யவும்.

❓ அடிக்கடி கேட்கப்படும் கேள்விகள் (FAQ)

1. JSON இல் உள்ள அனைத்து சரங்களையும் ஏன் நேரடியாக மொழிபெயர்க்கக்கூடாது?

ஏனெனில் ஒரே சரம் இடைமுக நகல், நிரல் முக்கிய பெயர் அல்லது வணிகக் குறியீடாக ஒரே நேரத்தில் இருக்கலாம். ஒவ்வொரு சரமும் மொழிபெயர்ப்பாளரிடம் ஒப்படைக்கப்படும் போது, முக்கிய பெயர், ரூட்டிங் மற்றும் வணிக குறியாக்கம் ஆகியவை ஒன்றாக மாற்றப்படலாம், இதனால் நிரல் உள்ளமைவு உருப்படியைக் கண்டறிய முடியாது.

2. பாதைகளை பிரிக்க புள்ளிகளைப் பயன்படுத்துவதில் உள்ள சிக்கல்கள் என்ன?

முக்கியப் பெயரிலேயே ஒரு காலப்பகுதி இருந்தால், புள்ளிகளை இணைப்பது தெளிவின்மையை ஏற்படுத்தும். அசல் கட்டுரை tuples அல்லது JSON பாயிண்டர்கள் போன்ற தெளிவற்ற பிரதிநிதித்துவங்களைப் பயன்படுத்த பரிந்துரைக்கிறது.

3. மொழிபெயர்ப்பில் இலக்கு மொழி இடம் பெற்றுள்ளதா என்பதை மட்டும் சரிபார்த்தால் போதுமா?

போதாது. முக்கிய பெயர்களின் தொகுப்பு மூலக் கோப்புடன் ஒத்துப்போகிறதா, அங்கீகரிக்கப்படாத பாதையின் மதிப்பு மாறாமல் உள்ளதா, இலக்கு புலம் இன்னும் சரமாக உள்ளதா, மற்றும் விடுபட்ட பாதைகள் பிழைகள் என வெளிப்படையாகப் புகாரளிக்கப்படுகிறதா என்பதையும் நீங்கள் சரிபார்க்க வேண்டும்.

4. null ஐ "காலி" என்ற உரையுடன் மாற்ற முடியுமா?

முடியாது. null என்பது வெற்று சரம் அல்ல, மொழிபெயர்ப்பு வசதிக்காக உரையுடன் மாற்றப்படக்கூடாது.

5. அணிவரிசைகளை மொழிபெயர்க்கும்போது மேப்பிங்கிற்கு எதைப் பயன்படுத்த வேண்டும்?

நிலையான ஐடி இருக்கும்போது, ஐடி முதலில் மேப்பிங்கிற்குப் பயன்படுத்தப்படும். குறியீட்டை மட்டுமே நம்பி, உறுப்புகள் மறுசீரமைக்கப்பட்ட பிறகு தவறான நகல் ஒத்திருக்கலாம்.

📝 சுருக்கம்

JSON உள்ளமைவை மொழிபெயர்ப்பதற்கு முன், முதலில் மொழிபெயர்ப்பை அனுமதிக்கும் பாதைகளை தெளிவுபடுத்தவும், பின்னர் மாறாத பகுதிகளைச் சரிபார்க்க ஏற்றுக்கொள்ளும் சரிபார்ப்புப் பட்டியலைப் பயன்படுத்தவும். ஏதேனும் தவறு நடந்தால் சிக்கலைக் கண்டறிவதை இது எளிதாக்குகிறது.

இப்போது முயற்சிக்கவும்: அசல் தளவமைப்பைத் தக்கவைத்து, மொழிபெயர்ப்பைத் தொடங்க ஆவணத்தைப் பதிவேற்றவும்