تمام، ده البرومبت كامل بعد دمج Multilingual Ads + تحسين شكل عمليات الشراء في برومبت واحد، مع الحفاظ على كل المتطلبات السابقة:

TASK: Multilingual Advertisements System + Enhanced Purchase UI

Implement the following features in the existing Vexora project.

IMPORTANT:
This is an enhancement to the existing system. Do NOT create a second Ads system, duplicate existing functionality, or modify unrelated features.

Before making any changes:

PHASE 1 — ANALYSIS + PLAN ONLY

First inspect the existing implementation and provide:

1. Current Ads architecture and database schema.

2. Existing Ad model and all related models/components/API routes.

3. Current ad creation/editing/admin UI.

4. Current public ad rendering system and ad slots.

5. Current storefront language/i18n architecture.

6. Current purchase/cart/checkout UI and the components responsible for purchase actions.

7. Current icon library/components already available in the project.

8. Exact files that would need to change.

9. Proposed database migration/schema changes.

10. Proposed localized-ad fallback logic.

11. Proposed purchase UI improvements.

12. Compatibility/security considerations.

13. Test plan.

DO NOT modify files during Phase 1.

After the analysis and plan, STOP and wait for my explicit approval.

FEATURE 1 — MULTILINGUAL ADVERTISEMENTS

After approval, implement multilingual advertisements using the existing Ads system.

1. Supported storefront languages

The storefront currently supports:

• English

• Arabic

• Russian

• Simplified Chinese

The Ads system must support localized ad content for these storefront languages.

The customer’s CURRENT STOREFRONT LANGUAGE must determine which advertisement version is displayed.

Do NOT use the Admin Panel language to determine the public advertisement language.

2. One Ad → Multiple Language Versions

Do NOT create a separate Ad entity for every language.

One existing Ad should be able to contain multiple localized versions.

For example:

Ad

├── English version

├── Arabic version

├── Russian version

└── Chinese version

Languages should be optional.

An admin does NOT have to provide every language version.

3. IMAGE / BANNER ADS

For IMAGE/BANNER advertisements, allow the administrator to upload a different image for each language.

Example:

English → banner-en.webp

Arabic → banner-ar.webp

Russian → banner-ru.webp

Chinese → banner-zh.webp

The storefront should automatically display the appropriate image according to the current storefront language.

Use the existing secure media/upload system.

Do not introduce unsafe SVG/script-based uploads.

Validate:

• MIME type

• File extension

• File size

• Image validity

Preserve existing media security protections.

4. TEXT ADS

For TEXT advertisements, allow localized content.

Each language version may have its own:

• Title

• Description/body text

• Optional CTA text

• Optional destination/link URL if supported by the existing Ads system

Example:

English:

Title: Special Offer

Text: Get your product today.

Arabic:

Title: عرض خاص

Text: احصل على منتجك الآن.

Russian:

Title: Специальное предложение

Text: Получите товар сегодня.

Chinese:

Title: 特别优惠

Text: 立即获取您的产品。

Do not hardcode these examples.

5. IFRAME ADS

For IFRAME advertisements:

Allow a localized URL/source per language when required.

For example:

English → HTTPS URL A

Arabic → HTTPS URL B

Russian → HTTPS URL C

Chinese → HTTPS URL D

Also support a universal/default iframe source when the same URL should be used for every language.

Preserve all existing iframe security requirements:

• HTTPS only where currently required

• sandboxing

• CSP

• existing validation

• no arbitrary JavaScript/HTML injection

Do not weaken existing security protections.

6. Database Architecture

First inspect the existing Ads schema.

Prefer extending the existing system with a localized relation/table rather than duplicating the entire Ad record.

A possible structure is:

Ad

├── id

├── type

├── slot

├── status

├── scheduling fields

├── impressions

├── clicks

└── localized versions

AdLocalization

├── id

├── adId

├── locale

├── title

├── text

├── image/media reference

├── iframe URL

├── optional link URL

├── createdAt

└── updatedAt

Use the architecture that best matches the existing project.

Enforce uniqueness for:

(adId, locale)

Do not create duplicate Ads systems.

Preserve all existing:

• impressions

• clicks

• scheduling

• slots

• active/inactive status

• targeting

• existing relationships

• analytics

If practical, analytics may record the locale of an impression/click, but this must not break existing analytics.

7. EXISTING ADS BACKWARD COMPATIBILITY

Existing advertisements must continue working.

Do NOT require the administrator to recreate all existing ads.

Migrate or map existing ad content into an appropriate:

Universal / Default

or existing/default language representation.

Existing ads must continue displaying correctly after the migration.

8. ADMIN ADS UI

Extend the existing Ads administration interface.

Do NOT create a second Ads management system.

When creating/editing an advertisement, provide clear language sections/tabs such as:

English

العربية

Русский

简体中文

For IMAGE ads:

English Banner → Upload

Arabic Banner → Upload

Russian Banner → Upload

Chinese Banner → Upload

For TEXT ads:

English → Title + Text

Arabic → Title + Text

Russian → Title + Text

Chinese → Title + Text

For IFRAME ads:

English → URL

Arabic → URL

Russian → URL

Chinese → URL

Universal → URL

Clearly show which language versions are configured.

If a language version is missing, show a non-blocking warning explaining that the ad will use the fallback version.

9. AD PREVIEW

Add/use an Admin preview system for advertisements.

The preview should include a language selector:

English

Arabic

Russian

Chinese

The preview must use the SAME public rendering and fallback logic as the storefront.

Do not create separate preview logic that behaves differently from production.

10. STOREFRONT LANGUAGE SWITCHING

The ad must react to the storefront’s current language.

Example:

User selects English

→ English ad version appears

User switches to Arabic

→ Arabic ad version appears

User switches to Russian

→ Russian ad version appears

User switches to Chinese

→ Chinese ad version appears

This should work using the existing storefront locale/i18n state.

Do not require:

• logout

• restart

• manual database changes

If the current architecture requires a page/navigation refresh to apply locale changes, preserve the existing architecture while ensuring the correct localized ad is rendered after the language change.

11. FALLBACK LOGIC

Implement a clear fallback hierarchy.

Recommended order:

1. Current storefront locale

2. Universal / Default version

3. English

4. No advertisement

Example:

If the user is using Arabic but the ad has no Arabic version:

Arabic

↓

Universal/Default

↓

English

↓

No ad

Do not display a random language version.

The fallback must work consistently across:

• image ads

• text ads

• iframe ads

12. RTL / LTR

Arabic must use RTL correctly.

English, Russian, and Simplified Chinese should use LTR.

For image banners:

• Do not modify the image itself.

• Do not automatically mirror the image.

• Only adapt surrounding UI/layout where appropriate.

13. PUBLIC AD RENDERING

Use the existing public Ads rendering architecture.

The rendering flow should effectively be:

Current storefront locale

↓

Find active Ad

↓

Find localized version

↓

Apply fallback

↓

Render existing ad type

↓

Apply existing impression/click tracking

Preserve all existing ad slot behavior.

Do not break Ads on existing public pages.

FEATURE 2 — ENHANCED PURCHASE / SHOPPING UI

Also improve the existing purchase-related UI so that buying products is visually clearer, more modern, and more distinctive.

IMPORTANT:

This is a UI/UX enhancement only.

DO NOT change:

• payment logic

• checkout logic

• order creation

• cart behavior

• product pricing

• discounts

• stock/availability

• payment methods

• delivery logic

• order validation

• purchase APIs

The existing functionality must remain exactly the same.

14. PURCHASE ACTION DESIGN

Locate the existing purchase actions throughout the storefront.

Examples may include:

• Buy Now

• Add to Cart

• Purchase

• Checkout-related product actions

• Product purchase buttons

Improve their visual presentation while preserving their existing behavior.

Use a clear shopping-related icon next to the purchase action.

Suitable examples:

• Shopping cart

• Shopping bag

• Cart + purchase/check indicator

Use the project’s existing icon library if one already exists.

Do NOT install a new icon dependency unless absolutely necessary.

15. PURCHASE BUTTON VISUAL DESIGN

Make purchase actions visually distinctive and polished while matching the existing Vexora design system.

Use the existing visual language such as:

• gradients

• rounded corners

• borders

• typography

• subtle shadows

• hover effects

• active states

The purchase action should clearly stand out from secondary actions without becoming oversized or distracting.

Do not copy WormGPT branding, logos, assets, or proprietary UI.

Keep the design consistent with the existing Vexora aesthetic.

16. ICON + TEXT

The purchase action should NOT rely on the icon alone.

For example:

[🛒] Buy Now

or the equivalent using the project’s icon component.

The exact icon should come from the existing icon system where possible.

The icon must be:

• properly aligned

• appropriately sized

• visually balanced with the text

• responsive

• accessible

17. MULTILINGUAL PURCHASE UI

The improved purchase UI must work correctly with:

English

Arabic

Russian

Simplified Chinese

Examples:

English → [cart icon] Buy Now

Arabic → [cart icon] شراء الآن

Russian → [cart icon] Купить сейчас

Chinese → [cart icon] 立即购买

Use the project’s existing translations/i18n system.

Do NOT hardcode new UI strings.

18. RTL PURCHASE LAYOUT

For Arabic:

• Correctly support RTL.

• Correct spacing between icon and text.

• Correct alignment.

• Do not incorrectly mirror the shopping icon if the icon itself is not direction-dependent.

For English/Russian/Chinese:

• Use LTR layout.

19. INTERACTION STATES

Add polished but subtle:

• Hover

• Focus

• Active/pressed

• Disabled/loading

states where appropriate.

Do not introduce excessive animation.

Keep animations performant and accessible.

Respect reduced-motion preferences if the existing project supports them.

20. ACCESSIBILITY

Purchase actions must remain accessible.

Ensure:

• Keyboard navigation works.

• Focus state is visible.

• Buttons have accessible names.

• The icon is not the only indication of the action.

• Do not rely only on color.

• Screen readers can understand the purchase action.

21. RESPONSIVE DESIGN

The improved purchase UI must work correctly on:

• Mobile

• Tablet

• Desktop

Do not allow:

• text overflow

• broken button layouts

• icon overlap

• RTL/LTR alignment issues

• buttons becoming unusably small

22. CONSISTENCY

If there are multiple purchase entry points, make their visual language consistent while respecting the existing layout of each page.

Reuse existing components wherever possible.

Do not create unnecessary duplicate purchase components.

23. STRICT SCOPE PROTECTION

Do NOT modify unrelated systems.

In particular, do NOT change:

• Telegram Bot functionality

• Telegram delivery

• Telegram Inline Mode

• Telegram Inline Keyboard

• Admin language system

• Maintenance Mode

• Admin authentication

• Admin authorization

• /BRAYA admin route

• NavApp system

• Payment processing

• Order processing

• Product delivery

• Existing Ads analytics logic unless required for localized ads

• Existing product/business logic

The two requested features in this task are:

1. Multilingual Ads

2. Enhanced Purchase UI

Everything else must remain unchanged.

24. SECURITY

Preserve all existing security protections.

For Ads:

• No arbitrary HTML/JavaScript.

• Secure iframe handling.

• Existing CSP protections.

• Secure media uploads.

• Proper authorization for Admin Ads management.

• Validate localized URLs.

• Validate uploaded media.

For Purchase UI:

• Do not expose sensitive payment/order information.

• Do not move business logic into client-side code.

• Do not weaken existing server-side validation.

25. TESTING

After implementation run:

npx tsc --noEmit

npx prisma validate

npx next build

Also test:

Ads

• Existing ads still render.

• New multilingual image ad.

• New multilingual text ad.

• New multilingual iframe ad.

• English version.

• Arabic version.

• Russian version.

• Chinese version.

• Missing-language fallback.

• Universal/default fallback.

• English fallback.

• No-version behavior.

• Storefront language switching.

• Admin preview.

• Ad scheduling.

• Ad slots.

• Impression tracking.

• Click tracking.

• Existing Ads functionality.

Purchase UI

Test:

• Product purchase button.

• Add to Cart if present.

• Buy Now if present.

• Desktop.

• Mobile.

• English.

• Arabic/RTL.

• Russian.

• Chinese.

• Hover.

• Focus.

• Active.

• Disabled/loading states where applicable.

• Actual purchase flow remains unchanged.

Do not report tests as passing unless they were actually executed.

26. FINAL REPORT

After implementation provide a concise but complete report containing:

1. What changed.

2. Ads architecture.

3. Database/schema changes.

4. Migration details.

5. Localized ad storage.

6. Image/banner localization.

7. Text localization.

8. IFRAME localization.

9. Fallback hierarchy.

10. Storefront locale integration.

11. Admin Ads UI changes.

12. Purchase UI changes.

13. Icon/component used.

14. Responsive/RTL/LTR handling.

15. Backward compatibility.

16. Security considerations.

17. Exact files changed.

18. Tests executed.

19. Exact test/build results.

20. Any limitations or remaining issues.

IMPORTANT:
Do not claim “100% bug-free”.

Report the actual validation results and any remaining limitations honestly.