feat: Make custom_code_head and custom_code_body translatable per locale #313

Problem or motivation

I need locale-specific scripts or JSON-LD structured data on a multilingual Ycode site, and the only options are:

• Use a single version across all locales — works for global scripts like Lenis, but fails for JSON-LD where service names, descriptions, and entity labels differ per language
• Inject both versions in global custom code and swap with JS — fragile; crawlers see only the first version, making it unreliable for SEO-critical tags
• Skip locale-specific structured data entirely — suboptimal for SEO/GEO on multilingual sites

Proposed solution

Add custom_code_head and custom_code_body as translatable content keys for pages.

• When a translation exists for a given locale, it replaces the default value in the rendered output
• When no translation exists, the default is used — full backward compatibility
• CMS variable resolution ({{FieldName}}) should work identically

Content keys: custom_code_head, custom_code_body
Source type: page
Content type: text

Alternatives considered

1. Single-language schema across all locales — fine for universal entities like Organization, but inadequate for Service, BlogPosting, or Product where content differs per language
2. Client-side JS locale detection — inject both versions, swap on load. Crawlers receive whichever version appears first, making it unreliable for JSON-LD, Open Graph, and verification tags
3. Duplicate pages per locale — bypasses Ycode's native localization system, creates maintenance overhead, and defeats the purpose of having translations

Area

Pages & Routing

Additional context

• Needed for a bilingual (French/English) Ycode site using JSON-LD structured data for SEO/GEO
• The global custom_code_head already works well for shared scripts; the gap is page-level locale-specific content
• Implementation complexity is low — the translatable content resolver already handles similar string-based keys like seo:title and seo:description