DEV Community: Image Splitting Field Notes

Building a Multilingual Game Guide in Astro Without Duplicate-Content Pages

Image Splitting Field Notes — Sat, 08 Aug 2026 17:31:21 +0000

Multilingual SEO pages are easy to generate and surprisingly easy to get wrong.

If every locale is a literal translation of one template, readers get awkward copy and search engines get a thin cluster of near-duplicates. If every language becomes a completely separate page, editorial updates drift and technical SEO becomes hard to audit.

I ran into that trade-off while building an Astro field guide for a newly released game. One guide query — the location and use of a specific key — needed an English page plus localized versions for Japanese, Spanish, French, German, and Traditional Chinese.

Here is the implementation pattern I used.

1. Keep page structure in Astro and editorial content in data

The page component owns the stable structure:

breadcrumb
answer summary
quick facts
route steps
FAQ
sources
related guides

Localized content lives in a typed JSON collection. Each entry carries its own locale, route, title, description, headings, steps, FAQ answers, and source note.

The dynamic route stays small:

export function getStaticPaths() {
  return guideData.guides.map((guide) => ({
    params: { locale: guide.route.split("/")[1] },
    props: { guide },
  }));
}

const { guide } = Astro.props;

This gives editors one predictable content contract while allowing each locale to use natural terminology instead of inheriting English sentence structure.

It also makes omissions visible. If a localized page is missing a route step, source note, or FAQ answer, that is a data problem rather than a hidden template branch.

2. Build one complete hreflang cluster

The English page lives at the canonical query URL. Localized versions use stable locale folders.

const alternates = [
  { hrefLang: "en-US", path: "/blue-key-location/" },
  ...allGuides.map((item) => ({
    hrefLang: item.locale,
    path: item.route,
  })),
];

The shared layout turns those entries into absolute alternate links using the production site URL. It also emits an x-default URL that points to the English guide.

Every page in the cluster references the same set of alternates. This matters more than simply placing a language switcher in the visible navigation: the HTML metadata needs to describe the relationship consistently in both directions.

Each page also receives its own self-referencing canonical. Localized pages never canonicalize back to English, because they are intended to stand as distinct language results.

3. Generate structured data from the same content

The article data already contains the information needed for several useful schema types, so I generate JSON-LD from the same source instead of maintaining a second SEO-only copy.

The page emits:

Article for the guide itself
BreadcrumbList for navigation context
FAQPage from the visible questions and answers
HowTo only when the page contains an ordered route

The conditional HowTo block is important. Adding process schema to every article would make the markup less accurate.

const routeSection = guide.sections.find(
  (section) => section.steps?.length
);

const howTo = routeSection && {
  "@context": "https://schema.org",
  "@type": "HowTo",
  name: routeSection.heading,
  step: routeSection.steps.map((step, index) => ({
    "@type": "HowToStep",
    position: index + 1,
    name: step,
    text: step,
  })),
};

Because the visible guide and JSON-LD share one data source, a route correction updates both.

4. Localize search intent, not just sentences

The most useful change was editorial rather than technical.

A guide page is not merely a translation target. Players in different languages may use different names for the same landmark, key item, platform feature, or region. A literal translation can be grammatically correct while still missing the phrase players actually search.

Each locale therefore owns:

its native title and meta description
its preferred landmark terminology
short answer wording
UI labels
source and update notes

The underlying route remains evidence-aligned across languages, but the phrasing is written for the reader in that locale.

I also keep dated evidence labels visible. Game information changes after release, so “verified on” is more honest and maintainable than presenting every fact as permanent.

5. Make production URLs part of the build

The site is static, but canonical URLs, hreflang links, sitemap entries, and JSON-LD still need the real production origin.

The build uses a single environment variable:

SITE_URL=https://beastofreincarnation.co npm run build
npm run check

That removes hard-coded development origins and makes the generated output portable across static hosts.

After building, I check the rendered HTML rather than trusting the component source:

canonical is absolute and self-referencing
every alternate URL returns 200
the cluster is reciprocal
x-default resolves
JSON-LD parses
the page is not accidentally noindex

Live example

The finished query cluster is visible in the Beast of Reincarnation Blue Key location guide. The English page links to five localized versions, and each version is generated from the same Astro page shape while retaining locale-specific copy.

The pattern is intentionally small: one component, one content contract, one alternate cluster, and one build-time origin. That has been easier to review than either duplicating page files or building a translation layer inside the component.

What I would reuse on another project

For another multilingual content site, I would keep the same boundaries:

Put layout and schema generation in components.
Put claims, steps, labels, and sources in typed content.
Give every locale a real canonical URL.
Generate a complete reciprocal hreflang cluster.
Localize the query language, not only the prose.
Validate rendered production HTML after every content expansion.

The goal is not to manufacture more URLs. It is to make each localized URL useful enough to deserve being indexed.

Disclosure

I used AI assistance to organize and edit this article. I verified the implementation details against the live Astro project and its rendered production output before publishing.

Designing a Cost-Aware AI Video Workflow: Show the Price Before Render

Image Splitting Field Notes — Sat, 01 Aug 2026 06:52:20 +0000

AI video forms often make the expensive decision feel like a cheap one. A creator chooses a model, duration, resolution, and audio mode, but the interface hides the consequence until after they press Generate.

That is more than a pricing problem. It is a product-state problem: the cost is derived from the same controls that define the output, so it should update in the same interaction loop.

This post explains the pattern I used while building an image-to-video workflow around Grok Imagine 1.5 Preview.

1. Make cost a derived field, not a checkout surprise

For the current Grok workflow, the supported duration is 1–15 seconds. The UI offers 480p and 720p. In this implementation, 480p is charged at 1.6 credits per second and 720p at 3 credits per second, rounded up to a whole credit.

The estimator can stay intentionally small:

type Resolution = "480p" | "720p";

function estimateCredits(
  duration: number,
  resolution: Resolution,
): number {
  const rate = resolution === "720p" ? 3 : 1.6;
  return Math.ceil(duration * rate);
}

The important part is not the formula. It is where the formula runs. Duration and resolution are already controlled form state, so the estimate belongs beside the Generate button and should change immediately when either control changes.

Do not calculate it only on the server and reveal it after submission. The server should still recalculate the authoritative amount, but the client estimate is what lets the user make a decision.

2. Model capabilities should shape the form

A generic video form tends to expose every control for every model. That creates impossible combinations and forces error handling to do work the interface could have prevented.

Instead, describe each model as data:

const grokImagine = {
  modes: ["image-to-video"],
  durations: Array.from({ length: 15 }, (_, index) => index + 1),
  resolutions: ["480p", "720p"],
  audio: "native",
  defaults: {
    duration: 8,
    resolution: "480p",
  },
} as const;

The form then renders only valid choices. Because this model creates video and audio together, there is no separate audio toggle. Hiding a control is better than showing a switch that does nothing.

This also reduces drift between marketing copy, the form, and the API. The same capability object can power validation, defaults, and explanatory text.

3. Design the default around a first successful result

A default is a recommendation. It should not silently consume most of a new user's allowance.

In this example, an 8-second 480p render costs 13 credits. A new account receives 20 credits, so the default can produce one full result with some room left. Moving the same duration to 720p raises the estimate to 24 credits, and the interface makes that trade-off visible before submission.

This is a useful acceptance test:

Can a new user complete the default workflow with the initial allowance?
Does changing resolution visibly change the estimate?
Does an unaffordable combination become obvious before the API call?
Is the default still long enough to demonstrate the product?

Free credits are not useful if they cannot produce a first result.

4. Put guidance next to the expensive choice

The creator should not need a separate pricing page to understand a control. Short, local guidance works better:

Start at 480p while testing motion and framing.
Move to 720p after the prompt is stable.
Keep the first clip short when exploring a new visual direction.
Describe subject motion, camera movement, and environmental motion separately.

This turns cost visibility into workflow advice instead of a warning banner.

5. Revalidate on the server

The preview is advisory. The API must normalize and validate the same settings before creating a provider task.

A safe request path is:

Parse duration as an integer.
Confirm the selected model supports that duration.
Confirm the resolution is in the model's capability list.
Recompute the cost on the server.
Check the current balance.
Deduct credits and create the asynchronous task.
Refund the deduction if the generation fails.

Client and server can share types and configuration, but the server remains authoritative.

6. Test decisions, not just controls

A useful UI test does more than confirm that a dropdown opens. It verifies the decision loop:

The 8-second 480p default shows 13 credits.
Switching to 720p shows 24 credits.
A 1-second 480p clip rounds up to 2 credits.
Unsupported durations never appear.
The submitted payload matches the estimate the user approved.
A failed generation restores the deducted balance.

These checks protect the promise the interface makes.

Live reference

The finished interaction is available in the MICT Grok image-to-video workflow. I am the builder of MICT; I am linking it as the concrete implementation discussed above, not as an independent recommendation.

Disclosure

I used AI assistance to edit the structure and wording of this article. I verified the technical details and code examples against the implementation before publishing.

Designing a Reliable Async AI Video Pipeline in TypeScript

Image Splitting Field Notes — Fri, 31 Jul 2026 03:46:32 +0000

Calling an AI video API looks simple in a demo:

Send a prompt.
Wait for a response.
Show the video.

In production, the model rarely returns a video in the original HTTP request. It creates a remote job, gives you an external task ID, moves through provider-specific states, and eventually returns either a media URL or an error. Your application has to keep user state, billing state, moderation state, and provider state consistent while that happens.

This article presents a provider-neutral reference architecture for products such as MICT, an AI image and short-video workspace. The code samples are illustrative rather than a verbatim description of MICT's production implementation. The useful part is not a particular API call; it is the set of boundaries around that call.

The real workflow is a state machine

A reliable generation request has more stages than “loading” and “done”:

request
  -> authenticate
  -> validate model settings
  -> moderate input
  -> calculate cost
  -> create and persist local task
  -> reserve or deduct credits
  -> create provider task
  -> attach external task ID
  -> poll provider
  -> normalize provider state
  -> moderate output
  -> complete or fail
  -> refund when required

Treating this as an explicit state machine gives every layer a shared vocabulary. A compact internal set is usually enough:

type GenerationStatus =
  | "running"
  | "processing"
  | "completed"
  | "failed";

Providers can keep their own vocabulary at the edge:

function mapProviderState(state: string): GenerationStatus {
  switch (state) {
    case "waiting":
    case "queuing":
      return "running";
    case "generating":
      return "processing";
    case "success":
      return "completed";
    case "fail":
      return "failed";
    default:
      return "running";
  }
}

The important design choice is that the rest of the product never branches on every provider's spelling. The adapter does that once.

Keep local and external task IDs separate

Create and persist your own task before calling the provider.

const taskId = createLocalTaskId();

await persistGeneration({
  taskId,
  userId,
  status: "running",
});

const externalTask = await provider.createTask(providerModel, input);

await attachExternalTaskId({
  taskId,
  externalTaskId: externalTask.id,
});

The local ID belongs to your product. Use it for:

authorization checks;
generation history;
credit transactions;
support references;
analytics;
idempotency.

The external ID belongs to the provider. Use it only when querying or canceling the remote job.

This separation matters when providers change, when one provider is temporarily replaced, or when a support ticket refers to a local job that never received an external task ID.

Validate settings before money moves

Different video models accept different combinations of mode, duration, resolution, aspect ratio, output count, and audio settings. Do not let the client invent those combinations.

Keep capabilities in a server-side model configuration:

type ModelConfig = {
  modes: Array<"t2v" | "i2v">;
  durations: number[];
  resolutions: string[];
  aspectRatios: string[];
  calculateCredits(input: {
    duration: number;
    resolution: string;
    outputCount: number;
  }): number;
};

Then reject unsupported values before moderation, billing, or provider submission:

if (!config.modes.includes(mode)) {
  throw new RequestError("Unsupported generation mode");
}

if (!config.resolutions.includes(resolution)) {
  throw new RequestError("Unsupported resolution");
}

Client-side validation is useful for feedback. Server-side validation is the boundary that protects your bill and your data.

Put moderation before generation

Input moderation should happen before the provider task is created and before credits are charged.

const moderation = await moderateRequest({
  userId,
  model,
  mode,
  prompt,
  imageUrl,
});

if (!moderation.allowed) {
  return {
    ok: false,
    code: moderation.code,
    creditsCharged: false,
  };
}

This avoids paying the upstream provider for a request your own policy would reject. It also lets the UI distinguish a policy decision from a technical failure.

Output moderation is a separate gate. A provider can successfully generate media that your application should not release. The output should not become completed until that gate passes.

provider success
  -> extract result URL
  -> moderate result
  -> completed

provider success
  -> extract result URL
  -> output blocked
  -> failed with a policy-safe message

Do not collapse input moderation, provider policy errors, and output moderation into one generic “generation failed” toast. They have different retry rules and support paths.

Make credit operations idempotent

The most damaging bugs in an AI generation product are often financial state bugs:

the provider rejected the request but credits stayed deducted;
polling ran twice and refunded twice;
a database write failed after the provider task started;
the browser retried a request after a network timeout.

Every charge should have a stable source key:

await decreaseCredits({
  userId,
  amount: creditCost,
  sourceType: "generation_charge",
  sourceId: taskId,
});

A refund should reference that same source:

await refundCreditsBySource({
  sourceType: "generation_charge",
  sourceId: taskId,
  transactionType: "refund",
});

The database should enforce uniqueness for the relevant source or transaction key. Application-level if (!refunded) checks are helpful, but they are not enough under concurrent polling.

You need at least two refund paths:

The provider task could not be created.
The provider accepted the task, but it later reached a terminal failure.

try {
  const external = await provider.createTask(modelId, input);
  await attachExternalTaskId({ taskId, externalTaskId: external.id });
} catch (error) {
  await refundByGenerationSource(taskId);
  throw error;
}

For terminal failure during polling:

if (status === "failed") {
  await refundByGenerationSource(taskId);
  await markGenerationFailed(taskId, publicErrorMessage);
}

When refunds are idempotent, repeated polling becomes much less frightening.

Polling should be boring

WebSockets can improve perceived responsiveness, but polling is often the most robust first implementation for provider jobs that take seconds or minutes.

The status endpoint should:

authenticate the request;
load the local generation;
verify that it belongs to the user;
return immediately for local terminal states;
query the provider only for non-terminal jobs;
normalize the result;
update local state;
return a small, stable response.

type StatusResponse = {
  status: GenerationStatus;
  progress?: number;
  resultUrl?: string;
  errorCode?: string;
  errorMessage?: string;
};

The client does not need the provider's raw payload. Raw payloads leak implementation details and make frontend behavior depend on unstable third-party schemas.

A reasonable browser loop looks like this:

async function waitForGeneration(taskId: string) {
  while (true) {
    const result = await getStatus(taskId);

    if (result.status === "completed") return result;
    if (result.status === "failed") throw new Error(result.errorMessage);

    await delay(5000);
  }
}

Production code should also stop polling when the component unmounts, pause or slow down in a hidden tab, and apply a maximum client-side wait. The job can continue on the server even if the browser stops asking.

Parse provider results defensively

Even one provider may return different result shapes across models:

{ "resultUrls": ["https://..."] }

{ "video_url": "https://..." }

{ "output": [{ "url": "https://..." }] }

Keep result extraction inside the adapter and accept only a non-empty string:

function extractResultUrl(raw: string): string | undefined {
  const result = JSON.parse(raw);
  const candidates = [
    result.resultUrls?.[0],
    result.urls?.[0],
    result.output?.[0]?.url,
    result.videoUrl,
    result.video_url,
  ];

  return candidates.find(
    (value): value is string =>
      typeof value === "string" && value.length > 0
  );
}

A provider saying success without a usable result URL is not a completed user experience. Keep the job non-terminal or move it to a clearly diagnosed failure path.

Do not let a late success overwrite a failure

Asynchronous systems can produce awkward orderings:

a job appears successful;
output moderation starts;
another process marks the generation failed;
a late update tries to mark it completed.

Use a conditional update:

update generations
set status = 'completed', result_url = $1
where task_id = $2
  and status <> 'failed';

If the update affects zero rows, reload the current state and return that state. Terminal safety decisions should win over late success events.

Preserve error categories

Users need different actions for different errors:

Error category	User action
insufficient credits	add credits or choose cheaper settings
provider unavailable	retry later
input policy blocked	revise the request
provider policy blocked	revise the request
output policy blocked	contact support only if the decision seems wrong
unknown technical failure	retry or contact support with the task ID

Return stable error codes and separately maintain a user-safe message:

throw new RequestError(
  "We could not start this generation right now.",
  "provider_unavailable",
  { creditsCharged: false }
);

Do not expose upstream account balances, internal model routes, or raw policy messages in the browser.

What to test

A happy-path video is not enough. Test the state transitions:

invalid model settings do not charge credits;
input moderation rejection does not charge credits;
provider creation failure refunds once;
provider terminal failure refunds once;
repeated status polling does not duplicate refunds;
one user cannot read another user's task;
provider success without a URL does not become completed;
output moderation failure cannot be overwritten by a late success;
terminal local states do not keep querying the provider;
unknown provider states stay recoverable.

The best tests target invariants:

one accepted generation <= one charge
one failed charged generation <= one refund
completed => usable result URL
failed-by-policy => result URL is not released
task owner => only user allowed to read status

The larger lesson

An AI video interface is a distributed system with a creative UI attached to it. The model call is only one step. The product becomes trustworthy when every other step—validation, authorization, billing, polling, moderation, and failure recovery—has an explicit boundary.

Start with a small internal state machine. Keep provider vocabulary at the edge. Give every charge a stable source. Make refunds idempotent. Treat moderation as part of the lifecycle, not a preflight checkbox. Then make polling intentionally boring.

That foundation is less glamorous than a generation demo, but it is what lets the demo become a product.

Disclosure: This article was prepared for MICT, which is referenced once as the product context for this architecture. AI tools assisted with drafting and editing; the code, claims, and final text were reviewed before publication.

The Pixel Math Behind Seamless Instagram Carousels

Image Splitting Field Notes — Sat, 18 Jul 2026 08:08:14 +0000

A seamless carousel is a geometry problem before it is an export problem.

If one portrait slide is 1080 × 1350 px, the master canvas must be an exact multiple of 1080 pixels wide:

master_width = slide_width × slide_count
master_height = slide_height

Examples:

Slides	Master canvas
3	3240 × 1350
5	5400 × 1350
7	7560 × 1350

Why seams break

The most common failures happen before slicing:

The master image was resized to a width that does not divide into whole pixels.
Text, faces, or logos sit directly on a cut boundary.
Individual tiles are resized again after export.
Filenames do not preserve the posting order.
Different compression settings are applied to different tiles.

A reliable export workflow

Choose the final slide ratio.
Multiply the slide width by the number of slides.
Add guides at every slide boundary.
Finish the composition on the single master canvas.
Export the master once.
Split it into equal horizontal sections.
Test the numbered pieces in an Instagram draft on the actual phone.

For private client artwork, the safest splitter is one that does not upload the source image. I built Image Splitter Online around that constraint: the image is processed locally in the browser, cut lines are previewed before export, and PNG, JPG, WebP, or ZIP output is available without an account.

A small implementation detail

If you are building your own splitter, distribute remainder pixels deterministically instead of rounding every tile independently. For a width W and N columns:

const base = Math.floor(W / N);
const remainder = W % N;

const widths = Array.from(
  { length: N },
  (_, i) => base + (i < remainder ? 1 : 0)
);

That guarantees the exported widths sum back to the source width. It also avoids the one-pixel gaps or overlaps that appear when every cut boundary is rounded separately.

The final check is visual: reconstruct the row from the exported files and verify it matches the master exactly before publishing.