تسمح Google بأن يتراوح عنوان المنتج بين 1 و150 حرفًا، وتطلب من التجار عدم استخدام الأحرف الكبيرة للتأكيد (مساعدة Merchant Center). وغالبًا ما تكون الكتالوجات التركية المصدَّرة من أنظمة ERP مكتوبة بأحرف كبيرة، لذا فإن الحل البديهي هو قاعدة تحوّل كل عنوان إلى أحرف صغيرة أو إلى نمط العنوان (Title Case). وهنا بالتحديد تتعطل البيانات التركية بصمت. في اختبارنا، أعاد التحويل الافتراضي إلى أحرف صغيرة للعنوان İZMİR ÇİZGİLİ KIŞLIK MONT ما مجموعه 30 code point بدلًا من 25، وتحوّلت ISPARTA إلى isparta بدلًا من ısparta. هذا الدليل موجّه لمديري الخلاصات والمطوّرين الذين يتعاملون مع نصوص المنتجات التركية. وفي نهايته ستتمكنون من اختبار منظومتكم، وإصلاح قاعدة تحويل الحالة، وإضافة فحص يكشف المشكلة في كل مزامنة.
لماذا تتعطل القواعد العادية مع حالة الأحرف التركية
في اللغة التركية زوجان منفصلان من الأحرف: ı بلا نقطة مع الحرف الكبير I، وi بنقطة مع الحرف الكبير İ. ويذكر ملف Unicode الخاص بتحويل الحالة ذلك صراحةً: «I and i-dotless; I-dot and i are case pairs in Turkish and Azeri» (Unicode SpecialCasing.txt).
أما التحويل الافتراضي (المحايد لغويًا) فلا يعرف ذلك. فهو يحوّل I إلى i، ويحوّل İ إلى i مع نقطة علوية مركّبة (U+0307). بينما تحوّل القواعد التركية في الملف نفسه I إلى ı وİ إلى i عادية. وتتبع الأذربيجانية القاعدة نفسها.
ثلاثة أمور تسوء في الخلاصة:
- أحرف خاطئة. تتحول
KADINإلىkadin، وتتحولYAĞIإلىyaği. تبقى الكلمة مقروءة، لكنها تحمل خطأ إملائيًا. - أحرف زائدة. تتحول
İZMİRإلىi̇zmi̇r، وهي سلسلة تحتوي على code points إضافية تبدو غير مرئية. تبدو شبه صحيحة على الشاشة، لكنها لا تطابقizmirفي عامل تصفية أو عملية ربط أو بحث. - أحرف كبيرة خاطئة في الاتجاه المعاكس. تتحول
istanbulإلىISTANBULبدلًا منİSTANBUL، وينتج نمط العنوانIçبدلًا منİç.
الخطوة 1: اكتشفوا ما تفعله منظومتكم حاليًا
قبل تغيير أي قاعدة، تحققوا من سلوك الشيفرة التي تحوّل عناوينكم. لقد مررنا المدخلَين نفسيهما عبر بيئات التشغيل التي تستخدمها معظم مسارات الخلاصات. كان المدخل ISPARTA İSTANBUL لاختبار الأحرف الصغيرة، وistanbul ışık لاختبار الأحرف الكبيرة.
| بيئة التشغيل والاستدعاء | نتيجة الأحرف الصغيرة | نتيجة الأحرف الكبيرة | مطابق للقواعد التركية؟ |
|---|---|---|---|
JavaScript toLowerCase() / toUpperCase() | isparta i̇stanbul | ISTANBUL IŞIK | لا |
JavaScript toLocaleLowerCase("tr") / toLocaleUpperCase("tr") | ısparta istanbul | İSTANBUL IŞIK | نعم |
Python 3.13 str.lower() / str.upper() | isparta i̇stanbul | ISTANBUL IŞIK | لا |
PHP 8.3 mb_strtolower() | i̇stanbul (للمدخل İSTANBUL) | غير متاح | لا |
PHP 8.3 strtolower() | isparta (للمدخل ISPARTA) | غير متاح | لا |
Perl lc() / uc() | isparta i̇stanbul | ISTANBUL IŞIK | لا |
تفصيلان مهمان. الأول أن الدالة toLocaleLowerCase() في JavaScript عند استدعائها دون وسيط تستخدم اللغة الافتراضية للبيئة، فقد تتصرف الشيفرة نفسها بشكل مختلف على الخادم وعلى الحاسوب المحمول. وتوضح الوثائق أن "İstanbul".toLocaleLowerCase("en-US") تعيد i̇stanbul بينما تعيد toLocaleLowerCase("tr") القيمة istanbul (MDN). مرّروا "tr" دائمًا بشكل صريح.
والثاني أن PHP 8.2 غيّرت الدالة strtolower() بحيث لم تعد تعتمد على setlocale() وصارت تحوّل أحرف ASCII فقط (دليل PHP). ولن يغيّر ضبط لغة تركية هذا السلوك في الإصدارات الحالية.
الخطوة 2: أنشئوا مجموعة اختبار من عناوين حقيقية
اختاروا من كتالوجكم من 10 إلى 15 عنوانًا تغطي كل الأحرف الخاصة بالتركية: İ وI وı وi وŞ وĞ وÇ وÖ وÜ. وأدرجوا عنوانًا يبدأ بـ I، وآخر يبدأ بـ İ، وثالثًا يتضمن وحدة قياس مثل ML أو GB. فيما يلي مجموعة للبدء، مع ناتج التحويل الافتراضي إلى أحرف صغيرة بجانب الناتج الصحيح.
| العنوان المصدر | التحويل الافتراضي إلى أحرف صغيرة | التحويل التركي إلى أحرف صغيرة |
|---|---|---|
ISPARTA GÜL YAĞI 50 ML | isparta gül yaği 50 ml | ısparta gül yağı 50 ml |
İZMİR ÇİZGİLİ KIŞLIK MONT | i̇zmi̇r çi̇zgi̇li̇ kişlik mont | izmir çizgili kışlık mont |
KADIN İÇ ÇAMAŞIRI SETİ | kadin i̇ç çamaşiri seti̇ | kadın iç çamaşırı seti |
IŞIK GEÇİRMEZ PERDE | işik geçi̇rmez perde | ışık geçirmez perde |
ÇOCUK OKUL ÇANTASI | çocuk okul çantasi | çocuk okul çantası |
انظروا إلى الصف الأخير. حرف واحد فقط يختلف، ومن السهل أن يفوت فحصًا بصريًا لبضعة عناوين. ولهذا يجب أن تغطي مجموعة الاختبار كل الأحرف، ولهذا تُقارَن السلاسل النصية فعليًا بدلًا من الاعتماد على الانطباع.
الخطوة 3: أصلحوا دالة تحويل الحالة
إذا كانت أداتكم تتيح اختيار اللغة، فاضبطوها على tr. وإذا لم تتيح ذلك، فغلّفوا عملية التحويل بأنفسكم. في JavaScript أو Node يكون الإصلاح وسيطًا واحدًا:
title.toLocaleLowerCase("tr")
title.toLocaleUpperCase("tr")لا تتضمن دوال النصوص القياسية في Python وسيطًا للغة. والحل البديل الموثوق هو استبدال الأحرف الأربعة الخاصة قبل استدعاء الدالة الافتراضية. لقد اختبرنا هذه النسخة على الصفوف الأربعة الأولى أعلاه:
def tr_lower(s):
return s.replace("İ", "i").replace("I", "ı").lower()
def tr_upper(s):
return s.replace("i", "İ").replace("ı", "I").upper()الترتيب مهم. استبدلوا İ وI أولًا ثم حوّلوا إلى أحرف صغيرة. فإذا حوّلتم أولًا، تكون المعلومة عن نوع الحرف الكبير قد ضاعت بالفعل.
الخطوة 4: عالجوا نمط العنوان والوحدات بشكل منفصل
يضيف نمط العنوان مشكلتين. فجعل الحرف الأول من كل كلمة كبيرًا يجب أن يستخدم التحويل التركي للأحرف الكبيرة، وإلا تحوّلت iç çamaşırı إلى Iç Çamaşırı في الدالة title() في Python. كما أن القاعدة الشاملة تجعل الوحدات بأحرف كبيرة: فتصبح 50 ML هكذا 50 Ml.
النمط الذي نعتمده هو: تحويل العنوان كاملًا إلى أحرف صغيرة بالدالة التركية، ثم تكبير الحرف الأول من كل كلمة بالدالة التركية، مع تخطي أي رمز يبدأ برقم أو يرد في قائمة قصيرة للوحدات (ml وgb وcm وkg). وعلى العنوان ISPARTA GÜL YAĞI 50 ML يعطي هذا Isparta Gül Yağı 50 ml. ومن دون قائمة الوحدات، يعيد المسار نفسه 50 Ml. لاحظوا أن Isparta صحيحة: فاسم المدينة يبدأ بالحرف الكبير I بلا نقطة.
أسماء العلامات التجارية حالة منفصلة. فالعلامة المكتوبة عمدًا بأحرف كبيرة (IKEA وHP) تحتاج إلى قائمة استثناءات، لأن Google تطلب فقط تجنب الأحرف الكبيرة للتأكيد، مع إبقائها حيثما يكون ذلك مناسبًا، كما في الاختصارات (مساعدة Merchant Center). أبقوا القائمة قصيرة واحفظوها في المكان نفسه الذي توجد فيه القاعدة.
وإذا كنتم تديرون هذه القواعد في أداة لإدارة الخلاصات، فتحققوا من كيفية تطبيقها لتحويل الحالة. تعرض Feed Rules في Feedance خيارات الأحرف الكبيرة وحالة الجملة وتكبير الحرف الأول، ولا تذكر الصفحة اللغة التي تعتمدها، لذلك نشغّل مجموعة الاختبار هذه على أي أداة، بما فيها أداتنا، قبل الوثوق بها مع النصوص التركية. وللحصول على نظرة أوسع حول متى تكفي القاعدة ومتى يستحق الأمر استخدام نموذج ذكاء اصطناعي، راجعوا مقارنتنا بين عناوين المنتجات المبنية على القواعد وتلك المبنية على الذكاء الاصطناعي.
الخطوة 5: اكتشفوا الأضرار المتبقية في البيانات الحالية
إذا كانت قاعدة خاطئة قد عملت بالفعل، فإن النقطة المركّبة موجودة الآن في بياناتكم المخزّنة. ولا يزيلها تطبيع Unicode: ففي اختبارنا، بقيت i متبوعة بـ U+0307 مكوّنة من code points اثنتين بعد تطبيع NFC، لأنه لا يوجد شكل مركّب مسبقًا تندمج فيه. عليكم إيجادها وإزالتها.
يعرض هذا الفحص كل عنوان يحتوي على النقطة العلوية المركّبة:
import re
bad = [t for t in titles if re.search("̇", t)]وبعد إعادة تشغيل القاعدة المصحّحة على İZMİR، يعيد الفحص نفسه القيمة false. شغّلوه على العنوان والوصف والعلامة التجارية وproduct_type وأي حقل custom_label، لأن قواعد تحويل الحالة كثيرًا ما تُطبَّق على أكثر من العناوين.
وبشكل منفصل، إذا أبلغت قناة عن خطأ في الترميز، فذلك عطل مختلف. فصفحة «Invalid UTF-8 encoding» في Merchant Center تذكر أن السبب مشكلة في ترميز النص، وتطلب منكم تحديد ترميز الملف أو تحويله (مساعدة Merchant Center). أما خطأ تحويل الحالة فينتج UTF-8 صالحًا، فلن يُطلق ذلك الخطأ. إنه يمر بصمت، وهذا هو سبب ضرورة اختباره.
الخطوة 6: اجعلوه بوابة فحص في كل مزامنة
إصلاحٌ لا يعيد أحد فحصه سيتراجع في أول مرة يضيف فيها شخص قاعدة جديدة أو يبدّل الأدوات. استخدموا قائمة التحقق هذه كبوابة إصدار لأي تغيير في قواعد العنوان أو الوصف أو اسم الفئة.
| الفحص | شرط النجاح |
|---|---|
| اللغة محددة صراحةً | تُستدعى كل دالة لتحويل الحالة مع tr أو تكون مغلّفة كما هو موضح أعلاه |
| اجتياز مجموعة الاختبار | تطابق كل الصفوف الناتج الصحيح تركيًا حرفًا بحرف |
| لا نقطة مركّبة | لا يحتوي أي حقل على U+0307 |
| الحفاظ على الوحدات | لا تُحوَّل رموز مثل ml وgb وcm إلى نمط العنوان |
| تطبيق استثناءات العلامات التجارية | تحتفظ العلامات المدرجة بأحرفها الكبيرة المقصودة |
| الطول دون تغيير | لا يزيد طول الناتج عن المدخل بعدد code points، ويبقى ضمن 150 |
يكشف فحص الطول الـ code points الإضافية التي يضيفها التحويل الافتراضي إلى أحرف صغيرة. وهو إنذار مبكر مفيد حتى لو لم تعرفوا بعد أي قاعدة تسببت في التغيير.
حدود هذه الطريقة
هذه طريقة للتركية والأذربيجانية، وهما اللغتان اللتان يدرجهما ملف Unicode لهذه القاعدة. وهي لا تغطي الحقول المكتوبة بالخط العربي؛ وللاطلاع عليها، راجعوا كيفية هيكلة بيانات المنتجات العربية والإنجليزية.
ليس لدينا دليل على أن Google أو أي سوق إلكتروني ترفض منتجًا بسبب خطأ في استخدام i بنقطة أو بلا نقطة. فالتكاليف الموثقة غير مباشرة: عناوين بأخطاء إملائية أمام المتسوقين، وسلاسل نصية لم تعد تطابق عوامل التصفية وعمليات الربط والبحث الداخلي لديكم. تعاملوا معها كعيب في جودة البيانات لا كمخالفة للسياسات.
تعالج حيلة الاستبدال في الخطوة 3 الأحرف الأربعة الخاصة، لكنها ليست تطبيقًا كاملًا لقواعد تحويل الحالة في Unicode. فالمكتبات المبنية على ICU والأدوات التي تتيح إعداد اللغة تغطي حالات حدّية أكثر من غلاف مكتوب يدويًا. وإذا كانت لدى أداة تستخدمونها بالفعل خيار لغة تركية صحيح، فاستخدموه واكتفوا بالاحتفاظ بمجموعة الاختبار. لم نختبر كيف تتعامل Channable وDataFeedWatch وProductsup مع اللغة التركية، لذلك لا نقدّم أي ادعاء في هذا الشأن؛ شغّلوا مجموعة الاختبار عليها كما تفعلون مع أي أداة. وللأسواق الإلكترونية قواعد عناوين خاصة بها فوق ما سبق، نغطيها في أدلتنا حول خلاصات Akakçe وCimri وN11 وÇiçekSepeti.
الأسئلة الشائعة
لماذا تتحول İZMİR إلى i̇zmi̇r عند تحويلها إلى أحرف صغيرة؟
يحوّل التحويل الافتراضي في Unicode الحرف الكبير İ ذا النقطة إلى i عادية مع نقطة علوية مركّبة (U+0307). أما القاعدة التركية فتحوّل İ إلى i عادية. تبدو النتيجة شبه صحيحة على الشاشة، لكنها تحتوي على code points إضافية.
هل ترفض Google Merchant Center العناوين التي تحتوي على النقطة المركّبة؟
لم نجد رفضًا موثقًا لذلك. فالسلسلة UTF-8 صالحة، ولذلك لا تُطلق خطأ «Invalid UTF-8 encoding». الضرر يتمثل في عناوين بأخطاء إملائية وفي فشل المطابقة داخل أدواتكم الخاصة.
هل أرسل العناوين بأحرف كبيرة أم صغيرة أم بنمط العنوان؟
تقول Google بعدم استخدام الأحرف الكبيرة للتأكيد وبوضع أهم التفاصيل أولًا، لأن المستخدمين يرون عادةً أول 70 حرفًا أو أقل فقط. وكلٌّ من حالة الجملة ونمط العنوان بأحرف تركية صحيحة يحقق ذلك. أما أيهما يحقق تحويلًا أفضل فهو اختبار يخص حسابكم.
هل يكفي toLowerCase("tr") في JavaScript؟
لا. فالدالة toLowerCase() لا تقبل لغة. استخدموا toLocaleLowerCase("tr") ومرّروا اللغة بشكل صريح، لأن القيمة الافتراضية تعتمد على البيئة.
لماذا لا يصلح setlocale الدالة strtolower في PHP؟
منذ PHP 8.2، تتجاهل strtolower() اللغة وتحوّل أحرف ASCII فقط. أما mb_strtolower() فتعالج النصوص غير ASCII، لكنها في اختبارنا أعادت مع ذلك i̇stanbul للمدخل İSTANBUL. طبّقوا استبدال الأحرف من الخطوة 3 قبل استدعائها.
هل يمكن لتطبيع Unicode إزالة النقطة الشاردة؟
لا. في اختبارنا، أبقى NFC على i مع U+0307 بوصفهما code points اثنتين. أزيلوا الحرف بشكل صريح، ثم أعيدوا تشغيل قاعدة تحويل الحالة المصحّحة على النص المصدر الأصلي.
هل يؤثر هذا على العربية أو اللغات الأخرى؟
تنطبق القاعدة على التركية والأذربيجانية. ولدى اللغات الأخرى مشكلات خاصة بها في تحويل الحالة والتطبيع، وهذا الدليل لا يغطيها.
كم صفًّا في مجموعة الاختبار يكفي؟
يكفي عدد يغطي كل حرف خاص بالتركية وكل موضع يمكن أن يأتي فيه: بداية الكلمة ووسطها ونهايتها وبجانب رقم. وفي معظم الكتالوجات يعني ذلك من 10 إلى 15 عنوانًا. أضيفوا صفًّا كلما ظهر عيب جديد في بيئة الإنتاج.
افحصوا خلاصتكم
إذا أردتم معرفة تقييم خلاصتكم الحالية من حيث جودة العناوين والسمات، فمرّروها عبر أداة تدقيق خلاصة المنتجات المجانية لدينا.
شريكة مؤسِّسة في Feedance، وتستند إلى أكثر من 20 عامًا من الخبرة في تصميم المنتجات وتجربة المستخدم لتشكيل الطريقة التي تتحول بها الكتالوجات إلى محتوى إبداعي. وبتركيز قوي على الربط بين أنظمة التصميم والأتمتة، تكرّس جهودها لمساعدة العلامات التجارية على توسيع نطاق الجودة البصرية دون توسيع الجهد المبذول في التصميم.
LinkedIn
