متطلبات Google CAP

يجب أن تتّبع بيانات التنبيه مواصفات الإصدار 1.2 من بروتوكول التنبيه الشائع (AASIS) في OASIS، بالإضافة إلى مواصفات Google Public Alert CAP v1.0 والمتطلبات الإضافية المذكورة أدناه.

لمحة عن Google CAP

يعمل معيار CAP على إنشاء البنية الأساسية وعناصر البيانات لتنبيه CAP، ولكنه لا يزال يقدم مساحة كبيرة للتناقضات في كيفية وتوقيت استخدام عناصر البيانات المختلفة.

ويهدف نظامنا الأساسي إلى تبسيط عملية العثور على معلومات الطوارئ من خلال جمع بيانات عالية الجودة وذات صلة داخل الأدوات على الإنترنت التي يستخدمها الأشخاص كل يوم. وتهدف المتطلبات الإضافية إلى زيادة مدى وصول التنبيهات إلى الجمهور وفعّاليتها على منتجات Google.

يتم تلخيص الاختلافات الخاصة بـ Google في متطلبات تنسيق CAP 1.2 XML في مواصفات إصدارات CAP للإصدار 1.0 من Google Public Alerts.

يتيح لك خيار &"تنبيهات Google العامة CAP" في أداة التحقق من صحة العنوان المفتوحة المصدر التحقق من بياناتك مقابل مواصفات OASIS ومتطلبات Google الإضافية.

وتسري الإرشادات أدناه على جميع أنواع التنبيهات والمخاطر. لقد جمعنا أيضًا بعض المتطلبات والاقتراحات الإضافية لأنواع التنبيهات المحدّدة هذه في قسم العيّنات:

إجراء اختبار دوري

  • يمكنك التأكّد من أنّ نظامك قادر على نشر التنبيهات من خلال <status>اختبار</status> لتنفيذ اختبارات نظامية شاملة.

مناطق التنبيه المستهدفة

  • إذا كانت هناك مناطق غير متعاقبة أسفل مستوى التنبيه نفسه ونوعه، أنشِئ رسائل <alert> منفصلة بدلاً من رسالة <alert> واحدة مع مناطق منفصلة.
  • إذا كان العنصر <area> يحتوي على عناصر <polygon>، تأكّد من أنها مضلّعات صالحة بدون تقاطع حواف، وحدِّد 6 نقاط عشرية كحد أقصى للدقة.
  • إذا كان عنصر <area> للتنبيهات يحتوي على رموز جغرافية، قدِّم البيانات الجغرافية بتنسيق shapefile وأبلغ Google على google-public-alerts@google.com على الأقل 30 يومًا قبل أي تغيير في شكل الملف.
  • يمكنك رسم مضلّعات مستندة إلى التأثير يتم تخصيصها للظروف الحالية وطبيعية الحدث كلما أمكن، بدلاً من استهداف التنبيهات مسبقًا للمناطق الجغرافية والسياسية (مثل المقاطعات أو المقاطعات).
  • يُرجى تزويد Google بوصف قصير (أقل من 50 حرفًا) للمنطقة المتأثرة في <areaDesc> أو في <parameter> مخصص منفصل من تنبيهات CAP. سيتم عرض هذا النص في عنوان التنبيه.

تضمين المحتوى الوافي

  • يجب تضمين محتوى ثري قابل للتنفيذ يمكن للمستخدمين قراءته في العنصرين <description> و<instruction>.
  • اشرح الحدث الحالي والتطورات المستقبلية والتأثير المتوقّع والاقتراحات بناءً على ذلك.
  • استخدِم القواعد الإملائية واللغوية وعلامات الترقيم الصحيحة.
  • استخدِم النص العادي أو تدوينًا لتحسين وضوح المحتوى، بدلاً من علامات HTML.
  • يُرجى تقديم رمز اللون RGB أو السداسي العشري المقابل لكل مستوى تنبيه (يمكن توفيره لـ Google بلا إنترنت).

تحديث التنبيهات

عند تغيير تنبيه، يمكنك إصدار تنبيه جديد يشير إلى التنبيه السابق، بدلاً من تغيير التنبيه الحالي أو إزالته من خلاصتك. بعد فترة زمنية مناسبة (على سبيل المثال، 24-48 ساعة)، أزِل التنبيهات المُلغاة أو المُعدَّلة أو المنتهية الصلاحية من خلاصتك.

<msgType> يجب أن يتضمن التعديل أو الإلغاء عنصر <references> واحدًا على الأقل. على النحو المحدّد في معيار CAP، يجب أن تستخدم أي رسالة تنبيه يتم تعديلها تنبيهًا سابقًا <msgType>Update</msgType> وأن تضبط <references>code</references> على جميع الرسائل السابقة ذات الصلة التي لم تصل إلى تاريخها <expires>. يجب تطبيق التعديل أو الإلغاء على تنبيه غير منتهي الصلاحية.

هناك ثلاث طرق لإلغاء الأحداث حسب الترتيب المفضّل:

  1. يمكنك ضبط تاريخ <expires> في كل حدث، مع تحديد وصف الرسالة المتوقّع بأن هذا التنبيه سينتهي عنده.
  2. يمكنك إصدار <alert> جديدة باستخدام <msgType>UPDATE و<responseType>"All Clear" و<expires> لفترة قصيرة في المستقبل.
  3. إصدار <alert> جديد باستخدام <msgType>CANCEL.

يُرجى الاطّلاع على أمثلة عن التنبيهات بشأن التحديثات وعمليات الإلغاء للحصول على أمثلة.

التوافق مع لغات متعددة

يُرجى إنشاء <alert> واحد يحتوي على حظر <info> متعدد (حظر <info> واحد لكل لغة).

لمزيد من التفاصيل ونموذج تنبيه متعدد اللغات، يُرجى الاطلاع على اللغات المتعددة.