Internationalization (i18n) for Tourists

• set up i18n.
• Use a subfolder structure like /en/ with neutral versions (avoid explicit content).
• Add proper hreflang tags (e.g., es-MX, en-US).
• Ensure semantic consistency and avoid literal translations—adapt to local terms instead.

1. URLs & routing
   • Add /en/ (and others) only for public pages.
   • Rewrite → perfil.php?name=<slug>&locale=en; set $g['locale'] from URL (whitelist).
2. Bootstrap
   • $g['locale'] = request_locale_or_default(); vary $g['url'] and cache keys by locale.
3. Templates
   • Wrap UI strings with __($key, $g['locale']); load messages from local/<domain>/i18n/<locale>.php.
   • Admin stays in one language—unchanged.
4. Profile content (read path only)
   • Keep same slug across locales.
   • Optional table profiles_i18n(profile_id, locale, name, description, …) with fallback to base language.
   • Pre-fill via your existing jobs worker (new type translate_profile); no admin UI required.
5. SEO
   • Add hreflang for each locale; per-locale sitemaps; canonical to each locale URL.
   • If translations aren’t ready, serve /en/ with noindex until populated.
6. Media & links
   • Locale-aware link helpers; don’t duplicate images.

Then do the RW/RO split

• Route /admin|/login|/logout|/crons|POST → RW; public GET → RO.
• RO uses MySQL replica; media stays centralized.

This order keeps admin untouched, makes public i18n SEO-correct, and the RO server benefits immediately from the heavier read traffic.