Frequently Asked Questions

Below are answers to the most common questions we receive from site owners and content managers working with Lang Forge. If your question is not listed here, contact our support team for help.

Installation and Setup

Lang Forge requires WordPress 5.8 or higher and PHP 7.4 or higher. It works with any standard WordPress hosting environment, including shared hosting, VPS, managed WordPress hosts (like WP Engine, Kinsta, and Flywheel), and local development tools like MAMP and Local. No special PHP extensions or server modules are required beyond what WordPress itself needs.

We recommend running only one multilingual plugin at a time. While Lang Forge includes a WPML compatibility layer that prevents function conflicts, having two multilingual plugins active simultaneously can cause unexpected behavior with URL routing and language detection. When Lang Forge detects that WPML’s core (SitePress) is active and configured, it shows a yellow warning notice on every wp-admin page and an inline conflict callout at the top of Lang Forge → Languages explaining the specific tables and behaviours that collide. If you are migrating from WPML, Polylang, or TranslatePress, activate Lang Forge and deactivate the previous plugin in the same session. See the “Recipe: Migrating from WPML to Lang Forge” section for a detailed migration guide.

Yes. Lang Forge can be activated on individual sites within a Multisite network. Each sub-site manages its own set of languages and translations independently. Network-wide activation is also supported, allowing the network administrator to activate Lang Forge across all sites at once. PRO licenses on Multisite count each sub-site as one site toward your plan limit.

This is almost always a user role issue. Only users with the Administrator role see the full Lang Forge menu by default. If you are logged in as an Editor or another role, you will see a limited set of menu items. If you are an Administrator and still do not see the menu, deactivate and reactivate the plugin from the Plugins page. This forces WordPress to re-register the menu items.

Translation Workflow

Yes. Each language has its own independent translation draft. You can open translations in multiple browser tabs and work on them simultaneously, or assign each language to a different team member. There is no locking mechanism that prevents parallel translation — each translation is a separate WordPress post with its own editing state.

Go to the taxonomy list page (for example, Posts > Categories) and click on any term. In the edit screen, you will see a Language & Translations section similar to the one on posts. Click Create Translation to create a translated version of the term with its own name, slug, and description. Translated terms are linked together, so when a visitor views the Spanish version of a category archive, they see Spanish posts filed under the Spanish category name.

Yes. Translated posts support the same scheduling feature as any regular WordPress post. Open the translation in the editor, set the desired publication date and time in the Publish panel, and click Schedule. The translation will go live at the scheduled time. The language switcher will not show the language for that page until the scheduled post actually becomes published.

If you have PRO, the Content Diff feature detects the changes and flags all linked translations as “needs update.” You will see an orange warning icon in the post list and a yellow banner in the translation editor showing exactly what changed. On the Free plan, there is no automatic detection — you need to check manually whether translations are still current after editing the original.

The AI Quality Check (QA Check button in the Visual Editor toolbar) is a second-opinion reviewer. It compares the original with your translation and flags missing content, meaning changes, tone mismatches, and grammar issues, then offers one-click fixes. Treat it as a spellchecker-style assistant, not an authority — for marketing copy and brand voice you should still review every suggested fix before applying. For factual content (product specs, technical documentation), suggestions are usually safe to accept directly.

When you click “Apply fix” on an issue, the translation is updated both on the server and live in the editor so you see the change immediately. You can always edit the applied text further before saving.

Yes. Comment auto-translation is a PRO feature. When enabled, comments left on the original post are automatically translated and displayed on the corresponding translated post. You can configure this in Lang Forge > Settings > Comments. Comments are translated using AI credits, and the original comment is always preserved — the translated version is stored separately.

URL Format

You can change it, but you need to handle redirections manually. When you switch URL formats, previously indexed URLs (like yoursite.com/es/about/) will stop working. Install a redirect plugin such as Redirection or Safe Redirect Manager and create 301 redirects from every old translated URL to the new format. Without redirects, visitors arriving from search engines or bookmarks will see 404 errors.

The Directory format requires “pretty permalinks” to be enabled (anything other than the Plain setting in Settings > Permalinks). If you are using plain permalinks, Lang Forge automatically falls back to the Parameter format (?lang=es). We recommend switching to a pretty permalink structure (such as Post name) for the best URL appearance and SEO performance.

Lang Forge supports Unicode slugs, so translated URLs can contain characters from any script — Cyrillic, Chinese, Arabic, and others. WordPress encodes these characters in the URL using percent-encoding, which is standard web behavior. For readability, most browsers display the decoded characters in the address bar. You can also manually set a Latin-character slug for any translation if you prefer ASCII-only URLs.

Compatibility

Lang Forge is compatible with any properly coded WordPress theme. It does not depend on specific theme features or frameworks. Themes that use standard WordPress functions for menus, widgets, and content display work without any adjustments. Page builder themes (Elementor, Divi, Beaver Builder, Astra, GeneratePress, OceanWP, and others) are fully supported. If your theme uses hardcoded text instead of translatable strings, those pieces of text will need to be handled through custom CSS or theme file edits.

Yes. Lang Forge works with WP Rocket, W3 Total Cache, LiteSpeed Cache, WP Super Cache, and other popular caching solutions. Each language version of every page is cached as a separate entry. If you use the Directory URL format, caching works out of the box because each language has a unique URL path. If you use the Parameter format, make sure your caching plugin is configured to vary the cache by the lang query parameter.

Yes. CDNs cache pages by URL, and since each language version of a page has its own unique URL (whether through directories, subdomains, or parameters), the CDN will cache and serve each language independently. No special CDN configuration is needed for the Directory or Subdomain URL formats. If you use a cookie-based language detection alongside a CDN, make sure to configure the CDN to bypass cache for requests with the Lang Forge language cookie, or disable cookie-based detection entirely and rely on URL-based language routing.

Performance

Lang Forge is optimized for sites with many languages. Sites with 10 to 15 languages operate without any noticeable performance difference compared to a monolingual site. Even sites with 30 or more languages work well because language detection and content routing happen once per page request, not once per element. The main consideration with many languages is content management overhead — translating a single post into 30 languages is a significant amount of work.

Lang Forge uses an in-memory translation cache that is populated once per request. The initial language detection query is a single lightweight database lookup. After that, all translation mappings for the current page are cached in memory and reused. On a typical page, this adds one to two database queries total — far fewer than most plugins add. If you have an object cache (Redis or Memcached), even the initial query is served from cache on subsequent requests.

License and Billing

Yes. Go to your account dashboard on the Lang Forge website and deactivate the license on the old site. Then activate it on the new site using the same license key. License transfers are instant and can be done as many times as needed within your plan’s site limit.

When your annual license expires, the plugin continues to work and all translations, settings, and content remain stored. Free-plan access is enforced again at runtime: AI translation, bulk jobs, Translation Memory REST/import/export, Content Diff, QA checks, Analytics, and import/export stop executing until the license is renewed. Unlimited languages, Glossary, and WooCommerce translation remain available on Free. Existing PRO data is preserved and becomes active again after renewal; it is not deleted during downgrade.

Direct admin REST/AJAX writes follow the same active language set as the UI and frontend. Free no longer caps the number of active languages, but unknown or inactive language codes still return language_not_available / HTTP 403 instead of mutating _lf_language through a hidden request.

No. All AI credits — the one-time welcome pack granted on your first-ever Forge purchase, plus any pay-as-you-go packs you buy — live in a single account-level pool that carries forward indefinitely. There’s no monthly reset, no billing-cycle boundary, no “use it or lose it” allowance: your plan is license-only, credits are separate and always yours until spent.

Migration

Migration time depends on the size of your site. A small site with 50 to 100 posts and two languages typically takes 30 to 60 minutes. A large WooCommerce store with thousands of products and five languages may take several hours, mostly for review and verification. The actual data migration step is fast — Lang Forge reads the WPML translation tables and recreates the language links automatically. WPML Translation Management jobs, Advanced Translation Editor history, translator assignments, baskets, and review statuses are not converted into Lang Forge workflow state. See the “Recipe: Migrating from WPML to Lang Forge” section for the complete process.

Yes. The migration process for Polylang is similar to WPML migration. Lang Forge reads Polylang’s taxonomy-based language assignments and term relationships to reconstruct translation groups. Since Polylang stores language data as custom taxonomies, the migration is straightforward. Go to Lang Forge > Tools > Migration and select “Polylang” to start the automated migration.

Yes. Go to Lang Forge > Tools > Migration and select “TranslatePress.” TranslatePress stores translated page content in dictionary tables instead of separate translated posts, so Lang Forge creates translated post copies, links them to the source post, imports default/active language settings, preserves the “hide default language in URL” setting, and imports TranslatePress gettext strings into String Translation. Review the migrated pages before deleting TranslatePress.

If you use the same URL format in Lang Forge as you had in your previous plugin, your URLs will remain identical and there will be no impact on SEO. For example, if WPML was configured with the Directory format (/es/about/) and you choose Directory in Lang Forge, all translated URLs stay the same. Hreflang tags and sitemaps are regenerated by Lang Forge, so search engines will continue to see the same language signals.

AI Credits

The estimates shown in the confirmation popup before any AI action are very accurate — they are based on the actual word count of the content being translated. The final credit usage may differ by one or two credits at most for very long content, because the AI may need slightly more or fewer tokens than estimated. The estimate is always shown before you confirm, so there are no surprises.

Lang Forge’s AI translation uses the Forge API exclusively (GPT-4o-mini) and does not support plugging in third-party translation APIs directly. This design ensures consistent quality, glossary enforcement, and Translation Memory integration across all translations. If you prefer a specific translation engine, you can export your content as XLIFF, translate it externally, and import the completed translations back into Lang Forge.

Every Lang Forge installation uses ChatGPT 4o mini — a fast, cost-efficient OpenAI model running on our servers. You can confirm this on Lang Forge → Settings → Translation Model. No configuration, no API keys to manage on your side.

Credits are only consumed when the translation is actually generated. The confirmation popup before each AI action shows the estimated cost and your remaining balance. Once the translation is generated, you can review, edit, and even discard it — but the credits for that generation are already used. If the translation fails due to a network error or timeout, no credits are deducted.

Language Detection

If Auto-detect Language is off (the default), visitors always land on the site’s default language unless they click a specific language in the switcher or navigate to a language-prefixed URL. If Auto-detect is on, Lang Forge reads the Accept-Language header from the visitor’s browser on their first page load. If the browser’s preferred language matches one of your active non-default languages, Lang Forge issues a 302 redirect to /{lang}/. A lf_autodetect_done cookie (1-year lifetime) is set at the same time, so the redirect runs only once per browser — the visitor can navigate back to / later and stay on the default language. POST requests, AJAX calls, and anything without an Accept-Language header (search engine crawlers) are never redirected, so SEO signals are not affected.

Previously, enabling Auto-detect would serve translated content at the canonical URL (for example, German content at example.com/). That broke hreflang annotations (the / URL was in two languages at once), confused search engines into merging or de-duplicating pages, and made the default-language URL un-cacheable by CDN. The 302 redirect approach keeps every language on its own URL, so hreflang, canonical URLs, duplicate-content signals, and page caching all behave correctly.

—