Ubuntu Manpages

الاسم

موجز

ping [-aAbBdCDfhHLnOqrRUvV346] [-c count] [-e identifier] [-F flowlabel] [-i interval] [-I interface] [-l preload] [-m mark] [-M pmtudisc_option] [-N nodeinfo_option] [-w deadline] [-W timeout] [-p pattern] [-Q tos] [-s packetsize] [-S sndbuf] [-t ttl] [-T timestamp option] [hop...] {destination}

الوصف

يستخدم ping مخطط بيانات ECHO_REQUEST الإلزامي لبروتوكول ICMP للحصول على استجابة ECHO_RESPONSE من مضيف أو بوابة. تحتوي مخططات بيانات ECHO_REQUEST (“ping”) على رأس IP و ICMP، متبوعًا بهيكل timeval ثم عدد عشوائي من بايتات “الحشو” المستخدمة لملء الحزمة.

يعمل ping مع كل من IPv4 و IPv6. يمكن فرض استخدام واحد منهما فقط بشكل صريح بتحديد -4 أو -6.

يمكن لـ ping أيضًا إرسال استعلامات معلومات العقدة IPv6 (RFC4620). قد لا يُسمح بـ القفزات الوسيطة، لأن توجيه المصدر IPv6 قد تم إهماله (RFC5095).

الخيارات

-3

دقة RTT (لا تقم بتقريب وقت النتيجة).

-4

استخدم IPv4 فقط.

-6

استخدم IPv6 فقط.

-a

ping مسموع.

-A

ping تكيفي. يتكيف الفاصل الزمني بين الحزم مع وقت الرحلة ذهابًا وإيابًا، بحيث لا يكون هناك أكثر من استقصاء واحد (أو أكثر، إذا تم تعيين التحميل المسبق) بدون إجابة في الشبكة. الفاصل الزمني المبدئي هو 2 مللي ثانية، لمزيد من المعلومات انظر الخيار -i. في الشبكات ذات RTT المنخفض، يكون هذا الوضع مكافئًا بشكل أساسي لوضع الفيضان.

-b

اسمح بإرسال ping إلى عنوان بث.

-B

لا تسمح لـ ping بتغيير عنوان مصدر الاستقصاءات. يتم ربط العنوان بالعنوان المحدد عند بدء ping.

-c count

توقف بعد إرسال عدد حزم ECHO_REQUEST. مع خيار الموعد النهائي، ينتظر ping عدد حزم ECHO_REPLY، حتى انتهاء المهلة.

-C

استدعاء استدعاء النظام connect() عند إنشاء المقبس.

-d

تعيين خيار SO_DEBUG على المقبس المستخدم. بشكل أساسي، لا يتم استخدام خيار المقبس هذا بواسطة نواة لينكس.

-D

طباعة الطابع الزمني (وقت يونكس + ميكروثانية كما في gettimeofday) قبل كل سطر.

-e identifier

تعيين حقل التعريف لـ ECHO_REQUEST. القيمة 0 تعني استخدام مقبس خام (غير مدعوم على مقبس مخطط بيانات ICMP). قد تتم طباعة قيمة الحقل باستخدام الخيار -v.

-f

ping فيضان. لكل ECHO_REQUEST يتم إرساله، تتم طباعة نقطة “.”، بينما لكل ECHO_REPLY يتم استلامه، تتم طباعة مسافة للخلف. يوفر هذا عرضًا سريعًا لعدد الحزم التي يتم إسقاطها. إذا لم يتم تحديد الفاصل الزمني، فإنه يضبط الفاصل الزمني على صفر ويخرج الحزم بأسرع ما تعود أو مائة مرة في الثانية، أيهما أكثر. فقط المستخدم الفائق يمكنه استخدام هذا الخيار بفاصل زمني صفري.

-F flow label

IPv6 فقط. تخصيص وتعيين ملصق تدفق 20 بت (بالنظام الست عشري) على حزم طلب الصدى. إذا كانت القيمة صفرًا، تقوم النواة بتخصيص ملصق تدفق عشوائي.

-h

إظهار المساعدة.

-H

فرض تحليل اسم DNS للإخراج. مفيد للوجهة الرقمية، أو الخيار -f، الذي لا يقوم بذلك افتراضيًا. يمكن أن يساعد أيضًا في تجاوز مشكلات تحليل DNS. يتجاوز الخيار -n المحدد مسبقًا. انظر أيضًا متغير البيئة IPUTILS_PING_PTR_LOOKUP.

-i interval

انتظر الفاصل الزمني ثوانٍ بين إرسال كل حزمة. يُسمح بالأرقام الحقيقية باستخدام النقطة كفاصل عشري (بغض النظر عن إعدادات اللغة). المبدئي هو الانتظار لثانية واحدة بين كل حزمة بشكل طبيعي، أو عدم الانتظار في وضع الفيضان. فقط المستخدم الفائق يمكنه تعيين الفاصل الزمني لقيم أقل من 2 مللي ثانية. البث والإرسال المتعدد لديهما قيود أعلى للمستخدم العادي: الحد الأدنى هو 1 ثانية.

-I interface

الواجهة هي إما عنوان، أو اسم واجهة، أو اسم VRF. إذا كانت الواجهة عنوانًا، فإنها تعين عنوان المصدر إلى عنوان الواجهة المحددة. إذا كانت الواجهة اسم واجهة، فإنها تعين واجهة المصدر إلى الواجهة المحددة. إذا كانت الواجهة اسم VRF، يتم توجيه كل حزمة باستخدام جدول التوجيه المقابل؛ في هذه الحالة، يمكن تكرار الخيار -I لتحديد عنوان مصدر. ملاحظة: بالنسبة لـ IPv6، عند عمل ping إلى عنوان نطاق رابط محلي، يمكن استخدام تحديد الرابط (بواسطة تدوين '%' في الوجهة، أو بواسطة هذا الخيار) ولكنه لم يعد مطلوبًا.

-l preload

إذا تم تحديد التحميل المسبق، يرسل ping هذا العدد من الحزم دون انتظار الرد. فقط المستخدم الفائق يمكنه اختيار تحميل مسبق أكبر من 3.

-L

قم بكتم حلقة الإرجاع للحزم المتعددة الإرسال. ينطبق هذا العلم فقط إذا كانت وجهة ping هي عنوان متعدد الإرسال.

-m mark

استخدم العلامة لوسم الحزم الصادرة. هذا مفيد لأسباب متنوعة داخل النواة مثل استخدام توجيه السياسات لاختيار معالجة صادرة محددة. مطلوب صلاحية CAP_NET_ADMIN أو CAP_NET_RAW (منذ Linux 5.17)، انظر socket(7).

-M pmtudisc_opt

اختر استراتيجية اكتشاف MTU للمسار. يمكن أن يكون خيار_pmtudisc إما do (تعيين علم DF ولكن يخضع لفحوصات PMTU بواسطة النواة، سيتم رفض الحزم الكبيرة جدًا)، أو want (قم باكتشاف PMTU، وتقسيم محليًا عندما يكون حجم الحزمة كبيرًا)، أو probe (تعيين علم DF وتجاوز فحوصات PMTU، مفيد للاستكشاف)، أو dont (لا تقم بتعيين علم DF).

-N nodeinfo_option

IPv6 فقط. أرسل استعلامات معلومات العقدة IPv6 (RFC4620)، بدلاً من طلب الصدى. مطلوب صلاحية CAP_NET_RAW.

help

اعرض المساعدة لدعم NI.

name

استعلامات عن أسماء العقد.

ipv6

استعلامات عن عناوين IPv6. هناك عدة أعلام خاصة بـ IPv6.

ipv6-global

اطلب عناوين IPv6 ذات النطاق العالمي.

ipv6-sitelocal

اطلب عناوين IPv6 المحلية للموقع.

ipv6-linklocal

اطلب عناوين IPv6 المحلية للرابط.

ipv6-all

اطلب عناوين IPv6 على واجهات أخرى.

ipv4

استعلامات عن عناوين IPv4. هناك علم واحد خاص بـ IPv4.

ipv4-all

اطلب عناوين IPv4 على واجهات أخرى.

subject-ipv6=ipv6addr

عنوان الموضوع IPv6.

subject-ipv4=ipv4addr

عنوان الموضوع IPv4.

subject-name=nodename

اسم الموضوع. إذا كان يحتوي على أكثر من نقطة واحدة، يُفترض اسم نطاق مؤهل بالكامل.

subject-fqdn=nodename

اسم الموضوع. يُفترض دائمًا اسم نطاق مؤهل بالكامل.

-n

مخرجات رقمية فقط. لن يُبذل أي جهد للبحث عن أسماء رمزية لعناوين المضيفين (لا حل عكسي لنظام أسماء النطاقات). هذا هو المبدئي للوجهة الرقمية أو الخيار -f. يتجاوز الخيار -H المُعرّف سابقاً. انظر أيضًا متغير البيئة IPUTILS_PING_PTR_LOOKUP.

-O

الإبلاغ عن رد ICMP ECHO المعلق قبل إرسال الحزمة التالية. هذا مفيد مع الطابع الزمني -D لتسجيل المخرجات في ملف تشخيصي والبحث عن الإجابات المفقودة.

-p pattern

يمكنك تحديد ما يصل إلى 16 بايت “حشو” لملء الحزمة التي ترسلها. هذا مفيد لتشخيص المشكلات المعتمدة على البيانات في الشبكة. على سبيل المثال، -p ff سيتسبب في ملء الحزمة المرسلة بكل الآحاد.

-q

مخرجات هادئة. لا يُعرض شيء باستثناء سطور الملخص عند بدء التشغيل وعند الانتهاء.

-Q tos

تعيين البتات المتعلقة بجودة الخدمة في مخططات بيانات ICMP. يمكن أن يكون tos عدداً عشرياً (ping فقط) أو عدداً سداسياً عشرياً.

في RFC2474، تُفسّر هذه الحقول على أنها خدمات متمايزة (DS) ذات 8 بت، تتكون من: البتات 0-1 (أدنى بتين) من بيانات منفصلة، والبتات 2-7 (أعلى 6 بتات) من نقطة رمز الخدمات المتمايزة (DSCP). في RFC2481 وRFC3168، تُستخدم البتات 0-1 لـ ECN.

تاريخياً (RFC1349، الذي أُبطل بواسطة RFC2474)، فُسّرت هذه على النحو التالي: البت 0 (أدنى بت) للمحجوز (يُعاد تعريفه حالياً كتحكم في الازدحام)، 1-4 لنوع الخدمة والبتات 5-7 (أعلى بتات) للأسبقية.

-r

تجاوز جداول التوجيه العادية والإرسال مباشرة إلى مضيف على واجهة متصلة. إذا لم يكن المضيف على شبكة متصلة مباشرة، يُرجع خطأ. يمكن استخدام هذا الخيار لاختبار اتصال مضيف محلي عبر واجهة لا يوجد مسار عبرها بشرط استخدام الخيار -I أيضًا.

-R

ping فقط. تسجيل المسار. يتضمن خيار RECORD_ROUTE في حزمة ECHO_REQUEST ويعرض مخزن المسار على الحزم المُعادة. لاحظ أن رأس IP كبير بما يكفي لتسعة مسارات فقط. تتجاهل العديد من المضيفات هذا الخيار أو تتخلص منه.

-s حجم_الحزمة

يحدد عدد بايتات البيانات التي سيتم إرسالها. المبدئي هو 56، والذي يُترجم إلى 64 بايت من بيانات ICMP عند دمجه مع 8 بايت من بيانات رأس ICMP. القيمة القصوى المسموح بها هي 65507 لـ IPv4 (65467 عند -R أو -T أو قفزات وسيطة) أو 65527 لـ IPv6، لكن معظم الأنظمة تحد هذا إلى رقم أصغر يعتمد على النظام.

-S sndbuf

تعيين sndbuf للمقبس. إذا لم يُحدد، يُختار لتخزين مؤقت لا يزيد عن حزمة واحدة.

-t ttl

ping فقط. تعيين وقت البقاء (TTL) لـ IP.

-T timestamp option

تعيين خيارات الطابع الزمني الخاصة لـ IP. يمكن أن يكون خيار الطابع الزمني إما tsonly (طوابع زمنية فقط)، أو tsandaddr (طوابع زمنية وعناوين) أو tsprespec مضيف1 [مضيف2 [مضيف3 [مضيف4]]] (قفزات محددة مسبقاً للطابع الزمني).

-U

طباعة زمن الانتقال الكامل من مستخدم إلى مستخدم (السلوك القديم). عادةً، يطبع ping زمن الرحلة ذهاباً وإياباً للشبكة، والذي يمكن أن يكون مختلفاً مثلاً بسبب فشل DNS.

-v

مخرجات مفصلة. لا تكتم ردود DUP عند اختبار اتصال عنوان متعدد الإرسال.

-V

عرض الإصدار والخروج.

-w deadline

تحديد مهلة، بالثواني، قبل خروج ping بغض النظر عن عدد الحزم المرسلة أو المستلمة. في هذه الحالة، لا يتوقف ping بعد إرسال عدد من الحزم، بل ينتظر إما انتهاء المهلة أو حتى يتم الرد على عدد من الاستقصاءات أو لتلقي إشعار خطأ من الشبكة.

-W timeout

وقت الانتظار للرد، بالثواني. يؤثر الخيار فقط على المهلة في غياب أي ردود، وإلا ينتظر ping لمدتين من زمن الرحلة ذهاباً وإياباً. يُسمح بالعدد الحقيقي مع النقطة كفاصل عشري (بغض النظر عن إعدادات اللغة). 0 يعني مهلة غير محدودة.

عند استخدام ping لعزل الأعطال، يجب تشغيله أولاً على المضيف المحلي، للتحقق من أن واجهة الشبكة المحلية قيد التشغيل. ثم، يجب “اختبار اتصال” المضيفات والبوابات الأبعد فالأبعد. تُحسب أزمنة الرحلة ذهاباً وإياباً وإحصائيات فقدان الحزمة. إذا تم استلام حزم مكررة، لا تُدرج في حساب فقدان الحزمة، على الرغم من استخدام زمن الرحلة ذهاباً وإياباً لهذه الحزم في حساب أرقام زمن الرحلة ذهاباً وإياباً الأدنى/المتوسط/الأقصى/الانحراف المعياري.

الانحراف المعياري للسكان (mdev)، وهو أساسًا متوسط مدى بُعد كل RTT ping عن متوسط RTT. كلما زاد mdev، زاد تباين RTT (بمرور الوقت). مع تباين RTT العالي، ستواجه مشكلات في السرعة مع النقل الجماعي (سيستغرق وقتًا أطول مما هو ضروري بالمعنى الدقيق، حيث سيؤدي التباين في النهاية إلى انتظار المرسل لـ ACKs) وستكون جودة VoIP متوسطة إلى ضعيفة.

عند إرسال (واستلام) العدد المحدد من الحزم أو إذا تم إنهاء البرنامج بـ SIGINT، يتم عرض ملخص موجز. يمكن الحصول على إحصائيات حالية أقصر دون إنهاء العملية باستخدام الإشارة SIGQUIT.

هذا البرنامج مخصص للاستخدام في اختبار الشبكة وقياسها وإدارتها. نظرًا للحمل الذي يمكن أن يفرضه على الشبكة، فمن غير الحكمة استخدام ping أثناء العمليات العادية أو من البرامج النصية الآلية.

البيئة

متغير البيئة IPUTILS_PING_PTR_LOOKUP المضبوط على 0 يعطل تحليل DNS العكسي (بحث PTR) بشكل مبدئي. سيتم تجاوزه بواسطة الخيار -H أو -n.

حالة الخروج

إذا لم يستلم ping أي حزم رد على الإطلاق، فسيخرج برمز 1. إذا تم تحديد كل من count و deadline، وتم استلام عدد أقل من count من الحزم بحلول وقت وصول deadline، فسيخرج أيضًا برمز 1. عند خطأ آخر، يخرج برمز 2. وإلا، يخرج برمز 0. هذا يجعل من الممكن استخدام رمز الخروج لمعرفة ما إذا كان المضيف نشطًا أم لا.

وجهات IPv6 المحلية للرابط

بالنسبة لـ IPv6، عندما يكون عنوان الوجهة ذو نطاق محلي للرابط ويستخدم ping مقابس مخططات بيانات ICMP، يجب تحديد واجهة الإخراج. عندما يستخدم ping مقابس خام، ليس من الضروري بالمعنى الدقيق تحديد واجهة الإخراج ولكن يجب القيام بذلك لتجنب الغموض عند وجود واجهات إخراج متعددة محتملة.

هناك طريقتان لتحديد واجهة الإخراج:

• باستخدام ترميز %

يتم إلحاق عنوان الوجهة بـ % واسم واجهة الإخراج أو ifindex، على سبيل المثال:

ping fe80::5054:ff:fe70:67bc%eth0

ping fe80::5054:ff:fe70:67bc%2

• باستخدام الخيار -I

عند استخدام مقابس مخططات بيانات ICMP، يتم دعم هذه الطريقة منذ إصدارات النواة التالية: 5.17، 5.15.19، 5.10.96، 5.4.176، 4.19.228، 4.14.265. كما أنها غير مدعومة على musl libc.

تفاصيل حزمة ICMP

رأس IP بدون خيارات هو 20 بايت. تحتوي حزمة ICMP ECHO_REQUEST على 8 بايت إضافية من رأس ICMP متبوعة بكمية عشوائية من البيانات. عند إعطاء packetsize، يشير هذا إلى حجم هذه القطعة الإضافية من البيانات (المبدئي هو 56). وبالتالي، ستكون كمية البيانات المستلمة داخل حزمة IP من نوع ICMP ECHO_REPLY دائمًا 8 بايت أكثر من مساحة البيانات المطلوبة (رأس ICMP).

إذا كانت مساحة البيانات على الأقل بحجم struct timeval، يستخدم ping البايتات الأولى من هذه المساحة لتضمين طابع زمني يستخدمه في حساب أوقات الرحلة ذهابًا وإيابًا. إذا كانت مساحة البيانات أقصر، لا يتم إعطاء أوقات رحلة ذهابًا وإيابًا.

الحزم المكررة والتالفة

سيبلغ ping عن الحزم المكررة والتالفة. لا ينبغي أن تحدث الحزم المكررة أبدًا، ويبدو أنها ناتجة عن إعادة إرسال غير مناسبة على مستوى الرابط. قد تحدث التكرارات في العديد من المواقف ونادرًا ما تكون (إن حدثت) علامة جيدة، على الرغم من أن وجود مستويات منخفضة من التكرارات قد لا يكون دائمًا مدعاة للقلق.

الحزم التالفة هي بوضوح سبب خطير للقلق وغالبًا ما تشير إلى عطل في الأجهزة في مكان ما في مسار حزمة ping (في الشبكة أو في المضيفين).

تصادمات المعرف

على عكس TCP وUDP، اللذين يستخدمان المنفذ لتحديد المستلم بشكل فريد لتسليم البيانات، يستخدم ICMP حقل المعرف (ID) للتحديد. لذلك، إذا استخدمت عمليتا ping على نفس الجهاز وفي نفس الوقت نفس المعرف، فقد يتم تسليم رد الصدى إلى مستلم خاطئ. هذه مشكلة معروفة بسبب الحجم المحدود لحقل المعرف ذي 16 بت. هذا قيد تاريخي للبروتوكول لا يمكن إصلاحه في الوقت الحالي ما لم نقم بتشفير معرف في حمولة حزمة ping. يطبع ping خطأ DIFFERENT ADDRESS ويكون فقدان الحزمة سالبًا.

يستخدم ping PID للحصول على رقم فريد. القيمة المبدئية لـ /proc/sys/kernel/pid_max هي 32768. على الأنظمة التي تستخدم ping بكثافة ومع pid_max أكبر من 65535، من المحتم حدوث تصادمات.

محاولة أنماط بيانات مختلفة

يجب ألا تعالج طبقة (الإنترنت) الشبكة الحزم بشكل مختلف اعتمادًا على البيانات الموجودة في جزء البيانات. لسوء الحظ، من المعروف أن المشكلات المعتمدة على البيانات تتسلل إلى الشبكات وتبقى غير مكتشفة لفترات طويلة من الزمن. في العديد من الحالات، النمط المحدد الذي سيواجه مشكلات هو شيء لا يحتوي على “تحولات” كافية، مثل كل الآحاد أو كل الأصفار، أو نمط على الحافة تمامًا، مثل كل الأصفار تقريبًا. ليس من الضروري بالضرورة تحديد نمط بيانات من كل الأصفار (على سبيل المثال) في سطر الأوامر لأن النمط المهم هو على مستوى وصلة البيانات، والعلاقة بين ما تكتبه وما تنقله وحدات التحكم يمكن أن تكون معقدة.

هذا يعني أنه إذا كان لديك مشكلة معتمدة على البيانات، فربما ستحتاج إلى إجراء الكثير من الاختبارات للعثور عليها. إذا كنت محظوظًا، فقد تتمكن من العثور على ملف لا يمكن إرساله عبر شبكتك أو يستغرق وقتًا أطول بكثير لنقله مقارنة بالملفات الأخرى ذات الطول المماثل. يمكنك بعد ذلك فحص هذا الملف بحثًا عن أنماط متكررة يمكنك اختبارها باستخدام الخيار -p من ping.

تفاصيل TTL

تمثل قيمة TTL لحزمة IP الحد الأقصى لعدد موجهات IP التي يمكن أن تمر بها الحزمة قبل التخلص منها. في الممارسة الحالية، يمكنك توقع أن يقوم كل موجه في الإنترنت بإنقاص حقل TTL بمقدار واحد بالضبط.

قد يأخذ حقل TTL لحزم TCP قيمًا مختلفة. القيمة القصوى الممكنة لهذا الحقل هي 255، والقيمة المبدئية الموصى بها هي 64. لمزيد من المعلومات، راجع قسم واجهة TCP/المستوى الأدنى من RFC9293.

في التشغيل العادي، يطبع ping قيمة TTL من الحزمة التي يستقبلها. عندما يستقبل نظام بعيد حزمة ping، يمكنه فعل أحد ثلاثة أشياء بحقل TTL في استجابته:

• عدم تغييره؛ هذا ما فعلته أنظمة Berkeley Unix قبل إصدار 4.3BSD Tahoe. في هذه الحالة، ستكون قيمة TTL في الحزمة المستقبلة 255 ناقص عدد الموجهات في مسار الرحلة ذهابًا وإيابًا.

• تعيينها إلى 255؛ هذا ما تفعله أنظمة Berkeley Unix الحالية. في هذه الحالة، ستكون قيمة TTL في الحزمة المستقبلة 255 ناقص عدد الموجهات في المسار من النظام البعيد إلى المضيف الذي يقوم ping.

• تعيينها إلى قيمة أخرى. تستخدم بعض الأجهزة نفس القيمة لحزم ICMP التي تستخدمها لحزم TCP، على سبيل المثال إما 30 أو 60. قد يستخدم البعض الآخر قيمًا عشوائية تمامًا.

العلل

• تتجاهل العديد من المضيفات والبوابات خيار RECORD_ROUTE.

• طول رأس IP الأقصى صغير جدًا بحيث لا يمكن لخيارات مثل RECORD_ROUTE أن تكون مفيدة تمامًا. ومع ذلك، لا يمكن فعل الكثير حيال هذا.

• لا يُوصى بإرسال ping الفيضاني بشكل عام، ويجب إجراء ping الفيضاني لعنوان البث فقط تحت ظروف خاضعة للرقابة الشديدة.

انظر أيضًا

ip(8), ss(8).

التاريخ

ظهر أمر ping في 4.3BSD.

الإصدار الموصوف هنا هو نسخته السليلة الخاصة بـ Linux.

اعتبارًا من الإصدار s20150815، لم يعد الملف الثنائي ping6 موجودًا. تم دمجه في ping. إنشاء رابط رمزي باسم ping6 يشير إلى ping سيؤدي إلى نفس الوظيفة كما في السابق.

الأمن

يتطلب ping صلاحية CAP_NET_RAW للتنفيذ 1) إذا استُخدم البرنامج لاستعلامات غير الصدى (انظر الخيار -N) أو عندما يُضبط حقل التعريف على 0 لطلب ECHO_REQUEST (انظر -e)، أو 2) إذا لم تدعم النواة مقابس بيانات ICMP، أو 3) إذا لم يُسمح للمستخدم بإنشاء مقبس صدى ICMP. قد يُستخدم البرنامج كجذر set-uid.

التوفر

ping جزء من حزمة iputils.

ترجمة

تُرجمت هذه الصفحة من الدليل بواسطة زايد السعيدي <zayed.alsaidi@gmail.com>

هذه الترجمة هي وثيقة مجانية؛ راجع رخصة جنو العامة الإصدار 3 أو ما بعده للاطلاع على شروط حقوق النشر. لا توجد أي ضمانات.

إذا وجدت أي أخطاء في ترجمة صفحة الدليل هذه، يرجى إرسال بريد إلكتروني إلى قائمة بريد المترجمين: kde-l10n-ar@kde.org.