Blog posts by Linh Doan Cuu

Cheapskate AI Translator: Because Translation Should Not Require a Second Mortgage

Thu, 15 Oct 2026 08:06:38 GMT

There is a particular kind of software project that begins with a detailed architecture document, a product roadmap, and a carefully assembled budget.

This is not that kind of project.

This project began with a simpler question:

Can I create language versions in Optimizely CMS without paying more for an LLM than I absolutely have to?

The answer is now an open source add-on: Cheapskate.AITranslator.

You can find the source code on GitHub and install the published package from the Optimizely NuGet feed.

The honest motivation

I am a cheapskate.

Not in the charming, coupon-clipping sense. In the practical engineering sense. If a free tier, a generous quota, or a small amount of careful request batching can do the job, I would prefer that to adding another monthly AI bill to the household budget.

The goal is not to avoid paying for good services forever. The goal is to pay as little as I can get away with while still delivering useful translations and a maintainable CMS workflow.

That means the add-on is designed around choice:

Google Gemini-compatible chat completions
GroqCloud-compatible chat completions
Microsoft Azure Translator
DeepL API Free
Custom OpenAI-compatible providers

Some providers offer free tiers, some offer free quotas, and some are inexpensive enough to be useful when a free option is not appropriate. The add-on does not assume that one provider, one pricing model, or one API will remain the best choice forever.

What the add-on does

Optimizely content editors can create draft language versions from the editor and choose whether to translate them with AI after the drafts are created.

The add-on can:

Create all missing language branches or one selected target language
Keep the new versions as drafts rather than publishing them
Optionally follow linked content in ContentArea properties
Translate language-specific text and Rich Text content
Preserve HTML structure while translating visible text
Run translation in the background after draft creation
Use different providers through one CMS settings screen

The workflow is intentionally modest. It creates drafts, starts translation work, and reports the job status. It does not pretend that an automated translation should bypass editorial review.

That last part is important. A translation engine can be very good and still occasionally produce something that makes a human editor stare at the screen for a while. Drafts are a useful place for that staring to happen.

The small trick that saves API calls

The add-on can combine multiple translatable properties into one JSON request instead of making one API request per property.

Without batching, a page with a title, teaser, body, call to action, and several blocks can turn into a small parade of API calls. That is inefficient, costs more, and can hit provider rate limits faster than necessary.

With batching enabled, the worker groups translation entries into bounded requests according to configured input and output token limits. The provider receives a structured payload, translates the values, and returns the translated entries for the background worker to write back to the draft.

In plain English:

Fewer trips to the API means fewer opportunities for the API to say, "Please slow down."

Batching does not remove provider limits, and it does not make an unlimited service out of a limited one. It simply uses the available quota more sensibly. The request-size limits remain configurable because different providers have different capabilities and pricing rules.

Why support several providers?

Because depending on one provider is an excellent way to discover that provider's outage page at the worst possible moment.

More seriously, different projects have different constraints:

A project may already have an Azure subscription and prefer Azure Translator.
A developer may want to use a free Gemini or GroqCloud quota.
A team may prefer DeepL for a particular language pair.
An organization may have its own OpenAI-compatible gateway.
A provider's model, pricing, quota, or terms may change.

The add-on keeps the CMS workflow stable while allowing the translation backend to change. Provider credentials and options live in CMS settings rather than in source control, and the custom provider option gives developers room to connect a compatible internal service.

This is not Optimizely Language Manager

A very important clarification: Cheapskate.AITranslator is not intended to replace Optimizely's official Language Manager add-on.

Language Manager is the official product for teams that need its supported translation-management workflow, integrations, governance, and product support. This add-on has a narrower and more developer-oriented purpose.

Cheapskate.AITranslator brings the implementation into the developer's control. The source code is available, the behavior can be inspected, and the add-on can be customized for a particular Optimizely CMS solution.

That may mean changing:

Which content properties are translated
How linked content is traversed
How prompts are written
Which provider is called
How batches are sized
How translation jobs are queued or reported
Which editorial safeguards are required

If your project needs an officially supported translation-management product, use Language Manager. If your project needs a small, inspectable starting point that your team can adapt, this add-on may be useful.

It is not a product-versus-product argument. It is a choice between a supported official solution and a source-controlled developer tool with a smaller scope.

Open source is the point

The most valuable part of this add-on is not the skate icon or the settings page. It is the ability to see what happens between clicking Create Language Versions and saving a translated draft.

Developers can review the code, change the translation rules, add provider behavior, adjust batching, and fit the workflow to their own content model. The add-on is deliberately not a sealed box that asks everyone to accept the same assumptions.

That also means responsibility comes with the freedom:

Review generated translations before publishing.
Protect provider credentials.
Check provider terms and quotas.
Test prompts and content types in a non-production environment.
Keep the add-on aligned with the CMS version used by the project.

Cheap is good. Cheap and mysterious is less good.

Getting started

The project targets Optimizely CMS 13 and .NET 10 on the main branch. The legacy CMS 12 implementation remains on the CMS-12-base branch.

Install the CMS 13 package with:

dotnet add .\YourCmsProject.csproj package Cheapskate.AITranslator --version 2.0.0

Then configure a provider under Settings > AI Translator, open localizable content in the editor, and use the Create Language Versions command.

The resulting versions are drafts. The AI translation runs in the background when enabled, and the editor remains responsible for the final content review.

Final accounting

The philosophy is simple:

Use the provider that fits the project.
Use free quotas where they are enough.
Batch requests so the quota lasts longer.
Keep the workflow in developer-controlled source code.
Spend money when spending money is actually justified.

That is the entire cheapskate strategy. It is not glamorous, but neither is discovering a surprisingly large AI invoice after a bulk translation job.

Cheapskate.AITranslator is open source under the MIT license: a small Optimizely add-on for teams that want draft language creation, optional AI translation, multiple provider choices, and a little more control over where the money goes.

Drag-and-Drop Reordering for Commerce Media Collection in Optimizely Commerce Connect

Wed, 05 Aug 2026 09:48:55 GMT

Optimizely Commerce Connect ships a polished asset editor for the CommerceMediaCollection property on catalog entries. It lets editors add, remove, and reorder media assets directly in the edit view — a solid baseline for most projects. Reordering is done via "Move Up" and "Move Down" buttons in the grid, which is perfectly fine when you have a handful of assets.

For some projects, though, editors need to manage dozens of images per product — product shots, lifestyle images, detail crops, downloads — and clicking a button 30 times to move an asset to the top becomes a real workflow problem. Drag-and-drop row reordering is the natural solution. This post walks through how to add it by extending the built-in Commerce editor rather than replacing it.

The Property

The CommerceMediaCollection property is declared on EntryContentBase and typed as ItemCollection<CommerceMedia>. Each CommerceMedia item carries a SortOrder integer that controls display priority on the front end — carousels, image galleries, download lists. Whatever order the editor sees in the CMS is what the front end is supposed to render.

[UIHint("commercemediacollection")]
public virtual ItemCollection<CommerceMedia> CommerceMediaCollection { get; set; }

The built-in editor already renders this as a dgrid with drag-handle affordances — the visual infrastructure for drag-and-drop is present. Wiring it up for internal row reordering and making sure SortOrder is written correctly afterward is the implementation work.

Approach: Extend, Don't Replace

Optimizely Commerce Connect Asset Collection's editor descriptor sets up column definitions, thumbnail formatters, item converters, and the dialog flow for adding assets. Rather than reimplementing all of that, the approach is to register a custom descriptor that runs last, inherits everything the Commerce descriptor configured, and only swaps out the client-side widget class.

The widget itself extends CommerceMediaCollectionEditor and overrides the minimum needed: how the grid's DnD layer is wired, how sort order is written after a drag, and whether columns are user-sortable.

Step 1 — Register a Custom Editor Descriptor

Optimizely CMS resolves editor descriptors by (TargetType, UIHint) pair. The CommerceMediaCollection property carries [UIHint("commercemediacollection")], so the custom descriptor must declare the same UIHint. EditorDescriptorBehavior.PlaceLast ensures it runs after Commerce's built-in descriptor, so all Commerce-specific metadata is already applied before we override just the widget class name.

using EPiServer.Commerce.SpecializedProperties;
using EPiServer.Shell.ObjectEditing;
using EPiServer.Shell.ObjectEditing.EditorDescriptors;

[EditorDescriptorRegistration(
    TargetType = typeof(ItemCollection<CommerceMedia>),
    UIHint = "commercemediacollection",
    EditorDescriptorBehavior = EditorDescriptorBehavior.PlaceLast)]
public class CommerceMediaDndEditorDescriptor : EditorDescriptor
{
    public override void ModifyMetadata(
        ExtendedMetadata metadata,
        IEnumerable<Attribute> attributes)
    {
        base.ModifyMetadata(metadata, attributes);
        metadata.ClientEditingClass = "myproject/editors/CommerceMediaDndEditor";
    }
}

Step 2 — Create a Protected Shell Module

The Dojo AMD path myproject/editors/CommerceMediaDndEditor must resolve to a real file. That means registering a Dojo package called myproject via a protected shell module.

modules/_protected/MyProject.Commerce.UI/module.config:

<?xml version="1.0" encoding="utf-8"?>
<module name="MyProject.Commerce.UI" clientResourceRelativePath="">
    <dojo>
        <packages>
            <add name="myproject" location="ClientResources" />
        </packages>
    </dojo>
    <clientModule>
        <moduleDependencies>
            <add dependency="CMS" />
            <add dependency="Commerce" />
        </moduleDependencies>
    </clientModule>
</module>

Source file tracking: modules/_protected/ is typically gitignored because NuGet restores add-on packages there. Keep your source in a separate tracked directory (e.g. ShellModules/_protected/) and copy it at build time:

<ItemGroup>
    <ShellModuleSource Include="ShellModules\_protected\**\*" />
    <Content Remove="ShellModules\_protected\**\*" />
    <Content Include="@(ShellModuleSource)">
        <Link>modules\_protected\%(RecursiveDir)%(FileName)%(Extension)</Link>
        <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
        <CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
    </Content>
</ItemGroup>

<Target Name="CopyCustomShellModules" BeforeTargets="Build">
    <Copy
        SourceFiles="@(ShellModuleSource)"
        DestinationFolder="$(MSBuildProjectDirectory)\modules\_protected\%(RecursiveDir)"
        SkipUnchangedFiles="true" />
</Target>

Explicit module registration: EPiServer Shell 12.x auto-discovery matches module directories to assemblies by name. A module named MyProject.Commerce.UI with no correspondingly-named assembly is skipped. Register it explicitly via IConfigurableModule:

using EPiServer.Framework;
using EPiServer.Framework.Initialization;
using EPiServer.ServiceLocation;
using EPiServer.Shell.Modules;
using Microsoft.Extensions.DependencyInjection;

[InitializableModule]
[ModuleDependency(typeof(EPiServer.Shell.UI.InitializationModule))]
public class CommerceUiModuleRegistration : IConfigurableModule
{
    public void ConfigureContainer(ServiceConfigurationContext context)
    {
        context.Services.Configure<ProtectedModuleOptions>(options =>
        {
            if (options.Items.Any(x => x.Name == "MyProject.Commerce.UI"))
                return;

            options.Items.Add(new ModuleDetails
            {
                Name = "MyProject.Commerce.UI"
            });
        });
    }

    public void Initialize(InitializationEngine context) { }
    public void Uninitialize(InitializationEngine context) { }
}

Note: Do not set Assemblies in ModuleDetails to your main web assembly. This module is purely client-side (JavaScript + module.config) — no C# shell controllers. Pointing Assemblies at the main project assembly causes EPiServer Shell to re-process it under its own application-part rules, which conflicts with ASP.NET Core's existing registration of that assembly and breaks ViewComponent discovery. Omit Assemblies for client-only modules.

Step 3 — The Custom Dojo Widget

The widget has three jobs:

Enable internal row DnD — epi/shell/dnd/Source (the DnD source class used by the grid) does not self-accept by default when accept type strings are configured. Commerce media items don't carry a recognized typeIdentifier, so the type-matching check fails for same-source drops. Wrapping checkAcceptance with dojo/aspect's around restores the standard behaviour for internal drags while leaving external drop handling (adding assets from the DAM) completely unchanged.
Write sequential SortOrder values — After a drag, every item needs a SortOrder that matches its new visual position. The custom model override handles the move and renumbers all items 1, 2, 3, … in one atomic update, firing itemsChanged exactly once with the final correct state.
Disable column header sorting — Clicking a column header in the grid would re-sort rows by that column's data without saving, creating a mismatch between what the editor sees and what is stored. Marking all columns sortable: false prevents this.

define([
  "dojo/_base/declare",
  "dojo/aspect",
  "epi-ecf-ui/contentediting/editors/CommerceMediaCollectionEditor",
  "epi-ecf-ui/contentediting/editors/model/CommerceMediaCollectionEditorModel",
], function (
  declare,
  aspect,
  CommerceMediaCollectionEditor,
  CommerceMediaCollectionEditorModel,
) {
  // Extended model: moves the item in the array and assigns sequential
  // SortOrder values across all items in a single atomic update.
  var ShiftReorderModel = declare([CommerceMediaCollectionEditorModel], {
    moveItem: function (item, target, before) {
      // Suppress itemsChanged from the first splice (remove)
      this._itemsUnchanged = true;
      var fromIdx = this._itemModels.indexOf(item);
      this._itemModels.splice(fromIdx, 1);

      // Suppress itemsChanged from the second splice (insert)
      this._itemsUnchanged = true;
      var toIdx = this._itemModels.indexOf(target);
      toIdx =
        toIdx === -1
          ? this._itemModels.length // dropped past last row → append
          : before
            ? toIdx
            : toIdx + 1;
      this._itemModels.splice(toIdx, 0, item);

      // Renumber: SortOrder 1, 2, 3, … in array order
      this._itemModels.forEach(function (m, i) {
        m.sortOrder = i + 1;
      });

      // Fire once with the final correct state
      this.emit("itemsChanged", this.get("items"));
    },
  });

  return declare([CommerceMediaCollectionEditor], {
    modelType: ShiftReorderModel,

    // Disable column header sorting so grid order always reflects stored order
    _getGridDefinition: function () {
      var columns = this.inherited(arguments);
      for (var col in columns) {
        if (columns[col]) {
          columns[col].sortable = false;
        }
      }
      return columns;
    },

    // Wire internal DnD and restore self-acceptance for same-source drops
    _setupDnD: function () {
      this.inherited(arguments);

      var dndSrc = this.grid.dndSource;
      this.own(
        aspect.around(dndSrc, "checkAcceptance", function (original) {
          return function (source, nodes) {
            // Allow reordering within the same grid
            if (source === this) {
              return true;
            }
            return original.apply(this, arguments);
          };
        }),
      );
    },
  });
});

Place this at ShellModules/_protected/MyProject.Commerce.UI/ClientResources/editors/CommerceMediaDndEditor.js (the MSBuild target copies it to modules/_protected/ at build time).

End Result

Editors open a catalog entry, switch to the Assets tab, and drag rows to reorder media. The grid updates immediately. On save, each asset's SortOrder reflects its position in the grid — 1 for the first row, 2 for the second, and so on. No separate admin page, no property changes, no base class modifications.

The solution can be applied to any ItemCollection<CommerceMedia> property in the codebase with the correct UIHint.

File Checklist

File	What it does
CommerceMediaDndEditorDescriptor.cs	Registers the custom widget for ItemCollection<CommerceMedia>
CommerceUiModuleRegistration.cs	Registers the shell module explicitly so auto-discovery doesn't skip it
ShellModules/_protected/MyProject.Commerce.UI/module.config	Declares the myproject Dojo package
ShellModules/_protected/MyProject.Commerce.UI/ClientResources/editors/CommerceMediaDndEditor.js	The custom editor widget
MyProject.csproj (MSBuild target)	Copies shell module source to modules/_protected/ at build time