تمكنت للتو من إرسال رسالة باستخدام عنوان Gmail وتطبيق Gmail المستند إلى الويب - وكان هذا يحتوي على توقيع بصري تم قصه بنجاح.
ومع ذلك، عند استخدام نفس حساب البريد الإلكتروني لإرسال رسالة عبر تطبيق Outlook 2016 المحلي على جهاز الكمبيوتر الشخصي، لم يتم إزالة التوقيع (نفس صورة التوقيع، لكنها مُعدة في Outlook).
بشكل واقعي، سيستخدم الغالبية العظمى من مستخدمي المنتدى تطبيق Microsoft Outlook، لذا يجب أن يكون ذلك معيارًا لـ “النجاح” في عملية القص.
هل مصدر البريد الإلكتروني الوحيد من Outlook 2016 هو الذي يسبب لك مشاكل مع التواقيع، أم جميعها؟
هل من المعروف أن Outlook 2016 يُدخل محتوى يقاوم القص؟ أم ربما لم يُعتبر Outlook 2016 أحد التطبيقات الشائعة التي يجب تضمينها في مكتبة email_reply_trimmer؟
هل توصل أي شخص إلى استراتيجية للتعامل مع هذا؟ (بخلاف طلب من المستخدمين تذكر إيقاف التواقيع التلقائية عند مراسلة المنتدى - وهو ما أعرف أنه سيثير الشكاوى!)
أرى أيضًا أنه بينما لم يتم قص التواقيع في رسائل Outlook 2016، إلا أنها لا تُحلل بشكل صحيح، وفي حالتي مع تنسيق خط مشوه وخطوط، بالإضافة إلى بعض الأحرف النصية المضافة وصورة مفرطة التوسيع - أو هل هذا نتيجة لمحاولة قص غير ناجحة؟
إنه توقيع مستخدم واحد من Outlook 16 يمر دائمًا عبر أداة التقليم، وآخر من عميل غير معروف (لكنه مُرسل عبر outlook.com و/أو MS-Exchange) يحتوي على بعض ملفات الصور المربعة البيضاء في الأسفل، مثل هذا:
هل مكتبة email_reply_trimmer هذه شيء يمكن لأي شخص عادي (مثل أنا) أن يلعب به لمعرفة ما إذا كان بإمكانه تحديد الأنماط في السكربت كما تُطبّق على تطبيقات البريد الإلكتروني الأخرى وإضافة فلتر لتوقيفات Outlook 2016؟ أعتقد أنني قرأت أن هذا السكربت أصبح الآن جزءًا أساسيًا من Discourse؟ أم أنني أضلل نفسي؟
لم أتعامل مع GitHub من قبل، ولا أود أن أتسبب في أي ضرر للآخرين أثناء التجريب، أو حتى إلحاق ضرر لا يمكن إصلاحه بمنتداي الخاص.
جرب تغيير برنامج نموذج الويب لوضع الرسالة أسفل – (شرطتان وفضة) لجعلها تبدو أكثر مثل التوقيع.
blah blah
النموذج: المحتوى
--
تم إرسال هذه الرسالة الإلكترونية إلى [البريد الإلكتروني للفئة] نتيجة لإكمال نموذج.
انقر هنا للإبلاغ عن البريد الإلكتروني غير المرغوب فيه.
لا تنسخ حرفيًا شرطتي والفضة أعلاه، فهناك خدعة يونيكود فيها
ستكون هذه الميزة مفيدة للغاية - القدرة على إضافة التوقيعات المسيئة إلى قائمة «احذف هذا إذا ظهر مرة أخرى». يمكن أن يكون التطابق أكثر وضوحًا بعض الشيء، حيث سيقتصر على إزالة ذلك النص حرفيًا، بدلاً من الاضطرار إلى محاولة مطابقة جميع التوقيعات بشكل تخميني.
هذا ليس دقيقًا تمامًا — يجب أن يكون هناك مسافة في المنتصف، إذن: “- -”
شخصيًا، وجدت أنه من الصعب جدًا إقناع المستخدمين بإدراج ذلك في توقيعاتهم. لا بأس إذا كان بإمكانك النظر فوق كتفهم لإعداده لهم، لكنهم يجدون صعوبة في فعل ذلك بأنفسهم!! ربما مستخدموك أكثر إلمامًا بالتكنولوجيا.
في الواقع، لا يفعلون ذلك. إذا قمت بنسخ ولصق التعبير النمطي في السطر 144 إلى https://rubular.com/، ستلاحظ أنه يطابق -- (شرطة-شرطة-مسافة) لكنه لا يطابق - - (شرطة-مسافة-شرطة).
أه، فهمت. يبدو بالتأكيد أن هناك مسافة في المنتصف، ما لم تقم بنسخها ولصقها في شيء آخر (من السطر 144): "--/s" - يبدو لي أن هناك مسافة بين الشرطات عند عرضها ككود.
“–/s” عند نسخها ولصقها مباشرة في ماركداون، لا توجد مسافة بوضوح.
قد يفسر هذا سبب صعوبة نجاحي في هذا الأمر! شكراً لك على الصبر.
لا أعرف لغة Ruby، لكن يبدو أن \s يطابق سطرًا جديدًا بالإضافة إلى المسافة - إذا كان ذلك صحيحًا، فإن -- بمفردها في سطر منفصل، دون المسافة، يجب أن تكون مقبولة أيضًا.
يستخدم Markdown مجموعة من الشرطات لإنشاء خط فاصل. لدينا رسائل تتضمن تفاصيل الاجتماع أسفل خط فاصل. هل هناك بديل يمكننا استخدامه لإنشاء فاصل دون التسبب في قص المحتوى؟
على سبيل المثال، قد تحتوي رسالة بريد إلكتروني واردة نموذجية على ما يلي:
هذا هو محتوى رسالة بريد إلكتروني نموذجية. قد تتضمن تفاصيل اجتماع. إذا تم إرسال هذا المنشور عبر البريد الإلكتروني، فسيتم قص هذا الجزء - وكل ما يليه -.
المشكلة هي أنه عندما يرد هذا المستخدم على منشور في Discourse عبر البريد الإلكتروني، يبدو أن صورتين بيضاوين يتم إضافتهما إلى منشوره. يؤدي ذلك إلى ظهور مساحة بيضاء غير مرغوب فيها بعد نصه. ويبدو أن هذه المشكلة تحدث فقط لهذا المستخدم الواحد. ولا يملك هذا المستخدم توقيع بريد إلكتروني بالمعنى التقليدي.
ما زلت ألاحظ أن حوالي 5-10% من توقيعات الأعضاء تتسلل عبر الفلترة.
إذا لم تتمكن القواعد الحالية من التعامل مع هذه الحالات، فأنا أعتقد حقًا أن قاعدة بيانات يدوية لتوقيعات الأعضاء، أو حتى صور مضمنة في رسائل البريد الإلكتروني التي تُرسَل باستمرار ولا يتم التقاطها تلقائيًا، أمر ضروري.
لا يمكنني على الإطلاق توقع أن يغير المستخدمون توقيعات البريد الإلكتروني الخاصة بهم من أجل المنتدى فقط، الذي يمثل جزءًا ضئيلًا من نشاطهم اليومي في البريد الإلكتروني.
