feat(chrome-extension): add multilingual UI, modern UX, latest Code.gs sync, and extension testing

[ardalan-ab]

What’s Included

• Added English/Persian (fa) language support with a language switcher
• Implemented RTL layout for Persian mode
• Updated extension UI with modern styling, icons, and loading feedback
• Added a loading indicator while fetching the latest Code.gs
• Synced Code.gs with the latest repository version
• Added test.html for standalone UI testing outside Chrome Extension mode
• Added structured i18n/messages.json files to support localization
• Improved error handling and feedback for copy/download actions
• Expanded README.md with usage and testing instructions

---

Why This Is Valuable

• Makes setup easier and more user-friendly
• Supports Persian users with full localization
• Ensures the extension always uses the latest Apps Script source
• Provides a lightweight test harness for faster validation
• Strengthens the extension as a production-ready helper tool

---

آنچه اضافه شده است

• افزودن پشتیبانی از زبان‌های انگلیسی و فارسی (fa) به همراه قابلیت تغییر زبان
• پیاده‌سازی چیدمان راست‌به‌چپ (RTL) برای حالت فارسی
• به‌روزرسانی رابط کاربری افزونه با طراحی مدرن، آیکون‌ها و بازخورد بارگذاری
• افزودن نشانگر بارگذاری هنگام دریافت آخرین نسخه Code.gs
• همگام‌سازی فایل Code.gs با جدیدترین نسخه مخزن
• افزودن فایل test.html برای تست مستقل رابط کاربری خارج از حالت افزونه Chrome
• افزودن ساختار استاندارد i18n/messages.json برای پشتیبانی از چندزبانه‌سازی
• بهبود مدیریت خطاها و بازخورد عملیات کپی و دانلود
• گسترش فایل README.md با توضیحات مربوط به استفاده و تست

---

اهمیت این تغییرات

• ساده‌تر و کاربرپسندتر شدن فرایند راه‌اندازی
• پشتیبانی کامل از کاربران فارسی‌زبان با بومی‌سازی کامل
• اطمینان از استفاده افزونه از جدیدترین نسخه Apps Script
• فراهم کردن محیط تست سبک برای اعتبارسنجی سریع‌تر
• تقویت افزونه به‌عنوان یک ابزار کمکی آماده استفاده در محیط Production

[therealaleph]

Reviewed via Anthropic Claude.

Solid first contribution, well-scoped. Walked through the diff:

• manifest.json v3, minimal permissions (storage, clipboardWrite), narrow host_permissions to script.google.com, raw.githubusercontent.com, api.github.com. No tab/cookie/webRequest scope — clean.
• popup.js fetches the canonical Code.gs from raw.githubusercontent.com/therealaleph/MasterHttpRelayVPN-RUST/main/assets/apps_script/Code.gs, generates the AUTH_KEY locally via crypto.getRandomValues, never exfiltrates anything off-device.
• The bundled chrome-extension/Code.gs is byte-identical to the current assets/apps_script/Code.gs (797 lines each, diff empty), so the fallback isn't a divergence vector at the snapshot point.
• i18n + RTL is well-done.

A few real concerns before merging into the main repo:

1. Bundled Code.gs drift: every time assets/apps_script/Code.gs changes (which happens ~3-5×/release), the bundled fallback needs to update too. CI doesn't currently check this. Two options:

   • Build step: a tiny CI job that fails the release if chrome-extension/Code.gs ≠ assets/apps_script/Code.gs.
   • Remove the bundle: extension only fetches from raw.githubusercontent.com, fails gracefully if blocked. Iran-network reality is that GitHub raw is sometimes blocked too — the bundle has real value as fallback. The drift problem is what needs solving, not the bundle's existence.
   • I'd prefer option 1.

2. Repo placement: this is a non-trivial new top-level directory (~1700 LoC of HTML/CSS/JS + Code.gs mirror). Alternatives I want to weigh before merging:

   • In-repo (this PR): official, discoverable, one-click contribution. Maintenance burden on the main team.
   • Separate repo (e.g. therealaleph/mhrv-helper-extension): cleaner separation, you (ardalan-ab) can own its release cadence + Chrome Web Store listing. Main repo links to it from README. Most projects do this.
   • A community-tools README section: list the extension as a community resource without bundling it, again pointing at your repo.

   I lean toward the separate-repo path, with you as the listed maintainer in the docs. The main repo's surface stays focused on the proxy + Apps Script; the extension lives next to it as a sibling. Open to being talked out of this.

3. Chrome Web Store distribution: extensions installed by side-loading the source dir are friction for typical users. Are you planning to publish to Chrome Web Store? If yes, the published listing's author identity ("ardalan-ab" or therealaleph?) needs deciding before we link it.

4. Test coverage: test.html is for manual UI testing, which is fine but not equivalent to automated tests. For an extension that holds AUTH_KEYs (even briefly), I'd want at least a smoke test that the AUTH_KEY never leaves the clipboard / DOM scope. Not a blocker for v0.2.0, but worth filing as a follow-up.

If you're up for it, my preferred next step:

• Push the extension to your own ardalan-ab/mhrv-helper-extension repo as v0.2.0.
• Open a small doc PR here adding a "Community helpers" subsection in our top-level README that links to your repo + describes what the extension does.
• That doc PR I can merge tonight.

If you prefer it land in the main repo: doable, but I'd want to address concerns 1 + 3 (CI sync check + Chrome Web Store plan) first.

Leaving open while you think about which direction. Strong work either way — the popup UX is much nicer than hand-editing Apps Script.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}

[ardalan-ab]

Sounds good to me.

I’ll move the extension into a separate repo on my side and continue maintaining it there.

I’ve also already added:

• a CI sync check for "Code.gs"
• some basic test coverage improvements
• a version-check button so users can verify whether they’re on the latest extension release

Then I’ll open a smaller PR here for the README/community helpers section linking to the repo.

I’m also fine with the extension being officially published/distributed under the main project as long as contributor/maintainer attribution remains included.

Thanks again for the detailed review.