# International Grand Enter

## Executive Intent

This plan defines how Teknav should enter non-Persian, international markets as a real English-language product, not as a surface translation of the current Persian site. The target is a complete English, LTR, production-grade publication experience under `/en/`, with independent editorial standards, search visibility, structured data, feeds, discovery paths, admin workflows, analytics, and operational validation. The English surface must feel native to international readers: clear English information architecture, English-first editorial judgment, LTR UI, English metadata, English screenshots and Open Graph images, English author bios, English newsletters, English legal copy, English calls to action, and English technical references.

The product should preserve Teknav's strongest asset: deep technical analysis. The Persian site is a Persian RTL authority publication. The English site should become an international technology analysis publication that can compete for global queries around AI engineering, software infrastructure, cybersecurity, data systems, developer tools, frontier models, AI policy, and applied technical research. That means the work is not only translation. It is market entry.

The core rule: English pages must be useful if the Persian site did not exist. Each page should stand on its own for an English-speaking reader, crawler, newsletter subscriber, researcher, developer, and social referrer. Hreflang can connect equivalent Persian and English pages, but the English pages cannot be thin duplicates, machine-translated artifacts, or Persian pages with English labels. They need English topic framing, English title logic, international source context, English terminology, LTR design, correct schema, and international distribution.

## Strategic Positioning

Teknav English should not try to compete as a general breaking-news site. Global tech news is crowded and dominated by brands with large reporting desks. Teknav's international advantage should be analysis quality, technical density, and perspective. The English product should position itself as:

1. A deep technology analysis publication focused on AI infrastructure, data systems, security, software engineering, and emerging computing.
2. A bridge between global technology trends and under-covered technical ecosystems, including Persian-language and regional technical signals when relevant.
3. A source of long-form explainers that developers, startup operators, researchers, and technical managers can cite.
4. A publication with first-party tools, glossaries, comparisons, diagrams, and structured explainers rather than only articles.

The English brand can remain `Teknav`, but the English tagline should be explicit: "Deep technology analysis for builders." Alternate taglines can be tested later, but the first version should avoid abstract phrasing. Readers landing from search need to know immediately that the site covers serious technology analysis, not generic commentary.

The English homepage should not be a mirror of the Persian homepage. It should emphasize international categories and proof of expertise: AI Engineering, Security, Data Infrastructure, Software Architecture, Hardware and Compute, Startup Systems, and Research Notes. If Persian categories map one-to-one, their English labels still need native editorial names, not literal translations.

## Success Criteria

The English launch should be considered production-ready only when all of these are true:

- Every public English route renders with `<html lang="en" dir="ltr">` or an equivalent route-scoped LTR shell.
- Every English page has a self-canonical English URL and does not canonicalize to Persian.
- Pages with a Persian equivalent have reciprocal `hreflang` for `fa`, `en`, and `x-default`.
- Pages without a Persian equivalent omit equivalent-language hreflang and stand as independent English content.
- English pages have English titles, descriptions, Open Graph tags, Twitter Card tags, JSON-LD, breadcrumbs, feed entries, and sitemap entries.
- All UI strings, empty states, validation messages, buttons, menus, filters, form labels, admin labels for English content, notification text, email templates, and newsletter copy are English where the selected product surface is English.
- CSS and layout pass a full LTR audit. No accidental RTL ordering, Persian punctuation, Persian numerals, or mirrored icons remain on English pages.
- Static generation supports English article pages, topic pages, author pages, glossary pages, comparisons, directory pages, story pages, feeds, and sitemap indexes.
- English content passes editorial review by a fluent English technical editor before indexing.
- The production build remains zero-CDN, zero external font, and zero external image dependency.
- English analytics can be segmented by locale, route, topic, author, acquisition source, and content type.
- The backend and admin workflows can create, edit, preview, schedule, publish, review, and audit English content without using Persian seed data as a live fallback.

## Scope

The international launch includes these surfaces:

- English homepage at `/en/`.
- English article list at `/en/articles`.
- English article detail at `/en/article/:slug`.
- English topics at `/en/topics/:slug`.
- English categories and tags at `/en/category/:slug` and `/en/tag/:tag`.
- English author pages at `/en/author/:slug` and, where needed, public profile equivalents.
- English glossary at `/en/glossary/:slug`.
- English newsletter archive at `/en/newsletter` and `/en/newsletter/:slug`.
- English comparison pages at `/en/compare` and `/en/compare/:slug`.
- English company directory at `/en/directory` and `/en/directory/:slug`, if companies are relevant internationally.
- English tools pages where the tool is useful for international readers.
- English web stories at `/en/stories` and `/en/stories/:slug`.
- English embed widgets where third-party sites can embed English cards.
- English legal pages: privacy, terms, about, contact, editorial policy, corrections policy, advertising/sponsored policy, and AI-use policy.
- English feeds: `/en/feed.xml`, topic feeds, author feeds, and optional JSON content exports.

The first release should not include international paid membership unless pricing, currency, terms, refund rules, and payment gateway support are ready. If membership is not ready, English premium UI should be hidden or replaced with newsletter and reader-account CTAs.

## URL And Routing Architecture

Use `/en/` as the English root. This keeps authority on `www.teknav.ir`, avoids a new domain cold start, and aligns with the existing Phase 16 direction. The English URL pattern should be clean and stable:

- Persian canonical: `https://www.teknav.ir/article/ai-clean-data`
- English canonical: `https://www.teknav.ir/en/article/ai-clean-data`

The implementation should not use `?lang=en` for indexable English content. Query-language pages are weak for canonical SEO and confusing for users. English routes should be path-based, crawlable, cacheable, and statically generated wherever possible.

Route dispatch should be separated by locale. The current SPA router should not simply add one special `/en` page. The route system needs a locale-aware shell:

- Locale parsing: `fa` default for root routes, `en` for `/en/*`.
- Direction: `rtl` for `fa`, `ltr` for `en`.
- Language: `fa-IR` for Persian, `en` or `en-US` for English.
- Navigation labels: locale-specific.
- Footer labels: locale-specific.
- SEO manager: locale-specific.
- Static generation: locale-specific.

If the frontend remains a SPA with static HTML generation, generated English pages must contain the correct English head tags at build time. Client-side head updates are not enough for competitive international SEO.

## Canonical And Hreflang Rules

Every English page should be self-canonical. The Persian page should also remain self-canonical. A translated article pair should use reciprocal alternates:

```html
<link rel="canonical" href="https://www.teknav.ir/en/article/slug" />
<link rel="alternate" hreflang="en" href="https://www.teknav.ir/en/article/slug" />
<link rel="alternate" hreflang="fa" href="https://www.teknav.ir/article/slug" />
<link rel="alternate" hreflang="x-default" href="https://www.teknav.ir/article/slug" />
```

For English-original articles with no Persian equivalent, use only the English canonical. Do not invent Persian alternates. For Persian-original articles with no English equivalent, do not add English hreflang. Hreflang must represent real, crawlable, equivalent pages.

Each localized pair must list itself and all other versions. This should be generated from data, not hand-authored per page. The content model should include `translations` or `localizedVersions` metadata:

- `locale`
- `slug`
- `canonicalPath`
- `sourceArticleId`
- `translationOf`
- `translationStatus`
- `localizedTitle`
- `localizedDescription`
- `localizedOgImage`

The sitemap approach is preferable for scale. HTML head tags should exist for immediate page clarity, but sitemap hreflang can centralize the complete matrix and reduce mistakes. If both are used, they must be generated from the same source of truth. Never maintain separate manual hreflang lists.

## Content Model

English content needs a real data model, not only a translated string map. Add or design for a localized content layer with these fields:

- `locale`: `fa-IR` or `en`.
- `baseArticleId`: stable ID connecting related language versions.
- `slug`: locale-specific slug.
- `title`: English title, not literal translation.
- `subtitle`: English dek/subtitle.
- `summary`: English summary.
- `bodyHtml`: English article body.
- `metaTitle`: optional override for search title.
- `metaDescription`: English search description.
- `canonicalPath`: `/en/article/...`.
- `ogTitle`, `ogDescription`, `ogImage`: English social metadata.
- `twitterTitle`, `twitterDescription`, `twitterImage`.
- `categorySlug`, `topicSlug`, `tags`: English taxonomies or mapped cross-locale taxonomies.
- `sourceLanguage`: original source language.
- `translationMethod`: original, human translation, machine-assisted draft, adapted rewrite.
- `translationReviewerId`: English editor responsible for final quality.
- `factCheckedAt`, `reviewedById`, `dateModified`, `corrections`.
- `englishReadingLevel`: target clarity score or editorial assessment.
- `internationalPriority`: launch sequencing flag.
- `regionRelevance`: global, US, EU, MENA, India, etc. only if actually relevant.

The existing Persian `teknav-data.js` can remain seed/reference data, but English should not become a loose `teknav-data-en.js` if the goal is production CMS. A static English file is acceptable for the first build pipeline prototype, but production should use backend-backed localized article records and admin workflows.

## Translation Is Not Enough

Each English article should pass through four editorial stages:

1. Technical extraction from the Persian article: claims, entities, data, diagrams, citations, definitions, and conclusions.
2. English outline rewrite: restructure for international readers, often changing the lead, headings, examples, and comparisons.
3. English technical draft: translate where useful, but rewrite idioms, transitions, and explanations.
4. English editorial review: verify terminology, citations, tone, title, search intent, and international relevance.

Literal translation will fail in international SEO because search intent changes by language. Persian readers may search for explanatory and localized terms. English readers may search for product names, standards, model names, regulatory terms, GitHub projects, CVEs, benchmark names, and implementation questions. The English article must target English search intent.

For example, a Persian article about "clean data in AI" may become an English article targeting "data-centric AI", "clean training data", "LLM data quality", and "AI data governance". The English title should not simply mirror the Persian title. It should choose the strongest global query cluster.

Machine translation may be used only as a draft accelerator. It cannot be the published final. Every English article needs human technical editing, source verification, and an English-native SEO pass.

## English Editorial Style Guide

English Teknav should use a concise, analytical style:

- Prefer clear technical English over marketing language.
- Explain acronyms on first use.
- Use active voice when possible.
- Avoid exaggerated claims like "revolutionary" unless quoted or justified.
- Use "AI model", "language model", "inference", "training data", "retrieval", "vector database", "agent", and other standard English technical terms consistently.
- Preserve Persian or regional context only when it adds unique value.
- Include concrete examples, metrics, command snippets, architecture diagrams, timelines, and comparison tables.
- Use article leads that answer "why this matters internationally" in the first 120 words.
- Use headings that match search intent, not literary phrasing.
- Prefer UTC or explicit timezone timestamps for international readers.
- Use Gregorian dates first. Persian calendar dates can be omitted unless relevant.
- Use English numerals on English pages.

Author bios should also be rewritten. A Persian author profile translated directly may feel local-only. English bios should emphasize expertise, coverage areas, editorial role, and verification. If the author is Persian-speaking but writing for an international audience, the bio can say so only when useful.

## English Information Architecture

The English homepage should be built around international reader tasks:

- "Latest Analysis" for current articles.
- "AI Engineering" for agents, model infrastructure, evaluation, RAG, inference, data quality.
- "Security" for vulnerabilities, software supply chain, AI security, browser security, cloud security.
- "Data Infrastructure" for Postgres, vector search, analytics, pipelines, governance.
- "Software Architecture" for developer tools, frameworks, backend systems, architecture decisions.
- "Compute and Hardware" for GPUs, chips, edge computing, robotics, data centers.
- "Research Notes" for math, scientific computing, benchmarks, and papers.
- "Comparisons" for high-intent X vs Y pages.
- "Glossary" for definitions that can rank and support internal linking.

Do not launch English with every Persian category if some categories have weak English content. A smaller, stronger IA is better for international search.

## SEO Architecture

The English SEO architecture should be built as a separate growth engine.

Technical requirements:

- Static English HTML for every indexable route.
- Self-canonical English URLs.
- Hreflang only where real equivalents exist.
- English sitemap index and child sitemaps.
- English RSS feeds.
- English robots rules.
- English Open Graph images.
- `og:locale` should be `en_US` or `en`.
- `og:locale:alternate` can reference `fa_IR` when there is a real Persian equivalent.
- Article schema should use `NewsArticle` and `TechArticle` where appropriate.
- Collection pages should use `CollectionPage`, `ItemList`, `BreadcrumbList`, and FAQ only where real FAQ content exists.
- Glossary terms should use `DefinedTerm`.
- Author pages should use `ProfilePage` or relevant person schema.
- Organization schema should represent the same Teknav organization entity across languages.
- `inLanguage` must be `en` for English pages.
- Images in Article structured data must be relevant, local, crawlable, and large enough for rich results.

Search intent requirements:

- Each English topic should have a keyword and intent map, but keyword stuffing must be avoided.
- Classify each article by intent: explainer, technical guide, analysis, comparison, reference, news analysis, glossary.
- Use English title formats that match the intent. Example: "What Is MCP? A Technical Guide to Model Context Protocol" is stronger than a literal Persian title.
- Comparison pages should exist for high-intent queries such as "PostgreSQL vs MongoDB", "Claude vs GPT", "RAG vs Fine-Tuning", and "Vector Database vs Keyword Search".
- Glossary clusters should exist for entity definitions such as "Model Context Protocol", "RAG", "context window", "tool calling", "agentic AI", and "post-quantum cryptography".
- Articles should connect naturally to glossary, comparisons, topic hubs, and related articles.
- Avoid auto-linking too aggressively. Internal links should help readers.

International SEO must compete on specificity. The goal is not generic "AI news". It is query clusters where a smaller publication can win by being clearer, deeper, and better structured.

## Structured Data Plan

English structured data must come from localized English data and visible English page content. It must not be copied from Persian pages and then partially edited. The implementation team should decide where generation belongs, but the outcome must be consistent, valid, and maintainable.

For articles:

- `@type`: `["NewsArticle", "TechArticle"]` where both are appropriate.
- `headline`: English title.
- `description`: English meta description.
- `image`: English OG/discover image.
- `datePublished`, `dateModified`: ISO timestamps.
- `author`: English author name and profile URL.
- `publisher`: Teknav organization.
- `inLanguage`: `en`.
- `mainEntityOfPage`: English canonical URL.
- `isAccessibleForFree`: true/false if premium is introduced.

For topic hubs:

- `CollectionPage`
- `ItemList`
- `BreadcrumbList`
- `FAQPage` only when the content has visible Q&A sections.

For glossary:

- `DefinedTerm`
- `BreadcrumbList`
- optional `FAQPage` for visible, useful FAQs.

For comparisons:

- `ItemList`
- `FAQPage`
- `BreadcrumbList`
- optional `HowTo` only if the page is genuinely procedural.

Structured data must match visible page content. Do not add schema for content hidden from users.

## Sitemaps And Feeds

The build pipeline needs English artifacts:

- `/sitemap-en.xml` as a sitemap index or top-level English sitemap.
- `/sitemap-en-main.xml`
- `/sitemap-en-articles.xml`
- `/sitemap-en-topics.xml`
- `/sitemap-en-glossary.xml`
- `/sitemap-en-authors.xml`
- `/sitemap-en-comparisons.xml`
- `/sitemap-en-directory.xml` if directory pages are internationalized.
- `/en/feed.xml`
- `/en/feeds/topic-ai.xml`, etc.
- `/en/feeds/author-*.xml`.

The global `/sitemap.xml` should include English child sitemaps. Lastmod dates must be capped to the current date, as the Persian pipeline already does. Future-dated English articles should not enter sitemaps or feeds until published.

English feed entries need English titles, summaries, canonical links, author names, categories, and full-content RSS where appropriate. Do not include Persian body content in English feeds.

## Open Graph And Image Strategy

English needs separate OG images. Current Persian images contain Persian text and should not be reused for English social cards if text is embedded.

English OG image requirements:

- 1200 x 630 minimum.
- English title text.
- English topic label.
- Teknav English wordmark.
- Local generated files under `/public/images/og/en/` or equivalent.
- No external image URLs.
- Article-specific visuals where possible.
- Consistent visual system but not identical Persian typography.

The generation script should accept locale. It should choose English fonts that are locally hosted and perform well. If using Vazirmatn for Persian and PelakFA for display, English should use a local Latin-compatible stack. Prefer self-hosted Inter, IBM Plex Sans, Source Sans 3, or a system font strategy. If adding fonts, keep them local and subset if possible.

## LTR Design System

The English launch requires a full LTR pass. Direction is not just text alignment. It affects:

- Header nav order.
- Logo placement.
- Drawer animation direction.
- Breadcrumb separators.
- Card metadata order.
- Icon orientation.
- Search input alignment.
- Form label alignment.
- Tooltip placement.
- Article table of contents placement.
- Byline and author card layout.
- Share button order.
- Comparison table reading direction.
- Admin editor panels if English content is edited in English mode.
- Toast positioning.
- Modal close buttons.
- Pagination controls.
- Previous/next article navigation.

Use logical CSS properties wherever possible: `margin-inline-start`, `padding-inline-end`, `inset-inline-start`, `border-inline-start`, etc. Avoid hard-coded left/right unless the visual concept is inherently directional.

The English shell should have its own quality bar:

- Desktop 1440, 1280, 1024.
- Tablet 768.
- Mobile 430, 390, 360.
- Very narrow mobile 320 if supported.
- Browser zoom at 125% and 150%.
- Long English titles.
- Long unbroken technical tokens such as CVE IDs, package names, GitHub repository names, and URLs.

Every English UI page needs a screenshot review before indexing.

## Frontend Architecture

The frontend must support English as a complete product surface, not as a visual overlay on the Persian site. The required outcome is a clear separation between Persian and English presentation, navigation, metadata, static output, and user-facing strings. The implementation team should choose the exact structure, but the result must make English routes predictable, maintainable, and safe to expand.

Required outcomes:

- English pages must resolve independently under the English URL surface.
- English pages must render with LTR direction from the first meaningful paint.
- English navigation, footer, search, article cards, breadcrumbs, forms, profile surfaces, and empty states must be English.
- English SEO metadata must be generated from English content.
- English static pages must contain meaningful English content before hydration.
- English API-backed surfaces must request and display English content only.
- Shared components may be reused only when they remain natural in both RTL Persian and LTR English.
- English-specific layouts should be allowed where reuse would create awkward UX.
- Persian routes must remain stable after English is added.
- The frontend should remain understandable for future maintainers.

## Backend And API Plan

The backend must support localized publishing without frontend seed fallback. The implementation team should decide the exact schema and route mechanics, but the production behavior must be unambiguous: English content, metadata, author profiles, newsletter flows, analytics, comments, and admin workflows must be separable from Persian content.

Required outcomes:

- Public content APIs must be able to return English content without leaking Persian fallbacks.
- Missing English content must be treated honestly instead of silently substituting Persian content.
- English and Persian versions of related content must be linkable when true equivalents exist.
- English originals must be possible without requiring Persian originals.
- Adapted English versions must be possible without forcing one-to-one structure with the Persian source.
- English slugs, canonical paths, SEO fields, OG fields, authors, categories, tags, topics, review dates, and correction notices must be stored and served as English data.
- Admin APIs must support English editorial workflows.
- Analytics must distinguish English behavior from Persian behavior.
- Newsletter and notification systems must respect reader language preference.
- Backend documentation should continue to distinguish the public API prefix from the concrete versioned API surface.

## Admin And Editorial Workflow

English content requires a real workflow:

- English original articles must be supported.
- English adaptations from Persian source material must be supported.
- Link English and Persian versions.
- Preview English static route before publish.
- English SEO audit readiness must be confirmed.
- English LTR layout preview readiness must be confirmed.
- Confirm English OG image readiness.
- Confirm English summary and feed readiness.
- Approve by English editor.
- Publish/schedule.
- Notify English subscribers only.

Admin filters should include:

- Locale.
- Translation status.
- Original vs adapted.
- English SEO quality.
- English editorial status.
- Missing hreflang counterpart.
- Missing OG image.
- Missing author bio translation.
- Missing glossary links.

Writers should not be able to publish English content directly unless they have English editorial permission. A technically correct article with weak English will damage trust.

## English SEO Quality Gate

Before publishing an English page, require:

- English title length within target range.
- English meta description present and not duplicated.
- Canonical path starts with `/en/`.
- `inLanguage` is `en`.
- Hreflang pair is valid if a translation exists.
- OG image exists and is English.
- Article has at least one English author profile.
- Article has visible publication date and modified date when changed.
- Article has clear headings.
- Article body is not mostly copied machine translation.
- Article has relevant internal links.
- Article has no Persian UI labels unless intentionally quoting.
- Article has no Persian numerals except in quoted Persian context.
- English tags and category are present.
- Premium/sponsored/correction labels are English if applicable.
- No external CDN asset appears in generated HTML.

The audit should fail publication for critical issues and warn for lower-risk issues.

## International Content Launch Plan

Do not translate everything at once. Start with a focused launch collection:

- 10 flagship English articles.
- 6 topic hubs.
- 20 glossary terms.
- 8 comparison pages.
- 3 author profiles.
- English homepage.
- English about/editorial policy/corrections policy/privacy/terms/contact.
- English feed and sitemap.
- English OG images.

Flagship article selection should prioritize:

- Evergreen technical value.
- International search demand.
- Existing Persian content strength.
- Ability to add unique perspective.
- Strong internal-link opportunities.

Good launch candidates:

- Data-centric AI and clean data.
- Model Context Protocol.
- RAG evaluation for Persian and low-resource languages.
- AI agents in production.
- Post-quantum cryptography.
- Software supply chain security.
- Vector search and semantic search.
- Local AI compute.
- AI data governance.
- Browser-based agent security.

Each article should be rewritten for English search intent and linked into topic hubs.

## International Distribution

SEO alone is not enough. The English launch needs distribution:

- Submit English sitemap in Google Search Console.
- Submit to Bing Webmaster Tools.
- English RSS discovery links should be available.
- English social card previews should be ready.
- English newsletter signup should be ready.
- Publish launch thread on LinkedIn, X, Hacker News where appropriate, Reddit only if community rules allow.
- Pitch selected deep articles to technical newsletters.
- Publish GitHub repositories or datasets when an article includes original research or tools.
- Embeddable glossary/article cards should be available for English technical blogs when they are useful.
- Use author profiles with clear expertise and external links.

Backlinks should come from useful assets: benchmarks, calculators, comparison pages, glossary definitions, diagrams, and research notes. Do not buy links or syndicate low-quality duplicates.

## Analytics And Measurement

Track English separately:

- Page views by locale.
- Search clicks and impressions by English query.
- Index coverage by English route type.
- Article engagement by locale.
- Newsletter conversion by English page.
- Scroll depth by English article type.
- Share clicks by English channel.
- Internal link clicks from English topic hubs.
- Hreflang error counts.
- English 404s.
- English Core Web Vitals.

Dashboards should show Persian and English side by side, but not mix them by default. The English launch will have different growth behavior.

## Performance Requirements

International users may have varied network conditions. English pages should be lighter than the current reader SPA if possible.

Required:

- Route-split admin/editor code from public reader bundle.
- Lazy-load heavy diagrams and 3D.
- Keep English homepage fast.
- Preload only required fonts.
- Use responsive images.
- Keep no CDN policy.
- Maintain compressed static output.
- Test mobile Lighthouse on `/en/`, `/en/article/:slug`, and `/en/topics/ai`.
- Verify generated English pages have useful static content before hydration.

International SEO will suffer if the English site ships unnecessary CMS JavaScript to every reader.

## Competitive Landscape And Market Entry Logic

The English launch has to be designed around realistic competition. International English technology search is divided into several layers:

- Large newsrooms ranking for current events and product announcements.
- Developer documentation and vendor blogs ranking for official feature queries.
- Engineering blogs ranking for technical implementation topics.
- SEO-driven content farms ranking for shallow definitions and comparisons.
- Forums and community sites ranking for troubleshooting and practical questions.
- Academic, standards, and research sites ranking for papers, protocols, and formal references.

Teknav should not compete head-to-head with all of them at once. The launch should identify "winnable authority lanes": topics where Teknav can publish deeper, more structured, and more international content than commodity SEO pages, while still being more readable than raw research or vendor documentation.

The best international lanes for Teknav are:

- AI infrastructure explainers that connect concepts to production architecture.
- Independent comparisons where vendor blogs are biased.
- Glossary pages that are short enough to rank but deep enough to earn internal links.
- Regional and low-resource-language technical analysis that English competitors rarely cover well.
- Security and reliability topics with clear risk framing.
- Developer-tool analysis written for technical leads and builders, not only beginners.
- Static evergreen references that can be updated over time.

The English strategy should avoid:

- Generic "what is AI" pages unless they support a very specific cluster.
- Thin daily news rewrites.
- Unverified product rumors.
- Auto-generated glossary pages without editorial usefulness.
- Direct translations of Persian local news that do not matter to global readers.
- Over-optimized pages with unnatural keyword repetition.

Before any English content is created, build a competitor matrix for each launch topic:

- Query cluster.
- Current top-ranking pages.
- Content type: documentation, news, blog, comparison, glossary, forum, paper.
- Search intent.
- Weakness in current results.
- Teknav angle.
- Required evidence.
- Required diagrams or tables.
- Internal links needed.
- Expected update cycle.

Example:

- Query cluster: "RAG evaluation", "evaluate retrieval augmented generation", "RAG metrics".
- Current competition: vendor blogs, framework docs, research explainers.
- Weakness: many pages list metrics without explaining failure modes.
- Teknav angle: production-grade RAG evaluation checklist with precision, recall, faithfulness, latency, cost, multilingual retrieval, and human review.
- Required assets: diagram of evaluation pipeline, metric table, glossary links, implementation checklist.
- Update cycle: quarterly, because tooling changes quickly.

This kind of mapping turns the English site into a planned search product rather than a translated archive.

## Audience Segments

The English site should serve multiple international reader groups, but every group must still fit Teknav's technical identity.

Primary audience:

- Software engineers.
- AI engineers.
- Data engineers.
- Security engineers.
- Engineering managers.
- Startup founders with technical responsibility.
- Technical product managers.
- Researchers who want readable summaries.

Secondary audience:

- Policy and business readers following AI infrastructure.
- Students and early-career developers looking for serious explainers.
- Journalists and newsletter writers looking for technically accurate context.
- International readers curious about technology signals from non-US and non-European ecosystems.

The site should not optimize for casual lifestyle tech readers. That market pushes the product toward shallow gadget writing and generic news. English Teknav should remain a technical publication.

Each audience segment needs different page affordances:

- Engineers need diagrams, definitions, examples, tables, and precise terminology.
- Managers need executive summaries, tradeoffs, risks, and adoption signals.
- Researchers need citations, paper names, benchmark context, and careful uncertainty language.
- Founders need market relevance, timing, cost, and implementation feasibility.
- Journalists need stable definitions, source links, authorship, and clear correction policies.

The article template should support this with visible components:

- TL;DR summary.
- Key terms.
- Why it matters.
- Technical breakdown.
- Tradeoffs.
- Practical technical notes.
- Risks and limitations.
- Related glossary.
- Related comparisons.
- Last reviewed date.

Do not force every article to use every block, but the English CMS should make them available.

## Brand And Naming Decisions

The English product should keep the Teknav name unless there is a strong legal or brand reason to separate it. A sub-brand can be used in metadata and copy:

- Teknav English
- Teknav International
- Teknav Tech Analysis

The public-facing brand should still read simply as "Teknav". The homepage can use a descriptive line such as "Technology analysis for builders" or "Deep technical analysis for AI, security, and software infrastructure."

Avoid slogans that only sound stylish. International readers need immediate category clarity. The title tag for the English homepage should include brand plus subject:

- `Teknav | AI, Security, and Software Infrastructure Analysis`

The English brand system should define:

- English wordmark treatment.
- English footer tagline.
- English newsletter name.
- English author-card style.
- English correction badge language.
- English sponsored-label language.
- English social profile descriptions.

The English social presence should not mix Persian and English posts in a confusing way. Either create locale-specific social profiles or make profile descriptions and posting cadence explicitly bilingual. For the first international entry, an English newsletter and RSS feed matter more than many social channels.

## Locale Strategy: English Now, Regions Later

The first international version should be plain English, not multiple regional English versions. Use `/en/`, not `/us/`, `/uk/`, or `/global/`. Region-specific expansion can be considered later if the site gains enough traffic and if content genuinely differs by region.

Recommended locale:

- HTML `lang`: `en`
- Direction: `ltr`
- URL prefix: `/en/`
- `og:locale`: `en_US` is acceptable for Open Graph compatibility, but content should be globally written.
- Dates: Gregorian, displayed in English.
- Timezone: explicit when relevant, preferably UTC for technical articles.
- Currency: avoid pricing unless the product supports international payments.

Do not target `en-US`, `en-GB`, and `en-IN` separately at launch. That would multiply hreflang and content-maintenance complexity without enough benefit. If future regional pages are introduced, they must be truly region-specific and not copies with spelling differences.

The English copy should use internationally neutral technical English:

- Prefer "organization" or "organisation" consistently. Choose one style and document it.
- Prefer "color" or "colour" consistently. Choose one style and document it.
- Use SI units and explain region-specific policy or legal terms.
- Avoid idioms that confuse non-native English readers.

Recommendation: use US spelling because most technical documentation, schema examples, and developer tools use it. That does not mean the audience is US-only.

## Complete Translation And Localization Inventory

"Every single thing should be LTR and English" means the project needs a full string and asset inventory. The plan should include a localization audit across these layers:

- Public navigation.
- Mobile navigation.
- Footer.
- Homepage sections.
- Article cards.
- Article detail pages.
- Topic hubs.
- Tags.
- Categories.
- Glossary.
- Comparisons.
- Directory.
- Stories.
- Embed widgets.
- Search UI.
- Login/register.
- Profile.
- Saved articles.
- Reading lists.
- Comments and replies.
- Notifications.
- Newsletter subscription.
- Newsletter archive.
- Contact forms if implemented.
- Error pages.
- Empty states.
- Loading states.
- Toasts.
- Form validation messages.
- Auth errors.
- 2FA flows.
- OAuth labels.
- Password reset emails if implemented.
- Session expiration messages.
- Admin dashboard.
- Admin article editor.
- Admin SEO panels.
- Admin analytics.
- Admin moderation.
- Admin media library.
- Admin newsletter tools.
- Admin review workflow.
- API error messages that become visible to users.
- System emails.
- RSS and feed metadata.
- OG image text.
- Static generated HTML.
- Sitemap titles are not visible, but URLs and lastmod must reflect English pages.
- Browser manifest fields.
- Service worker offline fallbacks.
- Install prompt copy.
- Embed-loader docs and default labels.

Each item should be classified:

- User-visible public string.
- User-visible authenticated string.
- Admin-only string.
- SEO metadata string.
- Asset text.
- Email/template string.
- API-facing error string.
- Generated artifact string.

For each classification, define:

- English copy owner.
- Translation source.
- Review requirement.
- Whether the string can be reused across locales.
- Whether it needs LTR layout testing.
- Whether it appears in generated static HTML.

This prevents the common failure where the homepage is English but login errors, comments, emails, and admin previews still show Persian.

## Content Migration Matrix

Before translating or rewriting anything, classify every existing Persian content item:

- Translate and adapt for launch.
- Translate and adapt after launch.
- Keep Persian-only.
- Rewrite as a new English-original article.
- Merge into a broader English guide.
- Split into multiple English articles.
- Retire from English plan because it is local-only.

The matrix should include:

- Persian title.
- Persian URL.
- Current traffic.
- Current backlinks if known.
- Topic.
- International relevance score.
- Evergreen score.
- Search demand estimate.
- Required rewrite level.
- Required fact update.
- Required English sources.
- Required diagrams/tables.
- English target slug.
- English target title.
- English publication priority.
- Link to equivalent English page once published.

Rewrite level can be:

- Level 1: direct translation with light editing. Rare, only for very factual pages.
- Level 2: adapted translation with new intro, headings, examples, and metadata.
- Level 3: full rewrite using Persian article as source material.
- Level 4: English-original article inspired by Persian coverage.

Most launch articles should be Level 2 or Level 3. Level 1 should not be the default.

The migration matrix should also handle taxonomies:

- Persian category to English category.
- Persian topic to English topic.
- Persian tags to English tags.
- Persian glossary terms to English terms.
- Persian author profile to English author profile.

Some Persian categories may not deserve English equivalents. The English site should not expose empty or weak categories just because they exist in Persian.

## International Taxonomy Map

The English taxonomy should be narrower, clearer, and designed around international search demand. Recommended first taxonomy:

- AI Engineering
- AI Policy and Governance
- Security
- Software Architecture
- Data Infrastructure
- Cloud and DevOps
- Hardware and Compute
- Developer Tools
- Research Notes
- Startup Systems

Each topic hub should include:

- Static intro written for English search intent.
- Canonical title and meta description.
- Top articles.
- Latest articles.
- Glossary terms.
- Comparisons.
- Related topics.
- FAQ if real visible questions are present.
- RSS link.
- Breadcrumbs.

Example hub: AI Engineering

- Primary queries: AI engineering, LLM infrastructure, AI agents, RAG, model evaluation, AI inference.
- Core evergreen articles: RAG evaluation, agent architecture, model context protocol, inference cost, data quality.
- Glossary terms: RAG, context window, tool calling, vector embedding, hallucination, evals.
- Comparisons: RAG vs fine-tuning, vector database vs search index, agent framework comparison.
- Update cycle: monthly.

Example hub: Security

- Primary queries: AI security, software supply chain security, browser security, vulnerability analysis, post-quantum cryptography.
- Core evergreen articles: prompt injection, package dependency risk, SBOM, CVE workflow, PQC migration.
- Glossary terms: SBOM, CVE, zero trust, prompt injection, supply chain attack.
- Comparisons: SAST vs DAST, passkeys vs passwords, E2EE vs TLS.
- Update cycle: monthly or event-driven.

This taxonomy should be stored in data and reflected consistently in routes, feeds, admin filters, schema, and navigation.

## English Slug And URL Rules

Slugs should be English, lowercase, stable, and descriptive:

- Use hyphens.
- Avoid stop-word-heavy slugs.
- Avoid date prefixes unless the article is event-specific.
- Avoid product names alone if the article is broader.
- Do not reuse Persian transliteration.
- Do not change slugs after indexing unless there is a redirect.

Good examples:

- `/en/article/rag-evaluation-production`
- `/en/article/model-context-protocol-technical-guide`
- `/en/glossary/tool-calling`
- `/en/compare/rag-vs-fine-tuning`
- `/en/topics/ai-engineering`

Bad examples:

- `/en/article/ai`
- `/en/article/translated-123`
- `/en/article/clean-data-persian`
- `/en/article/what-is-this-new-tech`

Redirect rules:

- If an English slug changes, old URL must 301 to the new URL.
- Do not redirect all missing English URLs to `/en/`.
- A missing English equivalent should 404 or show a useful English 404, not route to Persian.
- If a user manually switches language and no equivalent exists, send them to the nearest English topic page with a clear message, not a fake translated page.

## Cross-Language Navigation And Language Switcher

The language switcher should be honest. It should not imply every page has both languages.

For a page with an equivalent:

- Show "English" and "Persian" options.
- Switching from English goes to the Persian equivalent.
- Switching from Persian goes to the English equivalent.

For a page without an equivalent:

- Show the other language as unavailable or route to the closest topic page.
- Do not generate `hreflang` for a non-equivalent page.
- Do not canonicalize to the other language.

The language switcher label should be readable in both contexts. On English pages, use:

- `English`
- `Persian`

Do not use only flag icons. Flags represent countries, not languages, and English is not one country. Text labels are clearer and more accessible.

## English Search Experience

English site search should not return Persian results by default. It should have locale-aware behavior:

- Searching from `/en/` defaults to English content.
- Searching from Persian routes defaults to Persian content.
- A filter can include "All languages" if useful.
- Search result snippets must be English for English content.
- Search empty states must be English.
- Search facets must be English.
- Search analytics must record locale.

The backend should index English content with English tokenization rules. Persian full-text search behavior is not enough. PostgreSQL FTS or search logic should use language-appropriate configuration where possible:

- English stemming for English content.
- Persian-specific handling for Persian content.
- Locale-specific weights for title, tags, summary, body.
- Locale stored on searchable documents.

Search result ranking should favor:

- Exact title matches.
- Topic/tag matches.
- Freshness for news analysis.
- Evergreen authority for guides and glossary.
- Recency of review date for fast-changing technical topics.

English search pages can become SEO pages only if they are curated topic pages. Raw search-result pages should usually be noindexed to avoid thin indexable pages.

## Newsletter And Email Localization

The English newsletter should be a separate editorial product, not a translated version of the Persian newsletter.

Requirements:

- Locale preference stored on subscription.
- English signup copy.
- English confirmation email if double opt-in exists.
- English unsubscribe page.
- English unsubscribe confirmation.
- English newsletter archive.
- English sender name and subject-line style.
- English RSS-to-email or campaign workflow.
- Segmented campaign analytics.

Newsletter editorial formats:

- Weekly technical digest.
- Single-topic deep dive.
- Launch announcement for major English guides.
- Research note summary.
- Tool/comparison update.

Do not send Persian campaigns to English subscribers unless they explicitly opted into Persian. Do not send English campaigns to Persian subscribers by default. Mixed-language email lists damage trust and deliverability.

Subject lines should be native English:

- Good: `RAG Evaluation: Metrics That Actually Catch Failure`
- Weak: `New Teknav Article About RAG`

Every newsletter should include:

- English unsubscribe link.
- English privacy link.
- English site links.
- Correct canonical URLs.
- No Persian UI labels.

## Comments, Accounts, And Community

If comments are enabled on English articles, they need localized behavior:

- English comment form labels.
- English moderation messages.
- English report/flag reasons.
- English empty states.
- English login prompts.
- English notification text.
- Locale on comment metadata if comments are shown in mixed-language user profiles.

Moderation policy should be explicit. International comments can attract spam quickly, especially if English pages begin ranking. The launch should include:

- Rate limiting.
- Spam detection rules.
- Abuse reporting.
- Admin moderation filters by locale.
- English moderation email/templates if any.
- Clear community rules in English.

If the profile system exposes public user profiles, English readers should see English labels, English date formatting, and no accidental Persian-only trust badges.

## Author Authority And E-E-A-T Plan

For international SEO, author credibility is a core trust signal, even when it is not a simple ranking switch. English author pages should be strong enough for readers and search engines to understand expertise.

Each English author profile should include:

- English display name.
- Role.
- Coverage areas.
- Short bio.
- Longer bio.
- Editorial verification status if applicable.
- Links to articles.
- Links to external profiles where appropriate.
- Correction/contact route.
- Disclosure if AI tools are used in writing workflow.
- Profile structured data.

Article bylines should include:

- Author.
- Reviewer or editor when applicable.
- Published date.
- Updated date.
- "Reviewed for accuracy" date for evergreen guides.
- Correction notice if applicable.

Technical authority should be shown through content quality:

- Cited sources.
- Clear diagrams.
- Exact terminology.
- Versioned statements.
- Update history.
- Honest limitations.

Avoid fake authority signals. Do not invent credentials. Do not add "expert reviewed" unless a real qualified reviewer exists.

## Citation And Source Policy

English articles should use a stronger citation pattern than many Persian local articles may need. International readers will expect links to:

- Official documentation.
- Standards bodies.
- Research papers.
- GitHub repositories.
- Vendor announcements.
- CVE/NVD pages.
- Regulatory documents.
- Benchmark reports.
- Primary data sources.

Citation rules:

- Prefer primary sources.
- Use secondary sources only for context or reporting.
- Avoid citing low-quality SEO blogs.
- Cite exact versions when discussing software behavior.
- Include access date only when useful.
- Keep links local where assets are Teknav-generated.
- External links are acceptable in editorial content, but external assets are not allowed by the zero-CDN production rule.

For articles based on Persian sources or regional context, explain the source context in English. Do not assume international readers know local institutions, companies, or naming conventions.

## English Article Template Specification

A production English article template should support:

- Hero section with English title, dek, category, author, dates.
- Breadcrumbs.
- Reading time.
- Table of contents.
- Key takeaways.
- Optional executive summary.
- Body with semantic headings.
- Pull quotes or quote sharer support.
- Code blocks where needed.
- Diagrams and responsive images.
- Comparison tables.
- Glossary callouts.
- Correction notice.
- Sponsored notice if applicable.
- Author box.
- Related articles.
- Related glossary terms.
- Related comparisons.
- Newsletter signup.
- Comments if enabled.
- Social sharing.

The template should not over-decorate. English technical readers reward clarity, fast scanning, and evidence. The page should feel like a publication plus reference page, not a marketing landing page.

The template also needs structured content fields:

- `takeaways[]`
- `toc[]`
- `faq[]`
- `relatedGlossaryTerms[]`
- `relatedComparisons[]`
- `sourceLinks[]`
- `reviewedBy`
- `correctionHistory[]`

These fields help static generation, schema, internal linking, and QA.

## English Homepage Specification

The English homepage should be a production editorial surface. It should not be a language-switch page.

Recommended sections:

- Top editorial lead: one flagship article.
- Latest analysis.
- AI Engineering.
- Security.
- Data Infrastructure.
- Comparisons.
- Glossary.
- Research Notes.
- Newsletter signup.
- About/editorial trust strip.

Homepage SEO:

- Title: brand plus category scope.
- Meta description: concrete coverage areas.
- JSON-LD: WebSite, Organization, ItemList for visible article lists.
- Canonical: `/en/`.
- Hreflang: `/en/`, root Persian homepage, x-default depending on chosen default policy.

Homepage UX:

- LTR nav.
- English search.
- English categories.
- No Persian article cards unless in a deliberately labeled cross-language module.
- Fast load.
- Strong first viewport that signals "international technology analysis."

Do not fill the English homepage with all existing Persian articles through auto-translation. A smaller, curated homepage is better.

## Comparison Pages For International SEO

Comparison pages are a high-value international SEO opportunity because they match commercial and technical decision intent. They should not be shallow tables.

Each English comparison page should include:

- Clear question in the title.
- Summary verdict.
- Who should choose each option.
- Feature table.
- Cost and operational tradeoffs.
- Technical architecture differences.
- Security and compliance implications where relevant.
- Common mistakes.
- FAQ.
- Related glossary.
- Related articles.
- Last reviewed date.

Launch comparison ideas:

- RAG vs Fine-Tuning.
- Vector Database vs Full-Text Search.
- PostgreSQL vs MongoDB for AI Applications.
- Claude vs GPT for Coding Workflows.
- Passkeys vs Passwords.
- SAST vs DAST.
- Kubernetes vs Serverless for Startups.
- Edge AI vs Cloud AI.
- Open-Source LLMs vs Hosted APIs.
- Prompt Engineering vs Context Engineering.

Comparison pages must be reviewed regularly. A stale comparison page can become misleading faster than a glossary page.

## Glossary Strategy

The English glossary should be more than definitions. It should be an internal-link backbone.

Each term page should include:

- One-sentence definition.
- Plain-English explanation.
- Technical explanation.
- Why it matters.
- Example.
- Related terms.
- Related articles.
- Related comparisons.
- FAQ where useful.
- Last reviewed date.

Glossary pages should be concise but not thin. A 150-word definition may not compete internationally. A 700 to 1,200 word term page with examples, schema, and strong internal links can.

Launch glossary set:

- Retrieval-Augmented Generation.
- Vector Embedding.
- Context Window.
- Tool Calling.
- AI Agent.
- Model Context Protocol.
- Hallucination.
- Prompt Injection.
- SBOM.
- Passkey.
- Post-Quantum Cryptography.
- Semantic Search.
- Fine-Tuning.
- Inference.
- Evaluation Dataset.
- Data Lineage.
- Zero Trust.
- CVE.
- Rate Limiting.
- Observability.

Glossary definitions should not blindly copy vendor language. They should be neutral and consistent.

## Directory And Company Pages

The current Phase 15 directory can support English growth if the companies are internationally relevant. Do not internationalize the directory just to have more pages.

English directory requirements:

- English company names and descriptions.
- Organization schema.
- Clear category taxonomy.
- No Persian-only metadata.
- English filters.
- English pagination.
- English canonical and sitemap inclusion.
- Real editorial usefulness.

Good company pages can rank for:

- Company profile.
- Product category.
- Competitor comparisons.
- Regional technology ecosystem queries.

But directory pages can also become thin. The English directory should launch only with pages that have enough content:

- What the company does.
- Products.
- Technology area.
- Market.
- Sources.
- Related articles.
- Related comparisons.

If the current directory entries are mostly placeholders, keep the English directory out of the first launch.

## Web Stories And Visual Search

English web stories should be used selectively. They can support social and visual discovery, but they should not become a distraction from durable SEO.

Requirements:

- English story titles.
- English captions.
- English OG/Twitter tags.
- LTR controls and keyboard navigation.
- English canonical story URL.
- English article link at the end.
- No Persian text embedded in images.

Use stories for:

- Explaining a technical concept visually.
- Summarizing a comparison.
- Highlighting a timeline.
- Promoting a flagship guide.

Do not create stories for every article automatically. Poor stories create noise and maintenance burden.

## Embed Widgets For International Reach

English widgets can help distribution if external blogs can embed glossary cards, article cards, or company cards. The embed experience must be English and LTR:

- English default labels.
- English dark-mode labels.
- English postMessage metadata if exposed.
- LTR card layout.
- English fallback when content is missing.
- English documentation snippet.
- Locale parameter support.

Potential snippet:

```html
<script src="https://www.teknav.ir/embed-loader.js" data-locale="en" data-widget="glossary" data-slug="rag"></script>
```

The snippet should still load local Teknav assets and respect the no-CDN rule for Teknav-controlled output. External sites choose to embed it, but Teknav should serve its own widget code.

## Static Generation And Indexability Requirements

For international competition, English pages need meaningful static HTML. A crawler should see:

- English title.
- English meta tags.
- Canonical.
- Hreflang.
- Article body or substantial content.
- JSON-LD.
- Internal links.
- Breadcrumbs.

Do not rely on client-side fetches for article body content on indexable pages. If the SPA hydrates after static content, that is fine. But static HTML must carry the content.

Generated English artifacts should include:

- Article pages.
- Topic pages.
- Author pages.
- Glossary pages.
- Comparison pages.
- Directory pages if launched.
- Story pages.
- Legal/trust pages.
- Error page.
- Feed files.
- Sitemap files.

The build should fail if an English indexable page has:

- Persian `lang` or `dir`.
- Missing canonical.
- Canonical outside `/en/` for English routes.
- Persian title or description.
- Empty body.
- Missing JSON-LD for article pages.
- Missing OG image.
- External CDN asset.
- Future `lastmod`.
- Broken internal links.

## Robots, Indexing, And Crawl Budget

The English launch should be deliberate about what is indexable.

Index:

- English homepage.
- English articles.
- English topic hubs.
- English glossary terms.
- English comparison pages.
- English author pages.
- English legal/trust pages.
- English story pages if useful.
- English directory pages only if substantial.

Noindex:

- Raw search result pages.
- Login/register pages.
- Profile edit pages.
- Admin pages.
- Thin archive filters.
- Preview pages.
- Draft pages.
- Any page using fallback content.

Robots and sitemap rules should align. A page should not be submitted in a sitemap if it is noindexed. A page blocked by robots should not be expected to pass hreflang discovery.

Use Search Console after launch to monitor:

- Crawled, currently not indexed.
- Discovered, currently not indexed.
- Duplicate without user-selected canonical.
- Alternate page with proper canonical.
- Hreflang issues.
- Soft 404s.

## API And Backend Contract Outcomes

The backend contract must be explicit enough to avoid frontend seed fallback, but the exact implementation should be left to the engineering team. The product requirement is that every public, authenticated, admin, analytics, newsletter, and error surface can distinguish English from Persian content reliably.

Public content outcomes:

- English article lists must return English published content.
- English article detail surfaces must return the correct English article or a real not-found state.
- English topics, categories, tags, authors, glossary terms, comparisons, and directory entries must return English content where launched.
- English related-content recommendations must stay English by default.
- English search must search English content by default.
- English public payloads must include English SEO and trust metadata.
- English public payloads must never silently substitute Persian content.

Admin outcomes:

- Admin must make content locale visible.
- Admin must support English editorial status.
- Admin must support English review status.
- Admin must support English SEO readiness.
- Admin must support English preview readiness.
- Admin must expose missing English fields clearly.
- Admin must show language-linkage state without forcing false equivalence.
- Admin must prevent accidental publication of incomplete English content.

Analytics outcomes:

- English content engagement must be measurable separately.
- English search behavior must be measurable separately.
- English newsletter conversion must be measurable separately.
- English errors must be measurable separately.
- English dashboard views must not mix Persian and English by default.

Newsletter outcomes:

- Subscriber language preference must be respected.
- Campaign language must be explicit.
- Template language must match the campaign.
- Unsubscribe and preference pages must match the reader's language.

Error outcomes:

- English public errors must appear in English.
- English UI must not expose raw Persian backend messages.
- Stable error meaning must remain available for debugging.
- User-facing error copy must be appropriate for international readers.

## Data Ownership Outcomes

The data model must support international publishing without forcing engineers into one prescribed implementation. The important requirement is not a specific table shape; the important requirement is editorial flexibility, SEO correctness, and safe separation between Persian and English.

Required data outcomes:

- English originals must be supported.
- English adaptations from Persian source material must be supported.
- Persian-only pages must be supported.
- English-only pages must be supported.
- Real equivalent page relationships must be supported.
- Missing equivalent relationships must be allowed.
- English slugs must be stable and unique within the English surface.
- English canonical paths must be stored or derivable from trusted content state.
- English publication dates must be controlled independently.
- English review dates must be controlled independently.
- English correction history must be controllable independently.
- English metadata must not depend on Persian metadata.
- English authorship and reviewer data must be available.
- English taxonomy relationships must be available.
- English newsletter and analytics language preference must be available.
- English publication status must be available.
- English stale-content state must be available.

The implementation should be chosen after the schema is audited. The chosen model should prioritize correctness, editorial flexibility, and long-term maintainability over short-term convenience.

## Admin UX Requirements For English Publishing

Admin should make English publishing visible and controllable.

Dashboard widgets:

- English draft count.
- English articles awaiting review.
- English pages missing OG images.
- English pages missing hreflang counterpart.
- English SEO warnings.
- English articles needing review because source changed.
- English search traffic trend.

Article editor:

- Locale selector.
- Source article selector.
- Translation/adaptation status.
- English title and slug preview.
- English metadata fields.
- English OG image preview.
- English schema preview.
- English internal-link suggestions.
- English reading-level warning.
- LTR preview.
- Hreflang preview.
- Publish gate status.

Review workflow:

- Technical review.
- English copy review.
- SEO review.
- LTR layout review.
- Final editor approval.

The admin UI can remain Persian for Persian-only staff, but every English content preview and every English content field must be correctly LTR. Ideally admin supports a locale-aware editor mode.

## QA And Validation Matrix

A proper launch needs a test matrix. Manual review alone will miss regressions.

Automated validation:

- English static pages are ready.
- Check no CDN.
- Check canonical rules.
- Check hreflang rules.
- Check `lang` and `dir`.
- Check sitemap includes English URLs.
- Check feed includes English entries only.
- Check JSON-LD parseability.
- Check article images exist.
- Check internal links.
- Check no Persian UI strings on English routes from known string inventory.
- Check no Persian digits in English UI except allowed quoted content.
- Check service worker does not serve Persian fallback for English offline pages.

Manual validation:

- English homepage desktop/mobile screenshots.
- English article screenshots.
- English topic hub screenshots.
- English glossary screenshots.
- English comparison screenshots.
- English auth/profile flow.
- English newsletter signup/unsubscribe.
- English comments.
- English search.
- English 404.
- Language switcher.
- Social share preview.
- RSS feed preview.

Acceptance criteria:

- No critical issue before public indexing.
- No more than a small number of non-critical copy issues in launch content.
- All flagship articles approved by English editor.
- All generated artifacts regenerated after final content edits.

## Accessibility Requirements

English LTR must also preserve accessibility:

- Correct `lang="en"` for English routes.
- Correct heading order.
- Accessible names for icon buttons.
- English aria labels.
- Keyboard navigation in LTR order.
- Focus states visible.
- Forms labeled in English.
- Error messages associated with fields.
- Color contrast preserved.
- Tables usable on mobile.
- Code blocks scroll without breaking layout.
- Share widgets keyboard accessible.
- Story navigation keyboard accessible.

Do not leave Persian aria labels under English visible labels. Screen-reader users would experience a broken product.

## Analytics Event Taxonomy

Add locale to every relevant event:

- `page_view`
- `article_view`
- `article_scroll`
- `article_share`
- `newsletter_signup`
- `comment_submit`
- `comment_like`
- `search_submit`
- `search_result_click`
- `topic_click`
- `glossary_click`
- `comparison_vote`
- `language_switch`
- `embed_view`
- `embed_click`
- `error_capture`

Event properties:

- `locale`
- `route_type`
- `content_id`
- `translation_group_id`
- `topic`
- `author_id`
- `source`
- `utm_source`
- `utm_medium`
- `utm_campaign`
- `device_type`

Dashboards:

- English organic growth.
- English article retention.
- English newsletter conversion.
- English topic performance.
- English zero-result searches.
- English 404s.
- English hreflang health.

Metrics should guide content expansion. If English glossary terms get impressions but low CTR, improve titles/descriptions. If comparison pages convert newsletter signups, expand comparisons. If topic hubs do not earn traffic, strengthen internal links and intros.

## Launch Backlog With Milestones

Milestone 1: Strategy freeze.

- Approve English positioning.
- Approve taxonomy.
- Approve URL rules.
- Approve launch content list.
- Approve editorial workflow.

Milestone 2: Foundation readiness.

- Locale routing planned.
- Static generation plan complete.
- Data model chosen.
- String inventory complete.
- English design audit complete.

Milestone 3: Content production.

- Ten flagship articles drafted.
- Twenty glossary terms drafted.
- Eight comparisons drafted.
- Six topic hubs drafted.
- Author profiles drafted.
- Legal/trust pages drafted.

Milestone 4: Technical readiness.

- Backend contract specified.
- Admin workflow specified.
- SEO generator changes specified.
- OG generator changes specified.
- QA scripts specified.

Milestone 5: Prelaunch validation.

- English pages built in staging.
- Search metadata reviewed.
- Structured data validated.
- Feeds validated.
- Sitemaps validated.
- No CDN check passed.
- LTR screenshots approved.

Milestone 6: Launch.

- Publish `/en/`.
- Submit English sitemap.
- Submit Bing sitemap.
- Announce English launch.
- Monitor logs and indexing.

Milestone 7: Postlaunch iteration.

- Fix indexing issues.
- Update weak snippets.
- Expand content clusters.
- Original English research is planned.
- Improve internal links.

## First 90 Days Roadmap

Days 1 to 15:

- Finalize plan.
- Inventory work completed.
- Choose taxonomy.
- Select launch articles.
- Draft style guide.
- Define data model.
- Define QA gates.

Days 16 to 30:

- Prepare English content drafts.
- Prepare legal/trust pages.
- Prepare English author profiles.
- Prepare launch glossary.
- Prepare comparison outlines.
- Prepare UI string map.

Days 31 to 45:

- Locale foundation readiness becomes the main technical focus.
- Static generation readiness becomes the main indexing focus.
- English SEO artifact readiness becomes the main search focus.
- Admin workflow readiness becomes the main editorial focus.
- Staging validation begins.

Days 46 to 60:

- Complete editorial review.
- Complete LTR QA.
- Complete SEO validation.
- Complete feed/sitemap validation.
- Complete social card validation.
- Fix staging issues.

Days 61 to 75:

- Soft launch behind noindex or limited indexing if needed.
- Verify generated HTML.
- Verify analytics segmentation.
- Verify newsletter flow.
- Verify Search Console readiness.

Days 76 to 90:

- Public launch.
- Submit sitemaps.
- Start distribution.
- Monitor indexing.
- Improve pages based on query data.
- Plan next 25 English articles.

The exact dates can shift, but the order should not. Content, SEO, LTR, and backend readiness must converge before indexing.

## Operational Ownership

Assign ownership before implementation:

- Product owner: approves scope and launch definition.
- Technical lead: owns architecture, routing, build, backend contract.
- SEO owner: owns metadata, sitemap, hreflang, Search Console, query strategy.
- English editor: owns style, translation quality, final copy approval.
- Technical reviewer: owns factual correctness.
- Designer/frontend owner: owns LTR layout and visual quality.
- Backend owner: owns APIs, schema, admin workflows.
- Analytics owner: owns event taxonomy and dashboards.
- Security/privacy owner: owns legal pages, tracking, forms, account behavior.

Without ownership, internationalization becomes a collection of partial changes. The launch needs accountable owners for every surface.

## Decision Log Needed Before Build

Before implementation starts, document these decisions:

- Use `/en/` path prefix: yes/no.
- Use plain `en` or `en-US`: recommended `en`.
- Self-canonical English pages: yes.
- Hreflang method: HTML, sitemap, or both from same source.
- Content model: localized records linked by translation group recommended.
- English taxonomy: approved list.
- English launch content count.
- English fonts: system stack or local font files.
- English newsletter separate list: yes.
- English comments enabled at launch: yes/no.
- English directory included at launch: yes/no.
- English membership hidden at launch: recommended unless payments/legal ready.
- English admin permissions required: yes.
- English pages statically generated: yes.
- English search noindex policy: raw search noindex.

This decision log prevents repeated debate during implementation.

## Risks Expanded

Thin translation risk:

- Symptom: pages read like machine translation, rank poorly, and reduce brand trust.
- Mitigation: Level 2/3 adaptation, English editor approval, search-intent rewrite.

Hreflang risk:

- Symptom: Google sees alternates that are not equivalent, or alternates are missing reciprocal links.
- Mitigation: generate from translation group data, validate every build.

Canonical risk:

- Symptom: English pages canonicalize to Persian or to root homepage.
- Mitigation: route-type canonical tests.

LTR risk:

- Symptom: English UI looks broken because spacing, icons, drawers, and metadata order remain RTL.
- Mitigation: screenshot matrix and logical CSS audit.

Content freshness risk:

- Symptom: English technical guides become outdated.
- Mitigation: review dates, owner assignment, update cadence by topic.

Analytics risk:

- Symptom: English and Persian traffic are mixed, making decisions impossible.
- Mitigation: locale on events and separate dashboards.

Operational risk:

- Symptom: writers publish English drafts without proper review.
- Mitigation: role permissions and publish gates.

Legal/privacy risk:

- Symptom: English users receive unclear terms or tracking behavior.
- Mitigation: English legal pages, privacy review, localized consent where needed.

Performance risk:

- Symptom: English pages load slowly for international users.
- Mitigation: static content, bundle splitting, image optimization, no unnecessary admin code.

Reputation risk:

- Symptom: English pages look like an afterthought.
- Mitigation: curated launch, not full archive dump.

## What Not To Do

Do not:

- Auto-translate the whole Persian archive and index it.
- Use `?lang=en` as the main English URL.
- Canonicalize English articles to Persian articles.
- Add hreflang for pages without real equivalents.
- Reuse Persian OG images with Persian embedded text.
- Keep Persian emails for English subscribers.
- Show Persian comments or labels as default on English pages.
- Launch English admin fields without English preview.
- Index search result pages.
- Add external font/CDN dependencies.
- Treat glossary pages as one-paragraph filler.
- Translate legal pages literally without privacy/legal review.
- Hide weak English behind fancy design.
- Launch without Search Console and analytics segmentation.
- Launch directory pages if they are thin.
- Launch paid international membership before payments, terms, and support are ready.

This list should be used as a launch blocker checklist.

## Final Production Acceptance Checklist

The English product is ready for indexing when:

- `/en/` renders complete English static HTML.
- English routes use LTR and `lang="en"`.
- English nav/footer/search/auth/profile/newsletter/comments are English.
- English sitemap exists and is linked from global sitemap.
- English feed exists.
- English article pages have self-canonicals.
- Hreflang is reciprocal where equivalent pages exist.
- No fake alternates exist.
- English structured data matches visible content.
- English OG images exist.
- English author pages exist.
- English legal/trust pages exist.
- English analytics are segmented.
- English newsletter flow works.
- English comments and moderation work if enabled.
- English static pages pass no-CDN validation.
- English pages pass LTR screenshot review.
- English launch content is editor-approved.
- English Search Console and Bing submission steps are ready.
- Monitoring is prepared for 404s, indexing, and API errors.

Only after this checklist passes should English pages be submitted for indexing.

## Advanced Teknav Outcome Map

This section defines what Teknav must become for the English international launch. It intentionally avoids prescribing exact code structure, exact file organization, exact endpoint design, or exact implementation mechanics. The engineering team should choose the best technical path after inspecting the current codebase. The plan's job is to define the product, editorial, SEO, operational, and quality outcomes that the implementation must satisfy.

The expected end state is simple to state and difficult to execute: Teknav must become a Persian RTL publication and an English LTR international publication that share a brand and platform, but do not feel like one language is a compromised copy of the other.

### Planning Boundary

- The plan defines required outcomes.
- The plan defines product surfaces.
- The plan defines quality gates.
- The plan defines editorial expectations.
- The plan defines SEO expectations.
- The plan defines operational expectations.
- The plan defines risk boundaries.
- The plan does not dictate exact code architecture.
- The plan does not dictate exact data-model implementation.
- The plan does not dictate exact route-matching implementation.
- The plan does not dictate exact API handler structure.
- The plan does not dictate exact component structure.
- The plan does not dictate exact script structure.
- The plan does not dictate exact database migration design.
- The plan does not dictate exact test framework layout.
- The plan does not dictate exact deployment commands beyond existing project discipline.
- The plan leaves implementation decisions to the coder.

### Teknav Product Outcome

- Teknav must have a real English international surface.
- The English surface must be LTR everywhere.
- The English surface must be written in natural English.
- The English surface must be functional, not decorative.
- The English surface must support reading, search, navigation, sharing, subscription, author discovery, and trust evaluation.
- The English surface must not depend on Persian content as a visible fallback.
- The English surface must not feel like a machine-translated archive.
- The English surface must not expose Persian UI labels by accident.
- The English surface must not weaken the Persian product.
- The English surface must preserve Teknav's technical identity.
- The English surface must compete internationally through depth, clarity, and structure.
- The English surface must be able to grow independently over time.

### Teknav Brand Outcome

- Teknav must remain recognizable across both languages.
- The English brand must be understandable to non-Persian readers immediately.
- The English brand must signal technology analysis, not generic news.
- The English brand must feel serious, precise, and independent.
- The English brand must avoid local-only assumptions.
- The English brand must communicate technical credibility.
- The English brand must support author authority.
- The English brand must support editorial transparency.
- The English brand must support international sharing.
- The English brand must support long-term search trust.

### English Reader Outcome

- A reader arriving from Google must understand the page without knowing Persian.
- A reader arriving from social media must see English title, image, description, and context.
- A reader opening an English article must see English navigation and metadata.
- A reader browsing related content must stay in English unless they intentionally switch.
- A reader subscribing must receive English subscription copy.
- A reader using search must get English results by default.
- A reader viewing author pages must understand expertise in English.
- A reader viewing trust pages must understand Teknav's editorial policies in English.
- A reader encountering an error must see English error copy.
- A reader using mobile must get a polished LTR experience.
- A reader using assistive technology must get English accessible labels.

### English Route Surface Outcome

- Teknav must have an English homepage.
- Teknav must have English article listing pages.
- Teknav must have English article detail pages.
- Teknav must have English topic hubs.
- Teknav must have English category or tag surfaces where they are useful.
- Teknav must have English author pages.
- Teknav must have English glossary pages.
- Teknav must have English comparison pages.
- Teknav must have English newsletter surfaces.
- Teknav must have English legal and trust pages.
- Teknav may have English directory pages only when they are substantial.
- Teknav may have English story pages only when they are editorially useful.
- Teknav may have English widgets only when they provide real distribution value.
- Teknav must have an English not-found experience.
- Teknav must avoid fake English pages with thin or missing content.

### URL Outcome

- English URLs must be stable.
- English URLs must be readable.
- English URLs must be indexable.
- English URLs must be distinct from Persian URLs.
- English URLs must support self-canonical behavior.
- English URLs must support honest language alternates.
- English URLs must not depend on query parameters as the primary language signal.
- English URLs must not redirect missing content to unrelated Persian pages.
- English URLs must not create duplicate thin pages.
- English URLs must remain maintainable as the English library grows.

### LTR Outcome

- English pages must render left-to-right.
- English navigation must read left-to-right.
- English article metadata must read left-to-right.
- English breadcrumbs must read left-to-right.
- English tables must read left-to-right.
- English forms must read left-to-right.
- English modals must read left-to-right.
- English drawers must feel natural in LTR.
- English icons must not imply the wrong direction.
- English pagination must use correct previous and next meaning.
- English mobile layout must not carry RTL spacing mistakes.
- English code blocks must remain readable.
- English long technical tokens must not break layout.
- English screenshots must pass visual review before launch.

### Content Independence Outcome

- English articles must have English titles.
- English articles must have English summaries.
- English articles must have English bodies.
- English articles must have English headings.
- English articles must have English metadata.
- English articles must have English source context.
- English articles must have English internal links.
- English articles must have English social previews.
- English articles must have English author context.
- English articles must have English correction text where applicable.
- English articles must have English topic assignment.
- English articles must have English glossary relationships.
- English articles must have English comparison relationships where useful.
- English articles must not publish as literal unreviewed translations.
- English articles must stand alone for an international reader.

### Editorial Adaptation Outcome

- Persian source articles may be used as source material.
- English articles must be adapted for international search intent.
- English articles must explain local context when local context matters.
- English articles must remove local assumptions when they do not matter.
- English articles must prioritize clarity over literal translation.
- English articles must use internationally recognized technical terminology.
- English articles must have stronger source context where global readers expect it.
- English articles must use natural English headlines.
- English articles must use useful technical headings.
- English articles must state uncertainty clearly.
- English articles must avoid hype.
- English articles must avoid filler.
- English articles must avoid weak translated idioms.
- English articles must be reviewed before indexing.

### English Topic Outcome

- Teknav must define a smaller and stronger English taxonomy than the full Persian archive.
- English topic hubs must match international demand.
- English topic hubs must have clear editorial purpose.
- English topic hubs must connect articles, glossary terms, comparisons, and author expertise.
- English topic hubs must not exist if they have too little content.
- English topic hubs must use English labels that sound native.
- English topic hubs must avoid direct literal category translation when a better English label exists.
- English topic hubs must support internal linking.
- English topic hubs must support feeds where useful.
- English topic hubs must be updated as the library grows.

### Recommended English Authority Lanes

- AI Engineering should be a primary international lane.
- Security should be a primary international lane.
- Data Infrastructure should be a primary international lane.
- Software Architecture should be a supporting international lane.
- Developer Tools should be a supporting international lane.
- Research Notes should be used for original or high-depth work.
- Hardware and Compute should be used when Teknav can add real technical value.
- AI Policy and Governance should be used when content is analytical and sourced.
- Startup Systems should be used when content is practical and technical.
- Generic tech news should not be a primary international lane.

### AI Engineering Outcome

- Teknav must build a credible English AI Engineering cluster.
- The cluster must explain production AI systems.
- The cluster must cover RAG, agents, evaluation, model context, inference, and data quality.
- The cluster must be useful to builders.
- The cluster must include evergreen explainers.
- The cluster must include glossary support.
- The cluster must include comparison support.
- The cluster must include diagrams or tables where they improve comprehension.
- The cluster must be reviewed frequently because AI tooling changes quickly.
- The cluster must avoid shallow AI hype.

### Security Outcome

- Teknav must build a credible English Security cluster.
- The cluster must cover AI security, software supply chain risk, cryptography shifts, authentication, and vulnerability context.
- The cluster must use careful risk language.
- The cluster must avoid sensational framing.
- The cluster must provide mitigation-oriented explanations.
- The cluster must distinguish known facts from speculation.
- The cluster must include current review dates.
- The cluster must link to relevant glossary definitions.
- The cluster must be updated when security facts change.
- The cluster must prioritize reader trust over traffic spikes.

### Data Infrastructure Outcome

- Teknav must build a credible English Data Infrastructure cluster.
- The cluster must cover data quality, retrieval, storage, analytics, lineage, observability, and search.
- The cluster must connect strongly with AI Engineering.
- The cluster must explain tradeoffs for technical teams.
- The cluster must include diagrams where architecture matters.
- The cluster must include comparison pages where decision intent exists.
- The cluster must avoid vendor-only framing.
- The cluster must support both engineers and technical managers.
- The cluster must use precise terminology.
- The cluster must remain evergreen through periodic review.

### Software Architecture Outcome

- Teknav must build a practical English Software Architecture cluster.
- The cluster must focus on real system tradeoffs.
- The cluster must cover API design, observability, reliability, deployment, and maintainability when relevant.
- The cluster must support developers and engineering leads.
- The cluster must avoid abstract architecture content with no operational value.
- The cluster must include examples, checklists, and comparisons where useful.
- The cluster must connect with AI and data infrastructure content.
- The cluster must show maturity without becoming academic.
- The cluster must use plain English.
- The cluster must be updated when technology assumptions change.

### Developer Tools Outcome

- Teknav must treat Developer Tools as an evaluation lane, not a listicle lane.
- Tool coverage must explain practical value.
- Tool coverage must explain limits.
- Tool coverage must explain ecosystem maturity.
- Tool coverage must explain security or lock-in concerns where relevant.
- Tool comparisons must be fair.
- Tool pages must not feel like affiliate pages.
- Tool pages must include review dates.
- Tool pages must be updated when products change.
- Tool content must support international developer search intent.

### English Glossary Outcome

- Teknav must have an English glossary that supports search and internal linking.
- Glossary pages must be useful, not thin.
- Glossary pages must define terms clearly.
- Glossary pages must explain technical context.
- Glossary pages must include examples where helpful.
- Glossary pages must connect related terms.
- Glossary pages must connect related articles.
- Glossary pages must connect related comparisons.
- Glossary pages must use consistent terminology.
- Glossary pages must be reviewed on a defined cadence.
- Glossary pages must not copy vendor definitions blindly.
- Glossary pages must become the internal vocabulary backbone of English Teknav.

### English Comparison Outcome

- Teknav must have English comparison pages where decision intent is strong.
- Comparison pages must provide real tradeoff analysis.
- Comparison pages must state who each option is for.
- Comparison pages must include useful tables where appropriate.
- Comparison pages must be neutral.
- Comparison pages must not exaggerate differences.
- Comparison pages must include review dates.
- Comparison pages must link to relevant glossary pages.
- Comparison pages must link to relevant articles.
- Comparison pages must avoid shallow SEO templates.
- Comparison pages must be updated as products and practices change.

### English Homepage Outcome

- The English homepage must immediately communicate Teknav's international identity.
- The English homepage must feature English content only by default.
- The English homepage must prioritize high-authority clusters.
- The English homepage must include a clear lead story or flagship article.
- The English homepage must expose topic hubs.
- The English homepage must expose glossary or comparison assets.
- The English homepage must expose newsletter subscription.
- The English homepage must expose trust links.
- The English homepage must be fast.
- The English homepage must be indexable.
- The English homepage must not be a language switcher page.
- The English homepage must not be a translated Persian homepage clone.

### English Article Template Outcome

- English articles must support strong technical reading.
- English articles must support clear bylines.
- English articles must support publication and update dates.
- English articles must support reviewed-by information when applicable.
- English articles must support a table of contents where useful.
- English articles must support key takeaways where useful.
- English articles must support comparison tables.
- English articles must support diagrams and images.
- English articles must support code blocks.
- English articles must support citations.
- English articles must support correction notices.
- English articles must support related content.
- English articles must support newsletter conversion.
- English articles must support comments only when moderation is ready.
- English articles must remain readable on mobile.

### English Author Outcome

- English author pages must establish expertise.
- English author bios must be rewritten for international readers.
- English author pages must list English articles.
- English author pages must identify coverage areas.
- English author pages must explain editorial roles where relevant.
- English author pages must not invent credentials.
- English author pages must support trust.
- English author pages must support structured metadata.
- English article bylines must connect to English author context.
- English verified-author labels must be English and truthful.

### English Legal And Trust Outcome

- Teknav must have English legal and trust pages before broad launch.
- The English About page must explain Teknav to international readers.
- The English Editorial Policy must explain standards.
- The English Corrections Policy must explain how mistakes are handled.
- The English AI-Assisted Content Policy must explain AI use honestly.
- The English Privacy Policy must match actual data practices.
- The English Terms page must be understandable.
- The English Advertising Policy must exist before sponsored English content.
- Trust links must be visible from English public pages.
- Legal pages must not be literal low-quality translations.

### English Search Outcome

- English search must default to English content on the English surface.
- English search must show English snippets.
- English search must use English labels.
- English search must not show Persian results unless the user intentionally expands scope.
- English search must track zero-result queries.
- English search must support content strategy decisions.
- English search must avoid indexable thin result pages unless curated.
- English search must handle technical terms.
- English search must handle product names.
- English search must handle acronyms.

### English Newsletter Outcome

- English newsletter must be a separate reader relationship.
- English signup copy must be English.
- English subscriber language preference must be respected.
- English campaign copy must be English.
- English unsubscribe experience must be English.
- English newsletter archive must be English if launched.
- English newsletter analytics must be separated.
- Persian and English subscribers must not be mixed by default.
- English newsletter content must fit international readers.
- English newsletter should reinforce cluster authority.

### English Comment And Community Outcome

- English comments must be enabled only if moderation is ready.
- English comment UI must be English.
- English comment moderation states must be English.
- English reporting reasons must be English.
- English abuse handling must be prepared.
- English comments must not weaken site trust.
- English comments must respect account security.
- English comments must support locale-aware moderation.
- English notifications must be English where related to English content.
- English community rules must be visible if comments are active.

### English Widget Outcome

- English widgets must be LTR.
- English widgets must use English labels.
- English widgets must embed useful English content.
- English widgets must support international distribution.
- English widgets must avoid Persian fallback.
- English widgets must preserve the no-CDN product discipline where Teknav controls assets.
- English widgets must provide accessible iframe labels.
- English widgets must not create unclear security behavior.
- English widgets must be launched only when their content is strong.
- English widgets must support analytics where appropriate.

### English Directory Outcome

- English directory pages must launch only if they are substantial.
- English company pages must contain useful English descriptions.
- English company pages must provide international context.
- English directory filters must be English.
- English directory metadata must be English.
- English directory pages must not become thin indexable pages.
- English directory pages must support related articles where useful.
- English directory pages must support trust through sources.
- English directory launch can wait if content depth is insufficient.
- English directory quality matters more than page count.

### English Story Outcome

- English stories must be editorially useful.
- English stories must use English captions.
- English stories must use LTR controls.
- English stories must link back to English articles.
- English stories must not be auto-generated for every article.
- English stories must not contain Persian embedded text.
- English stories must support social discovery.
- English stories must remain accessible.
- English stories must have proper metadata.
- English stories should support flagship explainers, not replace them.

### SEO Outcome

- English pages must have self-canonicals.
- English pages must have correct language metadata.
- English pages must have correct direction metadata.
- English pages must have English titles.
- English pages must have English descriptions.
- English pages must have English Open Graph data.
- English pages must have English social images.
- English pages must have structured data that matches visible content.
- English pages must have sitemap inclusion only when indexable.
- English pages must have feeds where useful.
- English pages must avoid duplicate thin content.
- English pages must avoid fake hreflang alternates.
- English pages must avoid future-dated metadata.
- English pages must avoid missing or misleading canonical signals.

### Hreflang Outcome

- Hreflang must represent real equivalent pages only.
- English-original pages without Persian equivalents must not pretend to have Persian equivalents.
- Persian-only pages without English equivalents must not pretend to have English equivalents.
- Equivalent pages must be reciprocal.
- Language switching must match real availability.
- Hreflang data must be generated from trusted editorial relationships.
- Hreflang must not be maintained as disconnected manual fragments.
- Hreflang errors must block launch for affected high-priority pages.
- Hreflang must help users reach the right language.
- Hreflang must not be used to hide poor translation quality.

### Static Content Outcome

- English indexable pages must contain meaningful static HTML.
- English static pages must include body content where the page type requires it.
- English static pages must include metadata.
- English static pages must include internal links.
- English static pages must include visible English text.
- English static pages must not be empty shells before hydration.
- English static pages must not require remote assets.
- English static pages must not include CDN dependencies.
- English static pages must support compression.
- English static pages must remain deployable under the existing production model.

### Open Graph Outcome

- English social cards must be English.
- English social cards must use English titles.
- English social cards must use English topic labels.
- English social cards must use appropriate local assets.
- English social cards must not reuse Persian text images.
- English social cards must be readable at social preview size.
- English social cards must exist for flagship pages.
- English social metadata must match the page.
- English social previews must support international sharing.
- English social card quality must be reviewed before launch.

### Asset Outcome

- English launch must preserve zero-CDN discipline.
- English fonts must be local or system-safe.
- English images must be local where Teknav controls the page output.
- English diagrams must be optimized.
- English OG images must be generated or stored locally.
- English pages must not depend on third-party scripts.
- English pages must not depend on remote CSS.
- English pages must not depend on remote fonts.
- English pages must not depend on remote UI images.
- English asset quality must support international credibility.

### Performance Outcome

- English homepage must be fast.
- English article pages must be fast.
- English topic pages must be fast.
- English glossary pages must be fast.
- English comparison pages must be fast.
- English mobile pages must be fast.
- English pages must avoid unnecessary admin/editor weight.
- English pages must avoid unnecessary media weight.
- English pages must preserve compression.
- English pages must preserve responsive behavior.
- English pages must be tested on realistic mobile widths.
- English performance must be monitored after launch.

### Accessibility Outcome

- English pages must expose English accessibility labels.
- English pages must use correct heading structure.
- English forms must be labeled in English.
- English errors must be announced in English.
- English navigation must be keyboard usable.
- English focus states must be visible.
- English story controls must be keyboard usable if stories launch.
- English widgets must have accessible names.
- English tables must remain usable on mobile.
- English code blocks must remain readable.
- English screen-reader experience must not contain accidental Persian labels.

### Admin Outcome

- Admin must support English content creation.
- Admin must support English adaptation from Persian source material.
- Admin must support English-original content.
- Admin must support English preview.
- Admin must support English SEO review.
- Admin must support English editorial review.
- Admin must support English technical review.
- Admin must support English publication status.
- Admin must support English content filtering.
- Admin must support English missing-field visibility.
- Admin must prevent weak English publication.
- Admin must make English launch readiness visible.
- Admin must not rely on Persian seed data as English production fallback.

### Editorial Workflow Outcome

- English content must have an owner.
- English content must have a clear status.
- English content must have review accountability.
- English content must have publication readiness checks.
- English content must have search-intent review.
- English content must have technical review.
- English content must have copy review.
- English content must have metadata review.
- English content must have update cadence.
- English content must have correction handling.
- English content must have launch priority.
- English content must not enter the index before approval.

### Content Quality Outcome

- English launch content must be strong enough to represent Teknav internationally.
- English flagship articles must be deep.
- English glossary terms must be useful.
- English comparison pages must be honest.
- English topic hubs must be curated.
- English legal pages must be clear.
- English author pages must be credible.
- English newsletter copy must be native.
- English metadata must be written for English search behavior.
- English content must avoid filler.
- English content must avoid translation artifacts.
- English content must avoid unsupported claims.

### Translation Quality Outcome

- English translation must be adaptation, not word replacement.
- English translation must preserve technical accuracy.
- English translation must improve unclear source structure where needed.
- English translation must target English search intent.
- English translation must remove Persian-only assumptions where needed.
- English translation must explain Persian or regional context where needed.
- English translation must use natural technical vocabulary.
- English translation must pass human review.
- English translation must be rejected if it reads as machine output.
- English translation must be updated when the Persian source changes materially.

### Search Intent Outcome

- Every English page must know its search purpose.
- Some pages must target explainers.
- Some pages must target comparisons.
- Some pages must target definitions.
- Some pages must target technical analysis.
- Some pages must target author or brand trust.
- Some pages must target newsletter or retention.
- Pages without clear intent should not be prioritized.
- Search intent must shape the English title.
- Search intent must shape the English headings.
- Search intent must shape the internal links.
- Search intent must shape the update cadence.

### Internal Linking Outcome

- English internal links must form topic clusters.
- English articles must connect to topic hubs.
- English articles must connect to glossary pages.
- English articles must connect to comparisons where useful.
- English glossary pages must connect to related terms.
- English comparison pages must connect to supporting explainers.
- English author pages must connect to English articles.
- English homepage must connect to strong clusters.
- English internal links must use natural English anchors.
- English internal links must avoid spammy repetition.
- English internal links must help readers first.

### Analytics Outcome

- English traffic must be measurable separately.
- English search traffic must be measurable separately.
- English newsletter conversion must be measurable separately.
- English article engagement must be measurable separately.
- English topic performance must be measurable separately.
- English glossary performance must be measurable separately.
- English comparison performance must be measurable separately.
- English errors must be measurable separately.
- English 404s must be measurable separately.
- English zero-result searches must be measurable separately.
- English dashboards must guide postlaunch strategy.

### International KPI Outcome

- Teknav must know how many English pages are indexed.
- Teknav must know which English clusters earn impressions.
- Teknav must know which English pages earn clicks.
- Teknav must know which English pages have weak CTR.
- Teknav must know which English pages need updates.
- Teknav must know which English searches fail.
- Teknav must know which English pages convert subscribers.
- Teknav must know which English pages attract backlinks.
- Teknav must know which English pages cause errors.
- Teknav must use these signals to choose the next content work.

### Launch Readiness Outcome

- English homepage must be approved.
- English flagship articles must be approved.
- English topic hubs must be approved.
- English glossary pages must be approved.
- English comparison pages must be approved.
- English author pages must be approved.
- English legal pages must be approved.
- English metadata must be approved.
- English social cards must be approved.
- English sitemap must be valid.
- English feed must be valid.
- English analytics must be ready.
- English rollback plan must be ready.

### Staging Outcome

- English must be reviewed in staging before public launch.
- Staging must show realistic English content.
- Staging must show real LTR behavior.
- Staging must show static generated content.
- Staging must show social previews.
- Staging must show sitemap and feed output.
- Staging must show search behavior.
- Staging must show newsletter behavior if enabled.
- Staging must show comments if enabled.
- Staging must show error states.
- Staging must reveal Persian string leaks.
- Staging must be approved before indexing.

### Rollback Outcome

- Teknav must be able to protect Persian production if English launch has issues.
- Teknav must be able to remove English pages from indexable discovery if needed.
- Teknav must be able to pause English newsletter signup if needed.
- Teknav must be able to disable English comments if needed.
- Teknav must be able to correct English sitemap issues quickly.
- Teknav must be able to correct English canonical issues quickly.
- Teknav must be able to correct English content mistakes quickly.
- Teknav must be able to communicate English incidents clearly.
- Teknav must not require a full platform rollback for every English issue.
- Teknav must treat rollback readiness as part of launch readiness.

### Documentation Outcome

- Teknav documentation must describe the English product surface.
- Teknav documentation must describe English editorial rules.
- Teknav documentation must describe English SEO expectations.
- Teknav documentation must describe English route expectations.
- Teknav documentation must describe English API expectations without dictating code internals.
- Teknav documentation must describe English admin expectations.
- Teknav documentation must describe English validation expectations.
- Teknav documentation must describe English deployment expectations.
- Teknav documentation must keep API prefix/version language consistent.
- Teknav documentation must stay current after implementation decisions are made.

### Team Ownership Outcome

- English launch must have a product owner.
- English launch must have an editorial owner.
- English launch must have an SEO owner.
- English launch must have a technical owner.
- English launch must have a design/LTR owner.
- English launch must have a QA owner.
- English launch must have an analytics owner.
- English launch must have a security/privacy reviewer.
- English launch must have clear approval authority.
- English launch must not proceed with unclear ownership.

### Decision Outcome

- Teknav must decide what content belongs in the first English launch.
- Teknav must decide which English clusters matter first.
- Teknav must decide whether directory pages are launch-ready.
- Teknav must decide whether comments are launch-ready.
- Teknav must decide whether stories are launch-ready.
- Teknav must decide whether widgets are launch-ready.
- Teknav must decide whether any monetization appears in English.
- Teknav must decide the English style guide.
- Teknav must decide update cadence rules.
- Teknav must decide launch acceptance thresholds.
- Teknav must document these decisions before implementation begins.

### Prioritization Outcome

- English foundation must come before broad content expansion.
- English editorial quality must come before page count.
- English static indexability must come before launch distribution.
- English trust pages must come before broad international promotion.
- English author credibility must come before sensitive expert claims.
- English analytics must come before growth iteration.
- English rollback readiness must come before indexing.
- English comparison and glossary assets should support flagship articles.
- English original research should follow a strong foundation.
- English paid features should wait until legal, payment, support, and trust are ready.

### Stop Condition Outcome

- Stop if English pages show Persian fallback content.
- Stop if English pages render RTL.
- Stop if English pages lack meaningful static content.
- Stop if English canonicals are wrong.
- Stop if language alternates are fake.
- Stop if English metadata is copied from Persian.
- Stop if English social images contain Persian text.
- Stop if English legal pages are missing.
- Stop if English author credibility is missing.
- Stop if English analytics cannot be separated.
- Stop if English publication can bypass review.
- Stop if rollback readiness is absent.

### Postlaunch Outcome

- Teknav must review English query data regularly.
- Teknav must improve pages with impressions but weak clicks.
- Teknav must expand clusters that show traction.
- Teknav must update fast-changing technical pages.
- Teknav must noindex or improve weak pages.
- Teknav must use newsletter feedback for content planning.
- Teknav must use zero-result searches for glossary planning.
- Teknav must use backlinks to identify authority lanes.
- Teknav must publish original English work after the foundation is strong.
- Teknav must keep English quality higher than English page count.

### Strategic Shape Outcome

- Teknav should enter English markets as a focused technical-analysis publication.
- Teknav should not enter English markets as a translated mirror.
- Teknav should compete through depth, clarity, trust, structure, and useful assets.
- Teknav should make AI Engineering the first major authority lane.
- Teknav should support that lane with Security and Data Infrastructure.
- Teknav should use glossary and comparison pages as SEO infrastructure.
- Teknav should use author credibility and corrections policy as trust infrastructure.
- Teknav should use newsletters and feeds as retention infrastructure.
- Teknav should use static content quality as technical SEO infrastructure.
- Teknav should use no-CDN discipline as a performance and reliability advantage.
- Teknav should become a source international technical readers can cite.

## Legal, Trust, And Policy Pages

English readers need explicit trust pages:

- About Teknav.
- Editorial Policy.
- Corrections Policy.
- AI-Assisted Content Policy.
- Privacy Policy.
- Terms of Use.
- Contact.
- Advertising and Sponsored Content Policy.

These pages should be written in English, not translated literally. They should explain:

- How Teknav selects topics.
- How technical claims are reviewed.
- How corrections are handled.
- How AI tools may be used in drafting or research.
- How sponsored content is labeled.
- How user data is handled.
- How readers can contact editorial staff.

For international credibility, the footer should surface editorial policy, corrections, RSS, authors, topics, and contact.

## Rollout Phases

### Phase A: Discovery And Architecture

- Audit current routes and static generation.
- Content ownership model approved.
- English taxonomy approved.
- English typography requirements approved.
- URL expectations approved.
- Hreflang source-of-truth expectations approved.
- English SEO audit expectations approved.
- Launch content list approved.

### Phase B: LTR Foundation

- English LTR shell requirements satisfied.
- LTR visual system requirements satisfied.
- Shared component audit completed.
- English navigation and footer requirements satisfied.
- English legal/trust page requirements satisfied.
- Screenshot validation checklist approved.

### Phase C: Content Pipeline

- English article workflow ready.
- English author bio workflow ready.
- English category/topic/tag/glossary ownership ready.
- English OG image readiness process ready.
- English editorial QA checklist ready.

### Phase D: SEO And Static Generation

- English static page readiness confirmed.
- English sitemap and feed readiness confirmed.
- Hreflang readiness confirmed.
- English structured data readiness confirmed.
- English RSS discovery readiness confirmed.
- Search Console and Bing launch readiness confirmed.

### Phase E: Backend And Admin

- Locale-aware backend behavior ready.
- Locale-aware admin filtering ready.
- English SEO audit readiness confirmed.
- English preview readiness confirmed.
- Localized newsletter readiness confirmed.
- Locale analytics readiness confirmed.

### Phase F: Launch Collection

- Publish homepage, legal pages, author pages.
- Publish 10 flagship articles.
- Publish topic hubs, glossary, comparisons.
- Submit sitemaps.
- Validate indexing.
- Start distribution.

### Phase G: Scale

- Expand to 50 English articles.
- Original English reporting begins.
- English-specific tools become eligible when they support proven clusters.
- International partnerships become eligible when the English base is credible.
- Dataset/research releases become eligible when quality and maintenance are ready.
- Evaluate multi-region expansion only after English baseline works.

## Risk Summary

The largest risk is launching thin translated pages. That would create low-quality indexed content and may weaken trust. The second risk is LTR bugs that make the product look unfinished. The third risk is using hreflang incorrectly, especially adding alternates for pages that are not equivalent. The fourth risk is mixing Persian and English analytics, making growth impossible to understand. The fifth risk is translating the UI but leaving backend email templates, notifications, error states, and admin workflows Persian-only.

Mitigation is simple but labor-intensive: treat English as a product, not a translation layer.

## Final Launch Definition

Teknav English is ready when an English-speaking technical reader can arrive from Google, understand the page, trust the author, navigate related English content, subscribe to an English feed/newsletter, share an English card, and never encounter Persian UI unless they intentionally switch languages or read a Persian reference.

The desired outcome is not "Teknav has English pages." The desired outcome is "Teknav can compete internationally as an English technology analysis publication."

## References

- Google Search Central: Managing multi-regional and multilingual sites: https://developers.google.com/search/docs/advanced/crawling/managing-multi-regional-sites
- Google Search Central: Tell Google about localized versions of your page: https://developers.google.com/search/docs/specialty/international/localized-versions
- Google Search Central: Build and submit a sitemap: https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap
- Google Search Central: Search gallery for supported structured data: https://developers.google.com/search/docs/appearance/structured-data/search-gallery
- Google Search Central: Breadcrumb structured data: https://developers.google.com/search/docs/appearance/structured-data/breadcrumb
- Google Search Central: Article structured data: https://developers.google.com/search/docs/appearance/structured-data/article
- Google Search Central: Introduction to structured data: https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data
- Google Search Central: General structured data guidelines: https://developers.google.com/search/docs/appearance/structured-data/sd-policies