Caching

Every translated page requires a live call to the Weglot API, so the package caches translated output per page/language. This is on by default, controlled by CacheDurationInSeconds, and its storage backend is pluggable.

The default: in-memory

Out of the box, translated pages are cached using ASP.NET Core's own IMemoryCache. This works with zero setup, but it's per-instance: if your site runs on multiple servers or processes behind a load balancer, each one keeps its own cache and independently calls the Weglot API for the same page.

Disabling caching

Set CacheDurationInSeconds to 0. Every request will then call the Weglot API live — useful temporarily while actively editing content and checking translations, but not recommended for production, both for latency and for Weglot API credit usage.

Plugging in your own cache

If you need a cache shared across instances — or just want to use a specific caching library — implement one small interface:

namespace Arjo.Umbraco.Weglot.Caching
{
    public interface ITranslationCache
    {
        Task<string?> GetAsync(string key);
        Task SetAsync(string key, string value, TimeSpan duration);
    }
}

and register it from your own site's IComposer, using Umbraco's AddUnique so it takes over from the package's default regardless of composer ordering:

public class MyWeglotCacheComposer : IComposer
{
    public void Compose(IUmbracoBuilder builder)
    {
        builder.Services.AddUnique<ITranslationCache, MyTranslationCache>();
    }
}

Your implementation just needs to satisfy GetAsync/SetAsync — wrap IDistributedCache (Redis, SQL Server, etc.), a hybrid caching library, or anything else. The package itself takes no dependency on any particular caching library, so each site installing it chooses (or ignores) its own caching strategy without ever touching the package's source.

Worked example: ZiggyCreatures.FusionCache

FusionCache is a popular hybrid cache with fail-safe and stampede-protection features beyond a plain IMemoryCache. To back the translation cache with it, entirely from your own site project:

1. Add the package to your site (not this one):

   dotnet add package ZiggyCreatures.FusionCache

2. Implement ITranslationCache against IFusionCache:

   using Arjo.Umbraco.Weglot.Caching;
   using ZiggyCreatures.Caching.Fusion;
   
   public class FusionTranslationCache : ITranslationCache
   {
       private readonly IFusionCache _cache;
   
       public FusionTranslationCache(IFusionCache cache) => _cache = cache;
   
       public async Task<string?> GetAsync(string key)
           => await _cache.GetOrDefaultAsync<string?>(key, defaultValue: null);
   
       public async Task SetAsync(string key, string value, TimeSpan duration)
           => await _cache.SetAsync(key, value, duration);
   }

3. Register FusionCache and swap it in via your own IComposer:

   public class FusionTranslationCacheComposer : IComposer
   {
       public void Compose(IUmbracoBuilder builder)
       {
           builder.Services.AddFusionCache();
           builder.Services.AddUnique<ITranslationCache, FusionTranslationCache>();
       }
   }

That's it — no changes to the package. Umbraco auto-discovers IComposers in your site's own assembly, and AddUnique takes over the ITranslationCache registration regardless of which composer runs first.

Using this kind of extension allows you to use advanced techniques like back-plane caching, eager loading, load-balanced caching and other advanced caching techniques.

What the cache key looks like

Cached entries are keyed per sourceLanguage-targetLanguage--requestUrl, for example en-fr--https://www.example.com/fr/about-us. The same page in French and Spanish are independent entries.

The request URL in the key is the scheme, host and path. The query string isn't included.

Pages that vary by query string

Because the query string isn't part of the key, /fr/search?q=shoes and /fr/search?q=hats share one cache entry. Whichever is requested first is served to both until the entry expires. If your site has pages whose content depends on the query string (search results, filtered listings, paging), set CacheDurationInSeconds low enough for that to be acceptable. Alternatively, plug in a custom cache that skips caching for keys containing those paths.

Failed translations are cached too

If a Weglot call fails (for example, the plan's word limit has been reached), the visitor gets the untranslated page, and that untranslated page is cached for the normal cache duration like any other result. After fixing the cause, translated pages can take up to CacheDurationInSeconds to come back. Restart the site to clear the default in-memory cache immediately.

Publishing changes

The cache isn't cleared when you publish content. An edited page shows its old translation until its cache entry expires (up to CacheDurationInSeconds later). Keep the duration short if editors need to see translated changes quickly, or clear your cache store after a large publish.