This tutorial walks you through copying your Web Linguist SSL certificate into your WP Engine site's Custom SSL configuration. The process takes about two minutes. You'll need to repeat it every ~60 days when your certificate renews — we'll email you each time.

Not sure why you're doing this or what it actually changes? Read our explanation of how SSL works with managed hosting providers first — this tutorial assumes you've decided to upload the certificate and just want the steps.

Before you start

Make sure your DNS records are fully verified in your Web Linguist dashboard — every record should show a green check mark. If any row is still red or pending, the certificate hasn't been issued yet and the next step won't work.

Step 1 — Find your certificate in the Web Linguist dashboard

  1. Log in to your Web Linguist dashboard.
  2. Open the website whose certificate you want to upload.
  3. Go to the Installation tab.
  4. Scroll down past the DNS records section. You'll see a collapsible section labelled SSL Certificate with an Action needed badge.
  5. Click Show on the right side of that section to expand it.

You'll now see two boxes: Certificate (full chain) and Private Key, along with the certificate's issue date and expiration date.

Step 2 — Copy the certificate

  1. Next to the Certificate (full chain) box, click the Copy button. You should see a brief "Copied!" confirmation.
  2. Keep the dashboard tab open — you'll come back to it.

Step 3 — Paste the certificate into WP Engine

  1. In a new browser tab, log in to the WP Engine User Portal.
  2. Click the environment for the site you want to update.
  3. Click Manage.
  4. Click SSL in the left sidebar.
  5. Click Add Certificate.
  6. Choose Import Certificate.
  7. Paste the certificate you just copied into the Certificate field.
  8. Don't submit yet — you still need the private key.

Step 4 — Copy and paste the private key

  1. Switch back to your Web Linguist dashboard tab.
  2. In the Private Key box, click Show to reveal it (hidden by default so it doesn't appear on-screen unnecessarily).
  3. Click the Copy button next to the private key.
  4. Switch back to the WP Engine tab and paste it into the Private Key field.
  5. Submit the form.

WP Engine will validate that the certificate and private key match, then activate the custom SSL on your site. This usually takes a few seconds.

Step 5 — Mark it as uploaded in your dashboard

  1. Return to your Web Linguist dashboard.
  2. In the SSL Certificate section, tick the checkbox labelled I have uploaded these to my hosting provider.

The badge in the section header will change from Action needed to Uploaded. This is just a confirmation for your own tracking — we use it to know whether to remind you the next time your certificate renews.

That's it — what to expect from here

WP Engine is now serving your certificate. Their renewal-failure emails will stop within a day or two, and their internal monitoring will show your SSL as valid.

About every 60 days we'll automatically issue a fresh certificate (Let's Encrypt certificates are valid for 90 days, so we renew with about a month to spare). When that happens:

  • We'll send you an email letting you know the certificate has been renewed.
  • Your dashboard's SSL section will show Action needed again.
  • You'll repeat Steps 1–5 above with the new certificate values.

The new certificate will be valid the moment we issue it (your visitors are unaffected), so there's no urgency on the upload — you have the full ~90-day window to get to it.

Something went wrong?

If WP Engine rejects the certificate or key with an error like "Key is not in PEM format" or "Certificate and key do not match," double-check that you copied the entire contents of each box (including the -----BEGIN…----- and -----END…----- lines). If you're still stuck, reach out to our support team with a copy of WP Engine's exact error message and we'll help you sort it out.

Whether you need to switch payment methods, upgrade your plan, or cancel a subscription, Web Linguist makes it straightforward from your account dashboard. This guide walks you through everything, step by step.



Log In and Open Your Subscriptions

  1. Log in to your Web Linguist account at weblinguist.com.
  2. Click your avatar icon in the top-right corner of the navigation bar (the small circle with your initial).
  3. Select “Subscriptions” from the dropdown menu. This takes you to your main Subscriptions page.

 

Your “All Subscriptions” Overview

Once you’re on the Subscriptions page, you’ll get an overview of everything tied to your account.


The All Subscriptions page in Web Linguist, showing the default payment method and upcoming invoices.


Default Payment Method

At the top of the page you’ll find a Default Payment Method section. This is the card that gets used when you first purchase a new subscription through checkout.

Important: Changing your default payment method here does not update the card on any existing subscriptions. Each subscription keeps the payment method it was originally purchased with. To update the card on a specific subscription, you’ll need to open that subscription individually — covered in the next step.

Upcoming Invoices

Further down the page you’ll see a summary of upcoming invoices across all your websites, including the billing date and amount due — a handy snapshot of what’s coming up.



Manage an Individual Subscription


To make changes to a specific website’s subscription — such as updating the payment method, changing your plan, or cancelling — click that website’s name in the tab bar near the top of the Subscriptions page.


The individual subscription page showing the current plan, payment method dropdown, and options to upgrade, downgrade, or cancel.


Changing the Payment Method

On the individual subscription page, you’ll see a Payment Method dropdown on the right side. Use this to choose which card should be charged for that subscription’s future renewals.


Upgrading or Downgrading Your Plan

Click Upgrade Plan or Downgrade Plan and follow the prompts to switch to a different tier. Changes take effect on your next billing cycle.



Step 4 — Cancelling a Subscription

Click the Cancel button on the individual subscription page. You’ll then be asked to choose how you’d like to cancel:

  • Cancel Immediately — Your subscription ends right away and you lose access to that website’s translations immediately.
  • Cancel at End of Billing Period — Your subscription stays active until the current billing period runs out. You won’t be charged again, but you keep full access until then.

 

Quick Recap

  • Log in → click your avatar → select Subscriptions
  • The All Subscriptions page shows your default payment method and upcoming invoices across all sites
  • Changing the default payment method only affects new purchases — not existing subscriptions
  • Click a website name in the top tab bar to manage that specific subscription
  • From there you can update the payment method, change your plan, or cancel
  • When cancelling, choose between immediate access loss or cancelling at the end of your billing period

Still have questions? Reach out to the Web Linguist support team and we’ll be happy to help.

Using WebLinguist with WP Engine: Required Configuration & Why It Matters

If your website is hosted on WP Engine and you’ve chosen the Full Domain (Subdirectory) DNS setup, there are a few additional configuration steps required to make everything work correctly. This guide explains what those steps are, why each one is necessary, and exactly how to get them done.

This is not a limitation of WebLinguist — it’s a consequence of how WP Engine’s infrastructure is architected, and it affects all reverse proxy services that sit in front of WP Engine sites, not just ours.

Why WP Engine Requires Special Handling


WP Engine is not a standard web host. Their platform runs on top of Cloudflare’s enterprise network, which continuously monitors and validates that your domain’s DNS is pointing to WP Engine’s own infrastructure. When you point your domain to WebLinguist’s proxy instead, WP Engine’s Cloudflare layer detects the DNS change and can deactivate hosting for your domain — producing a Cloudflare Error 1001 and taking your site offline.

The solution is to configure WebLinguist’s proxy to fetch your site content directly from WP Engine’s backend install URL (yoursite.wpengine.com) rather than routing back through WP Engine’s public Cloudflare edge. This bypasses the validation layer entirely and goes straight to your WordPress installation on WP Engine’s servers.

There are then two additional nginx-level rules that need to be added to your WP Engine environment to ensure visitor IP addresses are handled correctly and that WordPress generates correct URLs when content passes through our proxy. Both are standard, documented configurations that WP Engine’s support team handles routinely.

Let’s go through each one.

Step 1: Enter Your WP Engine Install URL as Your Origin During Setup


What it is


During WebLinguist’s DNS setup wizard, you are asked to provide your origin URL — the address our proxy uses to fetch your original site content on the backend. This value is stored in your WebLinguist account and never exposed publicly.

For most standard hosting environments (plain VPS, shared hosting), this is simply your current server IP address or hosting domain. For WP Engine, this value must be your WP Engine install URL — the direct backend address of your WordPress installation.


Why it’s needed


Your domain’s DNS record points to WP Engine’s public Cloudflare IPs (141.193.213.10 / 141.193.213.11 for Advanced Network, or their CNAME wp.wpenginepowered.com). If WebLinguist’s proxy fetches content from those addresses, it hits WP Engine’s Cloudflare edge network — which expects your domain to be registered as a custom hostname in their system. Since you’ve moved DNS away from their infrastructure, your domain is no longer registered there, and the request fails.

By entering your WP Engine install URL as the origin, our proxy connects directly to your WordPress installation on WP Engine’s servers — completely bypassing the Cloudflare validation layer.


How to find your WP Engine install URL


Your install URL follows this format:

yourinstallname.wpengine.com

You can find your exact install name in the WP Engine User Portal:

  1. Log in to your WP Engine dashboard at my.wpengine.com
  2. Click on Sites in the left navigation
  3. Click on the environment name for your website
  4. Your install name is displayed at the top of the environment overview page — it’s also visible in the URL of your dashboard page

Your full install URL will be: [installname].wpengine.com


Where to enter it


When the WebLinguist setup wizard asks for your origin URL, enter your WP Engine install URL instead of your current domain or IP address:

yourinstallname.wpengine.com

If you have already completed setup and entered the wrong origin value, you can update it from your WebLinguist dashboard under Settings → DNS Setup → Origin URL. No DNS changes are required — this is purely a backend configuration update on our side.


Step 2: Add the Real IP Header Rule to Your WP Engine Environment


What it is


An nginx configuration rule that tells WP Engine’s server to read the real visitor’s IP address from the request headers sent by WebLinguist’s proxy, rather than treating WebLinguist’s server as the visitor.

The rule looks like this:

real_ip_header X-Forwarded-For;
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;

Why it’s needed


When traffic reaches WP Engine through WebLinguist’s proxy, every request appears to WP Engine’s server as coming from a single IP address — our proxy server’s IP. Without this rule, WP Engine’s nginx has no way of knowing the actual IP address of the visitor who made the original request.

This matters for several reasons:

IP-based access rules stop working correctly. If you have Web Rules in your WP Engine dashboard that block specific IP addresses, allow only certain IPs to access wp-admin, or restrict access by country — all of those rules would be applied against WebLinguist’s proxy IP rather than the real visitor’s IP. An IP block you set up to stop a bad actor would have no effect. A restriction on wp-admin access would potentially block all visitors, or none of the ones you intended.

Country-based rules stop working correctly. Any Web Rules using country conditions would see your proxy server’s country (wherever our infrastructure is located) rather than the visitor’s actual country. A rule allowing only US traffic would block all visitors, because every request appears to come from our data center.

WP Engine’s logging and analytics become inaccurate. WP Engine’s access logs would show our proxy IP for every request rather than real visitor IPs, making traffic analysis, security auditing, and support troubleshooting much harder.

WordPress itself may behave incorrectly. Some WordPress plugins use the visitor IP for rate limiting, spam detection, personalization, or security purposes. Without the real IP being passed through correctly, those plugins operate on the wrong data.


Why the rule uses Cloudflare’s IP ranges


WebLinguist’s proxy infrastructure sits behind Cloudflare’s network (the orange cloud). This means that when our proxy makes a request to your WP Engine origin, the connection appears to come from one of Cloudflare’s IP addresses rather than our own server’s IP. The IP ranges listed in the rule above are Cloudflare’s complete published IP ranges — both IPv4 and IPv6. By telling WP Engine to trust those ranges and read the X-Forwarded-For header from them, WP Engine correctly identifies the real end visitor’s IP for every request.

This also means your actual server IP is never exposed in this configuration — which is the correct and intended behavior.


How to get this rule added


This rule cannot be added through WP Engine’s Web Rules dashboard — it requires a direct nginx configuration change. You will need to contact WP Engine’s support team and ask them to add it.

How to contact WP Engine support:

  1. Log in to your WP Engine dashboard at my.wpengine.com
  2. Click the Help icon or navigate to the support chat from any page in your dashboard
  3. WP Engine offers 24/7 live chat support — this is the fastest path

What to say to WP Engine support:

You can copy and paste the following message:

“I’m using a reverse proxy service in front of my WP Engine environment. I need the following nginx rule added to my environment [your install name] so that the real visitor IP is correctly read from the X-Forwarded-For header rather than the proxy IP. This is a standard reverse proxy configuration per WP Engine’s own documentation.”

real_ip_header X-Forwarded-For;
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;

This is a well-documented, routine request. WP Engine’s support team handles this type of configuration regularly and will typically complete it within one business day, often much faster via live chat.


Step 3: Add the X-Forwarded-Proto Header Rule


What it is


A second nginx rule that tells WP Engine’s server that the original request arrived over HTTPS, even though the connection between WebLinguist’s proxy and WP Engine’s origin may be perceived differently at the server level.

This is typically handled by WP Engine automatically for sites on the Advanced Network, but if you encounter any of the symptoms described below after setup, adding this rule resolves them.

The rule:

proxy_set_header X-Forwarded-Proto https;

Or as a Web Rule in your WP Engine dashboard, you can set a response header:

X-Forwarded-Proto: https

Why it’s needed


WordPress stores your site’s URL in its database and uses it to generate all internal links, asset URLs, and redirects. If WordPress believes the incoming request arrived over HTTP rather than HTTPS — even for a moment — it can generate links with http:// instead of https://, trigger redirect loops as it tries to enforce its own HTTPS settings, or produce mixed-content warnings in browsers.

When traffic passes through a proxy chain, the original protocol information (HTTPS) can get lost or misrepresented by the time the request reaches WP Engine’s origin server. This header explicitly preserves that information.


Symptoms that indicate you need this rule


  • Your site is redirecting visitors in an infinite loop after setup
  • Pages load but images, CSS, or JavaScript appear broken (mixed content errors in browser console)
  • WordPress is generating http:// links instead of https:// links on translated pages
  • The browser shows a “Not Secure” warning even though your domain has a valid SSL certificate

If you experience any of these after completing your WebLinguist DNS setup, contact WP Engine support and request the rule above be added to your environment alongside the real IP rule from Step 2.


Step 4 (Optional): Verify Your Web Rules Still Work Correctly


Once the nginx rules from Steps 2 and 3 are in place, any existing Web Rules you have configured in your WP Engine dashboard should function correctly again. However, it’s worth a quick verification pass — particularly for any rules that use IP address or country conditions.

To verify:

  1. Log in to your WP Engine dashboard
  2. Navigate to your environment and click Web Rules in the left navigation
  3. Review any active Access Rules that use IP address or country conditions
  4. Test those conditions by accessing your site from the expected IP or location and confirming the rule behaves as intended

If a rule is not behaving as expected after the nginx changes are in place, contact WP Engine support referencing the real IP header configuration and ask them to confirm it was applied correctly to your environment.


Summary: Complete WP Engine Configuration Checklist


Step Action Where Required?
1 Enter yourinstallname.wpengine.com as your origin URL WebLinguist setup wizard (or dashboard Settings) ✅ Always required
2 Add real_ip_header + set_real_ip_from nginx rule WP Engine support (live chat) ✅ Always required
3 Add X-Forwarded-Proto: https rule WP Engine support or Web Rules ⚠️ Required if HTTPS/redirect issues occur
4 Verify existing Web Rules behave correctly WP Engine dashboard ✅ Recommended

What About the Subdomain Setup?


If you chose the Subdomain DNS setup instead of the Full Domain setup, none of the above steps are required. Because the subdomain approach leaves your root domain record pointing directly at WP Engine’s infrastructure, WP Engine’s Cloudflare validation never detects a DNS change. Their platform continues to operate exactly as it did before. WebLinguist’s proxy only handles traffic to the language-specific subdomains you’ve set up, and WP Engine’s origin is fetched directly without any special configuration.

The steps in this guide apply only to the Full Domain (Subdirectory) setup.


Still Having Trouble?


If you’ve completed the steps above and are still experiencing issues, here are the most common culprits:

Error 1001 is still appearing — Double-check that your origin URL in WebLinguist is set to your WP Engine install URL (e.g., yourinstallname.wpengine.com) and not your old A record value or WP Engine’s public Cloudflare IPs. You can verify and update this from your WebLinguist dashboard under Settings → DNS Setup → Origin URL. Also confirm that DNS propagation has completed — changes can take up to 24 hours to fully propagate, though most providers update within a few minutes.

Site loads but wp-admin is inaccessible — This is typically an IP access rule in WP Engine’s Web Rules that is now matching against WebLinguist’s proxy IP rather than your IP. Confirm with WP Engine support that the real_ip_header rule has been applied, then check your Web Rules for any access restrictions on /wp-admin/ or /wp-login.php/.

Images or styles are missing — This usually indicates an HTTPS/mixed content issue. Add the X-Forwarded-Proto: https rule from Step 3 and clear all caches in both WP Engine’s dashboard and your browser.

WP Engine dashboard shows an SSL warning about your domain — This is expected. Because your domain’s DNS now points to WebLinguist’s proxy rather than WP Engine’s infrastructure, WP Engine’s dashboard will flag your domain’s SSL as unmanaged on their side. This is correct — your domain’s SSL is now managed by WebLinguist’s Cloudflare layer. Your site visitors see a valid, secure HTTPS connection. The warning in WP Engine’s dashboard can be safely disregarded.

If you’ve worked through all of the above and are still stuck, reach out to our support team via live chat in your WebLinguist dashboard and we’ll work through it with you directly.

This guide shows how to add Web Linguist’s language switcher inside a specific spot on your website, instead of letting it appear in a default position. Choose this method if you want full control over exactly where the language switcher shows up (for example: inside your header, navigation, or footer).

1) Open the language switcher settings

  1. Log in to your weblinguist.ai dashboard
  2. Go to License Settings
  3. Click Customize
  4. Find Display Mode and select Embedded

Once you choose Embedded, you’ll see extra options.

2) Tell Web Linguist where to place the language switcher (CSS selector)

In Embedded mode, you’ll enter a CSS selector. This tells Web Linguist which element on your page should “hold” the language switcher.

Examples of CSS selectors

  • #header (an element with id=”header”)
  • .language-container (an element with class=”language-container”)
  • nav ul
  • footer .links

Important requirements

  • The selector must match an element on every page where you want the language switcher to appear.
  • If Web Linguist can’t find your selector on a page, the language switcher will fall back to the default location: document.body
  • A valid selector is required to use Embedded mode.

Required CSS for the mount element

The element you target must have:

position: relative;

Why? The language switcher uses absolute positioning. If the parent element isn’t position: relative, it may show up in the wrong place or look misaligned.

✅ Example:

<div id="header-switcher"></div>

<style>
  #header-switcher { position: relative; }
</style>

3) Choose your embed style

After you add a selector, pick how the language switcher should look:

  • Language Names and Icons (language name + flag icon)
  • Icons Only (flags only, more compact)

You can preview both right in the dashboard.

4) Pick an accent color

Choose an Accent color to control the highlighted/active language button. This helps match the language switcher to your site’s branding.

5) Optional: Add custom CSS (language switcher only)

You can add CSS in the Custom CSS section to fine-tune the language switcher’s appearance.

Good to know:

  • This CSS applies only inside the language switcher
  • It won’t affect the rest of your site
  • Useful for spacing, button sizing, and small visual tweaks

You’re done 🎉

Save your changes, and the language switcher will appear embedded wherever your CSS selector points.

If anything looks off (or it isn’t showing where expected), double-check:

  • The selector exists on that page
  • The target element has position: relative;

Web Linguist gives you full control over what gets translated on your site. Sometimes, you’ll want to exclude specific content—like brand names, code snippets, or user-generated content—from translation. That’s where our wl-notranslate classes come in.

✅ When You Might Want to Skip Translation

Here are common cases where you may want Web Linguist to ignore text:

  • Product names or trademarks (e.g., “Nike Air Max”)
  • Dynamic user content or form inputs
  • Code samples or technical terms
  • Custom phrases that already contain multiple languages
  • Branded language you want to keep consistent

🛠️ How to Use the Ignore Classes

Web Linguist gives you two simple CSS classes to stop translation:

1. wl-notranslate

Use this when you want to exclude a block or element and everything inside it from being translated.

<div class="wl-notranslate">
  <h3>Product Name™</h3>
  <p>This name stays the same in every language.</p>
</div>

All content inside this container will be skipped by Web Linguist’s translation engine.

2. wl-notranslate-single

Use this when you want to exclude only a single element, but still translate everything around it.

<p>Try our <span class="wl-notranslate-single">ProX Dashboard</span> today.</p>

Only the ProX Dashboard text will stay untouched—everything else will be translated as usual.

🎯 Best Practices

  • Use wl-notranslate for full sections, widgets, or repeated UI blocks.
  • Use wl-notranslate-single for inline brand names or phrases.
  • Don’t overuse these classes—let Web Linguist handle most of the heavy lifting for global reach.

🧪 Need to Test It?

Just add the class, refresh your page, and preview in Web Linguist. The ignored content will stay exactly as is—no translation, no impact on layout.

Search engines like Google and Bing rely on sitemaps to understand your website’s structure. For multilingual websites, a properly configured sitemap is essential to ensure all your translated pages are crawled, indexed, and ranked in search results quickly. It also allows you to add pages that might not be found otherwise.

Why Multilingual Sitemaps Matter

  • Better Indexing – Helps search engines find every translated version of your pages.
  • Improved SEO – Supports hreflang tags and ensures correct language/country targeting.
  • More Traffic – Unlocks organic visibility in international markets.

Getting Started

  1. Open the SEO Settings
    From your Web Linguist dashboard, go to the SEO or Search Engine Settings section.
  2. Generate Multilingual Sitemap
    Select the option to create a sitemap that includes all language versions of your site.
  3. Review and Download
    Preview your sitemap to confirm all translated URLs are included. Download if needed.
  4. Submit to Search Engines
    • Upload your sitemap in Google Search Console.
    • Submit it to Bing Webmaster Tools as well.

Best Practices

  • Regenerate your sitemap whenever you add new languages or significant content.
  • Always pair sitemaps with properly implemented hreflang tags.
  • Monitor indexing status in Google Search Console to catch errors early.

A multilingual sitemap ensures your translated content is discoverable worldwide. By generating and submitting one, you help search engines connect the right users with the right language versions of your site—boosting your international SEO and visibility.

Consistency is key when it comes to brand identity. Whether it’s your product names, slogans, or technical terms, you don’t want them to be mistranslated or altered across different languages. That’s where the Glossary feature in Web Linguist comes in. It lets you define how specific words or phrases should be translated—or locked—so your brand always speaks with one voice.

Why Use the Glossary?

  • Protect Brand Names – Ensure your product or company name never changes in translation.
  • Maintain Consistency – Keep important terms identical across all languages.
  • Improve Accuracy – Guide the AI to handle industry-specific or technical language correctly.

Getting Started

(Note: This is placeholder content. Steps will be updated once the Web Linguist dashboard is available.)

  1. Navigate to the Glossary Tab
    From your Web Linguist dashboard, open the Glossary settings.
  2. Add a New Term
    Enter the word or phrase you want to control. For example:
    • Web Linguist → should never be translated.
    • Pro Plan → keep consistent in every language.
  3. Set Translation Rules
    Choose how each term should be handled:
    • Do Not Translate – Keeps the original text.
    • Custom Translation – Provide your own preferred translation.
  4. Save and Apply
    Once saved, your rules apply site-wide and will override default AI translations.

Best Practices for Using the Glossary

  • Add product names, service tiers, and slogans to maintain brand identity.
  • Review glossary entries regularly as your business grows.
  • Use custom translations for technical terms that may confuse readers.
  • Keep entries short and specific to avoid conflicts.

Your brand is unique, and it deserves to stay consistent in every market. By using the Glossary in Web Linguist, you can lock in key terms, avoid embarrassing mistranslations, and ensure your global presence feels just as strong as your local one.

The language switcher is one of the most visible features of Web Linguist. It lets your visitors quickly choose their preferred language, making your site more welcoming and user-friendly. Just as importantly, it can be styled to match your brand so it feels like a natural part of your design.

Why Customize the Language Switcher?

  • Consistency – Ensure the look and feel matches your website’s branding.
  • User Experience – A clear, intuitive language switcher improves engagement.
  • Flexibility – Choose between dropdown menus, flags, or button styles depending on your audience.

Getting Started

(Note: This is placeholder content. Steps will be updated once the Web Linguist dashboard is available.)

  1. Navigate to the Dashboard
    From your Web Linguist dashboard, look for the Language Switcher settings.
  2. Choose a Style
    Select between:
    • A dropdown menu for a clean, minimal look.
    • Flag icons for a more visual experience.
    • Text buttons for clear, simple navigation.
  3. Customize the Appearance
    Adjust colors, fonts, and sizes to match your brand’s style. Place the switcher in a visible location—commonly in the site header, footer, or lower-right corner.
  4. Preview and Save
    Once you’re satisfied, preview how the switcher looks across devices. Save your changes to apply them site-wide.

Best Practices for Language Switchers

  • Keep it easy to find—don’t bury it deep in a menu.
  • Use clear labels (avoid abbreviations that may confuse users).
  • Place it in a consistent location across your site.
  • Test on desktop and mobile to ensure it’s always easy to use.

A well-designed language switcher helps global users feel at home on your site. By customizing it to your brand, you improve both aesthetics and usability—making multilingual browsing seamless for your audience.