গাইড

আপনার অ্যাপ থেকে ইমেইল কীভাবে পাঠাবেন (এবং ইনবক্সে পৌঁছানো নিশ্চিত করবেন)

আপনার অ্যাপ থেকে নির্ভরযোগ্যভাবে ইমেইল পাঠাতে নিজের মেইলবক্স নয়, বরং একটি ইমেইল সেন্ডিং প্রোভাইডার ব্যবহার করুন, নিজের ডোমেইনের একটি ঠিকানা থেকে পাঠান, এবং প্রোভাইডার যে DNS রেকর্ড দেয় তা যোগ করুন, যাতে SPF, DKIM ও DMARC সবগুলো পাস করে। ট্রানজ্যাকশনাল ইমেইল — পাসওয়ার্ড রিসেট, রসিদ, নিশ্চিতকরণ — মার্কেটিং ইমেইল থেকে আলাদা রাখুন, প্রতিটি শুধু তাদেরই পাঠান যারা তা আশা করছেন, এবং বাউন্স ও আনসাবস্ক্রাইব সামলান। আগে প্রমাণীকরণ ঠিক করুন; অ্যাপের ইমেইল স্প্যামে যাওয়ার সবচেয়ে সাধারণ কারণ এটিই।

ট্রানজ্যাকশনাল বনাম মার্কেটিং ইমেইল

কোডে এই দুই ধরনের ইমেইল একই রকম দেখালেও ইনবক্স প্রোভাইডার এবং আইন এদের সম্পূর্ণ আলাদাভাবে দেখে।

ট্রানজ্যাকশনালমার্কেটিং (বাল্ক)
কিসের কারণে পাঠানো হয়ব্যবহারকারীর কোনো কাজআপনার সময়সূচি বা ক্যাম্পেইন
উদাহরণসাইন-আপ নিশ্চিতকরণ, পাসওয়ার্ড রিসেট, ম্যাজিক লিংক, রসিদ, বুকিং রিমাইন্ডার, "কেউ উত্তর দিয়েছে"নিউজলেটার, পণ্যের ঘোষণা, প্রচারণা, পুনরায় যুক্ত করার বার্তা
প্রাপকএকবারে একজনএকসঙ্গে অনেকে
সম্মতিকাজটির মাধ্যমে ধরে নেওয়া হয়অনুমতি লাগে, সহজে আনসাবস্ক্রাইবের সুবিধা সহ
সময়সেকেন্ডের মধ্যে পৌঁছাতে হবেকয়েক মিনিট চলবে
কোথা থেকে পাঠাবেনআপনার অ্যাপ থেকে, API-র মাধ্যমেএকটি নিউজলেটার টুল বা প্রোভাইডারের ব্রডকাস্ট ফিচার

এদের আলাদা রাখুন। কোনো মার্কেটিং ক্যাম্পেইন স্প্যাম অভিযোগ পেলে একই স্ট্রিমের পাসওয়ার্ড রিসেটের ক্ষতি আপনি চাইবেন না। একটি সাধারণ পদ্ধতি হলো আলাদা সাবডোমেইন ব্যবহার করা — যেমন অ্যাকাউন্টের ইমেইলের জন্য mail.example.com এবং নিউজলেটারের জন্য news.example.com — এবং কিছু প্রোভাইডার দুটিকে নিজেরাই আলাদা করে রাখে। উদাহরণস্বরূপ Postmark ২০২৬ সালের সেপ্টেম্বর অনুযায়ী তাদের ট্রানজ্যাকশনাল ও ব্রডকাস্ট "মেসেজ স্ট্রিম" আলাদা সেন্ডিং অবকাঠামোতে চালানোর কথা বলে।

সঠিক প্রোভাইডার বাছাই

আপনার অ্যাপের নিজের সার্ভার থেকে সরাসরি ইমেইল পাঠানো উচিত নয়। সেন্ডিং প্রোভাইডাররা অবকাঠামো, IP সুনাম, পুনরায় চেষ্টা এবং বাউন্স প্রক্রিয়াকরণ সামলায়। পরিচিত কিছু বিকল্প হলো Postmark, Resend, SendGrid, Amazon SES ও Mailgun; প্রতিটিতে HTTP API ও SMTP অ্যাক্সেস আছে। দাম ও প্ল্যান বদলায়, তাই প্রতিটির নিজস্ব সাইটে গিয়ে তুলনা করুন।

যা তুলনা করবেন:

  • ফোকাস। কিছু প্রোভাইডার শুধু ট্রানজ্যাকশনাল ইমেইলে মনোযোগ দেয়; অন্যরা ট্রানজ্যাকশনাল ও মার্কেটিং দুটোই দেয়।
  • ডেভেলপার অভিজ্ঞতা। স্পষ্ট API, আপনার ভাষার অফিসিয়াল লাইব্রেরি, এবং কার্যকর লগ যা দেখায় প্রতিটি বার্তা পৌঁছেছে, বাউন্স হয়েছে নাকি স্প্যাম হিসেবে চিহ্নিত হয়েছে।
  • ওয়েবহুক বাউন্স, অভিযোগ ও ডেলিভারির জন্য, যাতে আপনার অ্যাপ সাড়া দিতে পারে।
  • টেমপ্লেট — প্রোভাইডারের কাছে সংরক্ষিত, বা আপনার নিজের কোডে। কোডে রাখলে সেগুলো ভার্সন করা ও পরীক্ষা করা যায়।
  • অঞ্চল ও ডেটা হ্যান্ডলিং, যদি ডেটা কোথায় প্রক্রিয়া হবে সে বিষয়ে আপনার নির্দিষ্ট প্রয়োজন থাকে।
  • আপনার পরিমাণে খরচ, বিনামূল্যের স্তর ছাড়িয়ে গেলে কী হয় তাসহ।

একটি তালিকায় নিউজলেটার পাঠানোর জন্য একটি আলাদা নিউজলেটার বা ইমেইল মার্কেটিং টুল প্রায়ই আপনার অ্যাপে ক্যাম্পেইন ফিচার বানানোর চেয়ে ভালো মানায়।

আপনার সেন্ডিং ডোমেইন সেট করুন

নিজের ডোমেইন থেকে পাঠান — hello@example.com, Gmail বা Outlook ঠিকানা নয়। কোনো তৃতীয় পক্ষের সার্ভিসের মাধ্যমে বিনামূল্যের মেইলবক্স ঠিকানা থেকে পাঠানো ইমেইল প্রমাণীকরণ যাচাইয়ে ব্যর্থ হয় এবং সম্ভবত ফিল্টার হয়ে যায়।

শুধু পাঠানোর জন্য একটি সাবডোমেইন ভাবতে পারেন। উদাহরণস্বরূপ Resend ২০২৬ সালের সেপ্টেম্বর অনুযায়ী সেন্ডিং সুনাম আলাদা রাখতে updates.example.com-এর মতো সাবডোমেইন থেকে পাঠানোর পরামর্শ দেয়। এতে ইমেইলের DNS রেকর্ডও আপনার মূল সাইটের রেকর্ড থেকে আলাদা থাকে।

প্রোভাইডার তারপর যেখানে আপনার ডোমেইনের DNS পরিচালিত হয় সেখানে যোগ করার জন্য DNS রেকর্ড দেবে। DNS যদি আপনার কাছে নতুন হয়, ডোমেইন ও DNS কীভাবে কাজ করে আগে রেকর্ডগুলো ব্যাখ্যা করে।

SPF

SPF (Sender Policy Framework) একটি TXT রেকর্ড, যেখানে তালিকাভুক্ত থাকে কোন সার্ভার আপনার ডোমেইনের হয়ে ইমেইল পাঠাতে পারে। গ্রহণকারী দেখে প্রেরক সার্ভারটি সেই তালিকায় আছে কি না।

  • একটি ডোমেইনের শুধু একটি SPF রেকর্ড থাকা উচিত। নতুন প্রোভাইডার যোগ করলে দ্বিতীয় রেকর্ড না বানিয়ে বিদ্যমানটির সঙ্গে মেশান।
  • মূল্যায়নের সময় SPF সর্বোচ্চ ১০টি DNS লুকআপের অনুমতি দেয়; include: এন্ট্রির দীর্ঘ চেইন এই সীমা ছাড়িয়ে ব্যর্থতা ঘটাতে পারে।
  • অনেক প্রোভাইডার যে রিটার্ন-পাথ সাবডোমেইন তৈরি করতে বলে, তাতে SPF সেট করে, তাই আপনার মূল SPF রেকর্ডে হাত না-ও দিতে হতে পারে।

DKIM

DKIM (DomainKeys Identified Mail) প্রতিটি বার্তায় একটি ক্রিপ্টোগ্রাফিক স্বাক্ষর যোগ করে। প্রোভাইডার একটি প্রাইভেট কী দিয়ে স্বাক্ষর করে; আপনি মিলে যাওয়া পাবলিক কী একটি DNS রেকর্ড (প্রোভাইডার অনুযায়ী TXT বা CNAME) হিসেবে প্রকাশ করেন। গ্রহণকারী স্বাক্ষর যাচাই করে নিশ্চিত হয় যে বার্তাটি অনুমোদিত প্রেরক থেকে এসেছে এবং পথে বদলানো হয়নি।

আপনার প্রোভাইডারের "verify domain" ধাপটি মূলত DKIM নিয়েই। এটি এড়িয়ে যাবেন না।

DMARC

DMARC বাকি দুটিকে একসঙ্গে যুক্ত করে। এটি _dmarc.yourdomain.com-এ একটি TXT রেকর্ড, যা গ্রহণকারীকে বলে:

  • অ্যালাইনমেন্ট: দৃশ্যমান From ঠিকানার ডোমেইনটি অবশ্যই SPF বা DKIM পাস করা ডোমেইনের সঙ্গে মিলতে হবে।
  • নীতি: ব্যর্থ বার্তার সঙ্গে কী করা হবে — p=none (শুধু রিপোর্ট), p=quarantine (সন্দেহজনক হিসেবে ধরা, প্রায়ই স্প্যাম) বা p=reject।
  • রিপোর্ট: সামগ্রিক রিপোর্ট কোথায় পাঠানো হবে (rua=), যাতে আপনি দেখতে পারেন কে আপনার ডোমেইনের নামে পাঠাচ্ছে।

একটি যুক্তিসঙ্গত পথ হলো রিপোর্ট পাওয়ার একটি ঠিকানাসহ p=none দিয়ে শুরু করা, নিশ্চিত হওয়া যে আপনার বৈধ মেইল পাস করছে, তারপর quarantine এবং শেষে reject-এ যাওয়া। কঠোর নীতি অন্যদের জন্য আপনার ডোমেইন জাল করাও অনেক কঠিন করে দেয়।

Gmail কী দাবি করে

২০২৬ সালের সেপ্টেম্বর অনুযায়ী Google-এর প্রেরক নির্দেশিকা বলে:

  • সব প্রেরককে ব্যক্তিগত Gmail অ্যাকাউন্টে পাঠাতে SPF বা DKIM, প্রেরক সার্ভারের বৈধ ফরওয়ার্ড ও রিভার্স DNS, TLS, এবং Postmaster Tools-এ ০.৩%-এর নিচে স্প্যাম রেট লাগবে।
  • বাল্ক প্রেরকদের (Gmail-এ দিনে ৫,০০০-এর বেশি বার্তা) SPF এবং DKIM, একটি DMARC রেকর্ড (p=none নীতি অনুমোদিত), From-ডোমেইন অ্যালাইনমেন্ট, এবং মার্কেটিং ও সাবস্ক্রাইব করা বার্তায় এক-ক্লিকে আনসাবস্ক্রাইব সহ একটি দৃশ্যমান আনসাবস্ক্রাইব লিংক লাগবে।

সার্ভার-সাইডের অংশগুলো আপনার প্রোভাইডার সামলায়। DNS রেকর্ড ও আনসাবস্ক্রাইব হ্যান্ডলিং আপনার দায়িত্ব। আপনি দিনে ৫,০০০-এর কাছেও না গেলেও বাল্ক নিয়মগুলো মেনে চলাই সবচেয়ে সহজ নিরাপদ পথ।

অ্যাপের ভেতরে ইমেইল পাঠানো বসান

ডোমেইন যাচাই হয়ে গেলে:

  1. API কী সংরক্ষণ করুন একটি সার্ভার-সাইড সিক্রেট হিসেবে — কখনোই ফ্রন্ট-এন্ড কোডে নয়। দেখুন এনভায়রনমেন্ট ভেরিয়েবল ও সিক্রেট কী।
  2. সার্ভার থেকে পাঠান, ইমেইল ট্রিগারকারী কাজটি সফল হওয়ার পরে।
  3. ইমেইলের জন্য ব্যবহারকারীকে অপেক্ষা করাবেন না। সবচেয়ে সরল অ্যাপের বাইরে যেকোনো কিছুর জন্য পাঠানো কিউতে রাখুন এবং অস্থায়ী ব্যর্থতায় আবার চেষ্টা করুন, যাতে প্রোভাইডারের ধীর সাড়া সাইন-আপ ধীর করে না দেয়।
  4. ফলাফল লগ করুন — প্রোভাইডারের মেসেজ ID ও স্ট্যাটাস — তবে কী বা ব্যক্তিগত ডেটাসহ পূর্ণ বার্তার মূল অংশ লগ করবেন না।
  5. বাউন্স ও অভিযোগের জন্য ওয়েবহুক সামলান: যে ঠিকানায় হার্ড বাউন্স হয় বা যা আপনাকে স্প্যাম হিসেবে চিহ্নিত করে, সেখানে পাঠানো বন্ধ করুন।

মূল বিষয়গুলো ঢাকে এমন একটি প্রম্পট:

[PROVIDER] দিয়ে ট্রানজ্যাকশনাল ইমেইল পাঠাও, সার্ভার সিক্রেট [ENV_NAME] ব্যবহার করে, "Acme hello@mail.acme.com" ঠিকানা থেকে। সাইন-আপের পর একটি স্বাগত ইমেইল, এবং বুকিং সংরক্ষণের পর একটি বুকিং নিশ্চিতকরণ পাঠাও। টেমপ্লেট কোডে রাখো, HTML-এর পাশে একটি প্লেইন-টেক্সট সংস্করণসহ। পাঠানো কিউতে রাখো এবং অস্থায়ী ব্যর্থতায় সর্বোচ্চ তিনবার আবার চেষ্টা করো। প্রোভাইডারের ত্রুটিসহ ব্যর্থতা লগ করো, কিন্তু API কী কখনো নয়। একটি ওয়েবহুক এন্ডপয়েন্ট যোগ করো যা হার্ড বাউন্স ও অভিযোগে ঠিকানাকে অপ্রদেয় হিসেবে চিহ্নিত করে, এবং ভবিষ্যতে সেসব ঠিকানা বাদ দাও।

ভেরিফিকেশন লিংক, ম্যাজিক লিংক ও পাসওয়ার্ড রিসেটের মতো অ্যাকাউন্ট ইমেইল লগইনের অংশ। আপনার অ্যাপে লগইন কীভাবে যুক্ত করবেন দেখায় এই প্রবাহগুলো কীভাবে একসঙ্গে কাজ করে; এই লিংকগুলো একবারই ব্যবহারযোগ্য ও স্বল্প-মেয়াদী করুন।

ডেলিভারেবিলিটির অভ্যাস

প্রমাণীকরণ আপনাকে বিবেচনায় আনায়। আচরণ আপনাকে ইনবক্সে রাখে।

  • শুধু লোকজন যা আশা করে তাই পাঠান। নিশ্চিত সাইন-আপ, মার্কেটিংয়ের জন্য স্পষ্ট অপ্ট-ইন, কেনা তালিকা নয়।
  • কঠোরভাবে ট্রানজ্যাকশনাল নয় এমন সব কিছুতে আনসাবস্ক্রাইব সহজ করুন, এবং সঙ্গে সঙ্গে তা মেনে চলুন।
  • নতুন ডোমেইন ধীরে ধীরে চালু করুন। একটি সম্পূর্ণ নতুন ডোমেইন প্রথম দিনেই হাজারো বার্তা পাঠালে সন্দেহজনক দেখায়। আপনার ট্রানজ্যাকশনাল মেইল দিয়ে শুরু করুন এবং পরিমাণ ধীরে ধীরে বাড়ান।
  • তালিকা পরিষ্কার রাখুন। হার্ড বাউন্স সঙ্গে সঙ্গে সরান, এবং দীর্ঘদিন কিছু না খোলা মানুষদের সরানোর কথা ভাবুন।
  • মানুষের মতো লিখুন। একটি স্পষ্ট বিষয়, পরিচিত প্রেরকের নাম, একটি প্লেইন-টেক্সট অংশ, কম ছবি এবং নিজের ডোমেইনের লিংক। লিংক শর্টেনার এড়িয়ে চলুন।
  • পর্যবেক্ষণ করুন। আপনার ডোমেইন Google Postmaster Tools-এ যোগ করুন এবং মাঝে মাঝে DMARC রিপোর্ট পড়ুন।
  • একটি আসল রিপ্লাই-টু ঠিকানা ব্যবহার করুন যা কেউ পড়ে। উত্তর ভালো সংকেত, এবং কার্যকর মতামতও।

কাউকে স্প্যাম না করে পরীক্ষা করা

  • যেখানে আছে সেখানে আপনার প্রোভাইডারের টেস্ট মোড বা স্যান্ডবক্স ব্যবহার করুন, অথবা আপনার নিজের মালিকানাধীন ঠিকানায় পাঠান।
  • ডেভেলপমেন্টে আসল ব্যবহারকারীর বদলে একটি ক্যাচ-অল টেস্ট ইনবক্স-এ পাঠান; বাস্তবের মতো দেখতে ঠিকানায় ভরা একটি সিড করা ডাটাবেস অপরিচিতদের ভুলবশত ইমেইল করার সহজ উপায়।
  • কয়েকটি ক্লায়েন্টে প্রতিটি টেমপ্লেট দেখুন — ওয়েবে Gmail, ফোনের মেইল অ্যাপ, Outlook — এবং ডার্ক মোডেও।
  • একটি টেস্ট ইমেইলের মেসেজ হেডার দেখুন: সেখানে দেখা যায় SPF, DKIM ও DMARC পাস করেছে কি না।

আইনের মূল বিষয়

নিয়ম দেশভেদে আলাদা। মোটামুটিভাবে, মার্কেটিং ইমেইলের জন্য অনেক জায়গায় সম্মতি লাগে, প্রেরককে চিহ্নিত করতে হয়, এবং একটি কার্যকর আনসাবস্ক্রাইব দিতে হয়; ট্রানজ্যাকশনাল ইমেইলের সঙ্গে আচরণ আলাদা, কিন্তু একে মার্কেটিং ঢোকানোর পথ হিসেবে ব্যবহার করা উচিত নয়। আপনি যদি ওয়েটলিস্ট পেজ থেকে ঠিকানা সংগ্রহ করেন, তাহলে বলুন কী পাঠাবেন ও সংরক্ষণ করবেন এবং প্রতিজন কখন, কীভাবে সাইন-আপ করেছে। সন্দেহ থাকলে আপনার ব্যবহারকারীরা যেখানে আছেন সেখানকার নিয়ম যাচাই করুন।

ইমেইল চেকলিস্ট

  • সেন্ডিং প্রোভাইডার বাছাই করা হয়েছে; API কী একটি সার্ভার সিক্রেট হিসেবে সংরক্ষিত
  • আপনার নিজের ডোমেইন বা সাবডোমেইন থেকে পাঠানো হচ্ছে, বিনামূল্যের মেইলবক্স থেকে নয়
  • SPF, DKIM ও DMARC রেকর্ড যোগ করা হয়েছে এবং পাস করছে
  • ট্রানজ্যাকশনাল ও মার্কেটিং মেইল আলাদা করা হয়েছে
  • পাঠানো কিউতে রাখা ও আবার চেষ্টা করা হয়; ফলাফল লগ করা হয়
  • বাউন্স ও অভিযোগের ওয়েবহুক সামলানো হয়েছে
  • ট্রানজ্যাকশনাল নয় এমন মেইলে আনসাবস্ক্রাইব আছে এবং তা সঙ্গে সঙ্গে মানা হয়
  • একাধিক ক্লায়েন্টে টেমপ্লেট পরীক্ষা করা হয়েছে; টেস্ট মেইল কখনো আসল ব্যবহারকারীর কাছে যায় না

Mythex অ্যাপ থেকে ইমেইল পাঠানো

Mythex আপনার বানানো অ্যাপের জন্য কোনো অন্তর্নির্মিত ইমেইল সেন্ডিং সার্ভিস অন্তর্ভুক্ত করে না, তাই Resend, SendGrid বা Postmark-এর মতো একটি প্রোভাইডার আপনাকে আনতে হবে। এর API কী প্রজেক্টের একটি সিক্রেট হিসেবে সংরক্ষণ করুন — চ্যাটে একটি সিক্রেটস কার্ডের মাধ্যমে এজেন্ট এটি চাইতে পারে — এবং সাধারণ ভাষায় যে ইমেইলগুলো দরকার তা চান। একটি স্টার্টার প্রম্পট পাবেন আপনার অ্যাপ থেকে ইমেইল পাঠান-এ। আপনি যদি Pro-তে Mythex-এর মাধ্যমে ডোমেইন কিনে থাকেন, তাহলে ডোমেইনের DNS সেটিংসে প্রোভাইডারের TXT ও CNAME রেকর্ড যোগ করতে পারেন; দেখুন কাস্টম ডোমেইন।

প্রশ্নোত্তর

ট্রানজ্যাকশনাল ও মার্কেটিং ইমেইলের পার্থক্য কী?

ট্রানজ্যাকশনাল ইমেইল ব্যবহারকারীর কোনো কাজের কারণে পাঠানো হয় এবং তা প্রত্যাশিতও — যেমন পাসওয়ার্ড রিসেট, রসিদ বা বুকিং নিশ্চিতকরণ। মার্কেটিং ইমেইল আপনার নিজের সময়সূচি অনুযায়ী অনেক মানুষের কাছে পাঠানো হয়, যেমন নিউজলেটার ও ঘোষণা। এদের সম্মতির নিয়ম আলাদা, তাই এগুলো আলাদা স্ট্রিম বা সাবডোমেইন থেকে পাঠানোই ভালো।

আমার অ্যাপের ইমেইল স্প্যাম ফোল্ডারে যাচ্ছে কেন?

সাধারণ কারণগুলো হলো: পাঠানোর ডোমেইনে SPF, DKIM ও DMARC সেট না করা, তৃতীয় পক্ষের সার্ভিসের মাধ্যমে Gmail-এর মতো বিনামূল্যের ঠিকানা থেকে পাঠানো, একটি সম্পূর্ণ নতুন ডোমেইন যার কোনো সুনাম নেই, অথবা স্প্যামের মতো দেখতে কনটেন্ট বা লিংক। আগে প্রমাণীকরণ ঠিক করুন, তারপর কনটেন্ট ও পরিমাণ দেখুন।

আমার Gmail অ্যাকাউন্ট থেকে কি অ্যাপের ইমেইল পাঠানো যায়?

হাতেগোনা কয়েকটি ব্যক্তিগত টেস্ট বার্তার জন্য হয়তো, কিন্তু আসল অ্যাপের জন্য নয়। নিজের ডোমেইনসহ একটি ইমেইল সেন্ডিং প্রোভাইডার ব্যবহার করুন, সে যে DNS রেকর্ড দেয় তা সেট করুন, এবং সেই ডোমেইনের একটি ঠিকানা থেকে পাঠান।

আমার কি DMARC লাগবে?

বাস্তবে, হ্যাঁ। ২০২৬ সালের সেপ্টেম্বর পর্যন্ত, Google Gmail ঠিকানায় দিনে ৫,০০০-এর বেশি বার্তা পাঠানো প্রত্যেকের জন্য DMARC বাধ্যতামূলক করেছে, এবং একটি DMARC রেকর্ড আপনার ডোমেইনকে জাল করে ব্যবহার হওয়া থেকেও রক্ষা করে। রিপোর্ট দেখার সময় p=none নীতি দিয়ে শুরু করা ঠিক আছে।

Mythex · Pricing · AI দিয়ে যা খুশি বানান · ওয়েবসাইট ও অ্যাপের টেমপ্লেট · Mythex-এর তুলনা · AI অ্যাপ তৈরির শব্দকোষ · AI অ্যাপ তৈরির বিনামূল্যের টুল · English

English አማርኛ العربية Български Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)