Fix and improve the existing Vexora project with the following THREE requirements:
Fix the missing Inline Keyboard buttons on product posts published by the Telegram bot into the configured Telegram group/channel.
Fix Maintenance Mode so “Admin Login” / “دخول المسؤول” is NOT visible to normal public visitors while Maintenance Mode is enabled.
Add a fully independent Admin Panel language system with English, Arabic, Russian, and Simplified Chinese, allowing the administrator to switch the Admin Panel language at any time.
IMPORTANT:
Do NOT redesign or replace the Telegram bot.
Do NOT create a second Telegram bot.
Do NOT create a second i18n/translation system.
Do NOT modify unrelated storefront, checkout, payment, authentication, products, reviews, ads, theme, or database functionality unless strictly required.
Reuse the existing architecture.
Use minimal-diff changes.
Preserve all existing authentication, authorization, webhook, payment, and security protections.
━━━━━━━━━━━━━━━━━━━━
1. TELEGRAM — ANALYZE EXISTING IMPLEMENTATION
━━━━━━━━━━━━━━━━━━━━
Before changing code, inspect the existing Telegram product publishing implementation.
Find exactly where a new product is published to the Telegram group/channel.
Identify:
Telegram API method being used.
Whether it uses sendMessage, sendPhoto, sendMediaGroup, or another method.
How the product caption/text is generated.
How the product URL is generated.
Whether reply_markup is currently being sent.
Whether an Inline Keyboard is generated anywhere.
Whether the keyboard is attached to the wrong Telegram API request.
Whether there are separate publishing paths for products with and without images.
Whether the Telegram API response/error is checked.
Whether the configured group/channel chat ID is correct.
Whether the bot has the required permissions.
IMPORTANT:
Telegram Inline Mode and Telegram Inline Keyboard are different features.
The required functionality is an Inline Keyboard displayed directly underneath the published product post.
━━━━━━━━━━━━━━━━━━━━
2. REQUIRED TELEGRAM PRODUCT BUTTON
━━━━━━━━━━━━━━━━━━━━
When a new product is published to the Telegram group/channel, include an Inline Keyboard.
At minimum:
🛒 Buy Now
The button must open the correct Vexora product page.
Use the existing product slug/URL system.
Do NOT hardcode the domain.
Use the existing configured production/base URL.
━━━━━━━━━━━━━━━━━━━━
3. PRESERVE EXISTING TELEGRAM BUTTONS
━━━━━━━━━━━━━━━━━━━━
If existing product buttons already exist, preserve them.
Examples:
🛒 Buy Now
👁 View Product
💬 Contact
Do not create a duplicate button system.
Repair the existing implementation if one already exists.
━━━━━━━━━━━━━━━━━━━━
4. INLINE KEYBOARD IMPLEMENTATION
━━━━━━━━━━━━━━━━━━━━
Use Telegram Bot API reply_markup.
The request should conceptually contain:
reply_markup: {
inline_keyboard: [
[
{
text: “…”,
url: “…”
}
]
]
}
The keyboard must be part of the same Telegram API request that sends the product post.
Do NOT:
Put the keyboard inside the message text/caption.
Use Reply Keyboard.
Use Inline Mode as a replacement.
Send a second unrelated message just to display buttons.
━━━━━━━━━━━━━━━━━━━━
5. PRODUCTS WITH IMAGES
━━━━━━━━━━━━━━━━━━━━
If products with images use sendPhoto, attach the Inline Keyboard to the SAME sendPhoto request.
Conceptually:
sendPhoto({
chat_id,
photo,
caption,
parse_mode,
reply_markup
})
Do not send the image first and then attach the keyboard to another unrelated request.
━━━━━━━━━━━━━━━━━━━━
6. PRODUCTS WITHOUT IMAGES
━━━━━━━━━━━━━━━━━━━━
If products without images use sendMessage, attach the Inline Keyboard to the sendMessage request.
Conceptually:
sendMessage({
chat_id,
text,
parse_mode,
reply_markup
})
Both paths must support Inline Keyboard buttons.
━━━━━━━━━━━━━━━━━━━━
7. TELEGRAM URL SAFETY
━━━━━━━━━━━━━━━━━━━━
Generate the product URL server-side from the actual product.
Do not trust a URL supplied by the browser.
Only use the configured Vexora storefront domain/base URL.
Do not allow arbitrary external URLs to be injected into Telegram product buttons.
━━━━━━━━━━━━━━━━━━━━
8. TELEGRAM API ERROR HANDLING
━━━━━━━━━━━━━━━━━━━━
Check the actual Telegram API response.
Do not report successful publishing if Telegram rejected the request.
Safely handle:
Invalid reply_markup
Invalid URL
Invalid chat ID
Bot permissions
Group/channel permissions
Telegram API errors
Never expose:
Bot Token
Webhook secret
Internal credentials
Stack traces
━━━━━━━━━━━━━━━━━━━━
9. DO NOT MODIFY BOTFATHER INLINE MODE
━━━━━━━━━━━━━━━━━━━━
The Telegram Bot’s Inline Mode has already been enabled.
Do NOT change or replace this.
Inline Mode is unrelated to the required Inline Keyboard.
The required feature is reply_markup.inline_keyboard.
━━━━━━━━━━━━━━━━━━━━
10. MAINTENANCE MODE — HIDE ADMIN LOGIN
━━━━━━━━━━━━━━━━━━━━
When Maintenance Mode is ENABLED:
Normal public visitors must NOT see:
“Admin Login”
“دخول المسؤول”
Any equivalent visible admin-entry link/button.
This applies to:
Desktop
Mobile
Header
Footer
Navigation
Maintenance page
Any public storefront component shown during Maintenance Mode
Do NOT merely hide it with CSS if the component can safely be excluded from rendering.
The admin login/protected admin route must continue to work for authorized administrators.
IMPORTANT:
Removing the visible link must NOT remove or weaken admin access.
Do NOT:
Disable admin authentication.
Remove admin authorization.
Create a new admin login system.
Expose the admin panel publicly.
Add a visible admin URL to the maintenance page.
━━━━━━━━━━━━━━━━━━━━
11. MAINTENANCE MODE SECURITY
━━━━━━━━━━━━━━━━━━━━
When Maintenance Mode is active:
Normal visitors:
See the maintenance page.
Cannot access the normal storefront.
Authorized administrators:
Can still authenticate through the existing protected admin mechanism.
Can still access /BRAYA.
Keep all existing:
Authentication
Authorization
Sessions
Middleware
Route protection
Security checks
unchanged unless strictly necessary.
━━━━━━━━━━━━━━━━━━━━
12. ADMIN PANEL LANGUAGE SYSTEM
━━━━━━━━━━━━━━━━━━━━
Add a complete language selector to the existing /BRAYA Admin Panel.
The Admin Panel must support exactly these four languages:
English
العربية
Русский
简体中文
Chinese must be Simplified Chinese.
The administrator must be able to switch the Admin Panel language whenever they want.
For example:
English → 简体中文
or:
简体中文 → العربية
or:
العربية → Русский
or:
Русский → English
The change should happen immediately or through an automatic page refresh/navigation if required by the existing architecture.
The administrator must NOT need to:
Edit code.
Edit environment variables.
Restart the server.
Log out and log back in.
━━━━━━━━━━━━━━━━━━━━
13. ADMIN LANGUAGE SELECTOR UI
━━━━━━━━━━━━━━━━━━━━
Add a visible Language Selector inside /BRAYA.
Example:
Language
English
العربية
Русский
简体中文
Clearly indicate the currently selected language.
Do not rely only on flags.
The selector must work on:
Desktop
Mobile/tablet Admin UI
Place it in an appropriate existing Admin location such as:
Header
Profile menu
Settings
Admin preferences
Prefer the existing Admin UI design instead of creating an unrelated component.
━━━━━━━━━━━━━━━━━━━━
14. ADMIN LANGUAGE INDEPENDENCE
━━━━━━━━━━━━━━━━━━━━
This is CRITICAL.
The Admin Panel language and storefront language must be completely independent.
Example:
Storefront:
Chinese
Admin Panel:
English
This must work.
Example:
Storefront:
English
Admin Panel:
简体中文
This must work.
Example:
Storefront:
Arabic
Admin Panel:
Русский
This must work.
Changing the Admin Panel language MUST NOT change the storefront language.
Changing the storefront language MUST NOT change the Admin Panel language.
Do NOT use one shared global locale state if it causes the two systems to change together.
Use separate locale state/persistence for:
Storefront
Admin Panel
━━━━━━━━━━━━━━━━━━━━
15. ADMIN LANGUAGE PERSISTENCE
━━━━━━━━━━━━━━━━━━━━
Persist the selected Admin Panel language.
After:
Refreshing the page
Navigating between /BRAYA pages
Closing/reopening the browser
Logging in again
the selected Admin Panel language should remain active.
Use the safest mechanism that fits the existing architecture.
Prefer an authenticated admin/user preference in the database if the existing system supports it.
Otherwise use a secure Admin-specific cookie.
Do NOT reuse the storefront locale cookie if that would couple the two systems.
━━━━━━━━━━━━━━━━━━━━
16. FULL SIMPLIFIED CHINESE ADMIN TRANSLATION
━━━━━━━━━━━━━━━━━━━━
Translate the entire Admin Panel UI into Simplified Chinese.
Do not only translate the language selector.
Chinese translation must cover all Admin UI, including:
Dashboard
Sidebar
Navigation
Header
Settings
Products
Categories
Orders
Customers
Reviews
Ads
Telegram settings
Maintenance settings
Theme settings
Forms
Buttons
Tables
Filters
Search
Pagination
Notifications
Confirmation dialogs
Success messages
Error messages
Validation messages
Empty states
Login/admin authentication UI
Account/profile settings
Do NOT translate dynamic business/user-generated content such as:
Product names
Product descriptions
Customer names
Customer messages
unless the existing system already translates those values.
Only Admin UI strings need translation.
━━━━━━━━━━━━━━━━━━━━
17. ADMIN ENGLISH / ARABIC / RUSSIAN / CHINESE COMPLETENESS
━━━━━━━━━━━━━━━━━━━━
Audit the entire Admin Panel.
Every Admin UI string should use the existing translation architecture.
Ensure translations exist for:
English
Arabic
Russian
Simplified Chinese
Do not leave visible translation keys such as:
admin.dashboard.title
on the production Admin UI.
Do not leave obvious untranslated English strings when Simplified Chinese is selected.
If there are existing missing translations, fix them as part of this Admin language implementation.
━━━━━━━━━━━━━━━━━━━━
18. ADMIN RTL/LTR
━━━━━━━━━━━━━━━━━━━━
Admin Panel direction must change according to the selected language.
Arabic:
RTL
English:
LTR
Russian:
LTR
Simplified Chinese:
LTR
When switching:
Arabic → Chinese
the Admin Panel should switch from RTL to LTR correctly.
When switching:
Chinese → Arabic
the Admin Panel should switch from LTR to RTL correctly.
This direction change must NOT affect the storefront.
━━━━━━━━━━━━━━━━━━━━
19. SERVER-SIDE LOCALE VALIDATION
━━━━━━━━━━━━━━━━━━━━
Only allow the supported Admin locales.
For example:
en
ar
ru
zh-CN
or the exact locale identifiers already used by the existing i18n system.
Validate the locale server-side.
Do not accept arbitrary locale values.
Do not allow arbitrary locale input to dynamically load files/modules.
Only authenticated administrators may change their Admin Panel language preference.
━━━━━━━━━━━━━━━━━━━━
20. TELEGRAM SETTINGS INSIDE ADMIN
━━━━━━━━━━━━━━━━━━━━
The Telegram-related Admin UI must also respect the selected Admin language.
If Admin language = English:
Use English Admin labels.
If Admin language = Arabic:
Use Arabic Admin labels.
If Admin language = Russian:
Use Russian Admin labels.
If Admin language = Simplified Chinese:
Use Simplified Chinese Admin labels.
This applies only to Admin UI.
It must NOT automatically change the language of Telegram customer messages or storefront content unless those systems already have their own independent localization.
━━━━━━━━━━━━━━━━━━━━
21. PRESERVE EXISTING TELEGRAM PRODUCT POST
━━━━━━━━━━━━━━━━━━━━
Do not redesign the Telegram product message.
Keep existing:
Product name
Description
Price
Image
Product information
Formatting
Hashtags
Existing links
Existing delivery information
Only fix/add the missing Inline Keyboard.
━━━━━━━━━━━━━━━━━━━━
22. DUPLICATE-PUBLISH PROTECTION
━━━━━━━━━━━━━━━━━━━━
Do not introduce duplicate Telegram posts.
Do not publish the same product twice because of this fix.
Reuse existing publishing/idempotency mechanisms.
━━━━━━━━━━━━━━━━━━━━
23. SECURITY
━━━━━━━━━━━━━━━━━━━━
Never expose:
Telegram Bot Token
Telegram webhook secret
Internal credentials
Private server configuration
Do not allow browser requests to inject arbitrary Telegram buttons or URLs.
The server must construct the keyboard.
For Maintenance Mode:
Keep server-side protection intact.
Do not rely on CSS for access control.
For Admin Language:
Only authenticated admins can change Admin language.
Validate locale values against an allowlist.
Do not allow arbitrary locale strings.
Do not weaken existing authentication or authorization.
━━━━━━━━━━━━━━━━━━━━
24. VALIDATION
━━━━━━━━━━━━━━━━━━━━
After implementation, run:
npx tsc --noEmit
npx prisma validate
npx next build
Also run the existing relevant tests if available.
TELEGRAM TESTS:
Publish a product with an image.
Verify Inline Keyboard appears underneath the post.
Test a product without an image if supported.
Verify the keyboard appears.
Click the button.
Verify it opens the correct product page.
Verify no duplicate post is created.
Verify Telegram errors are handled safely.
MAINTENANCE TESTS:
Disable Maintenance Mode.
Verify normal storefront behavior.
Enable Maintenance Mode.
Open storefront as a normal visitor.
Verify maintenance page appears.
Verify “Admin Login” / “دخول المسؤول” is NOT visible anywhere.
Test desktop.
Test mobile.
Verify an authorized administrator can still access /BRAYA.
Verify a normal visitor cannot bypass maintenance protection.
ADMIN LANGUAGE TESTS:
Open /BRAYA.
Verify Language Selector exists.
Select English.
Verify Admin UI is English.
Select العربية.
Verify Admin UI is Arabic and RTL.
Select Русский.
Verify Admin UI is Russian and LTR.
Select 简体中文.
Verify the entire Admin UI is Simplified Chinese and LTR.
Refresh the page.
Verify the selected Admin language persists.
Navigate between multiple /BRAYA pages.
Verify the language remains selected.
Log out and log back in.
Verify the selected Admin language remains active if the chosen persistence mechanism is designed to persist across login.
Change storefront language.
Verify Admin language does NOT change.
Change Admin language.
Verify storefront language does NOT change.
Test at least these combinations:
Storefront = Chinese + Admin = English
Storefront = English + Admin = Chinese
Storefront = Arabic + Admin = Chinese
Storefront = Chinese + Admin = Arabic
━━━━━━━━━━━━━━━━━━━━
25. FINAL REPORT
━━━━━━━━━━━━━━━━━━━━
After completing the work, report:
TELEGRAM:
Root cause of missing buttons.
Exact files changed.
Telegram publishing function/API route.
Whether reply_markup was missing, malformed, or incorrectly attached.
What was fixed.
Whether image and non-image publishing paths were fixed.
MAINTENANCE MODE:
Exact component/file responsible for the Admin Login link.
What was changed.
Confirmation that the link is no longer rendered to public visitors during Maintenance Mode.
Confirmation that admin authentication and authorization remain intact.
ADMIN LANGUAGE:
Existing i18n architecture used.
Files changed.
Translation files added/modified.
Supported Admin languages.
Chinese locale identifier.
Admin language persistence mechanism.
How Admin and storefront locales remain independent.
How RTL/LTR is handled.
Which Admin UI areas were translated.
Any remaining untranslated strings.
VALIDATION:
Tests executed.
Exact TypeScript result.
Exact Prisma validation result.
Exact production build result.
Whether a real Telegram publication test was possible.
Any remaining limitations.
Do not claim “100% bug-free”.
Do not modify unrelated functionality.
Use the smallest safe changes necessary to implement all three requirements correctly.