Skip to main content
SellLikeLocal
Request a localisation review

interface.localisation

Translating an interface is half of it. The other half is where the words land.

SellLikeLocal LTD translates the buttons, menus, forms, hints, notifications and error messages inside a product, then works through what the new text does to the screens it arrives on: what still fits, what wraps, what is cut, and which formats have to change for the region you are entering.

Request a localisation reviewExplore localisation examples
demonstrationone label · button.save · three states
checkout · delivery

Delivery address

CancelSave changes
The screen as it is drawn today. The button was sized around the label it holds, which is the quiet assumption every design makes.
checkout · delivery · translated

label cut at the edge

The same label after translation, longer than the one it replaces. The button keeps the width the design gave it, so the end of the label is simply gone.
checkout · delivery · adapted
The layout adapted to the text rather than the other way round: the row stacks, the button is allowed to grow, and the whole label survives at any length.

Translated text is drawn as a grey bar everywhere on this site. No language, locale or market is confirmed for this company yet, and setting a sentence in one would be a claim we are not entitled to make. The length is the part a layout has to survive, so length is what is shown.

services

Four kinds of work, ordered one by one

Nothing here is bundled. You can take one of these, or all four, and the scope, the price and the timescale are set out in writing before any of it starts.

strings

Interface String Translation

Buttons, menus, form labels and helper text, notifications and error messages, translated with the job of each element and the screen it sits on in front of us. Terminology is agreed with you first, then held to across every screen in scope.

you send
Your resource files as your team keeps them, and the designs or screenshots that show where each string appears.
you receive
The same files, translated, with a list of queries wherever a string cannot be settled without more context.

layout

Layout Adaptation

What the translated text does to the design: where it wraps, where it is cut, which controls have to grow, which rows have to stack, and whether a screen still holds together when a label is much longer than the one it replaced.

you send
The designs, or screenshots of the screens in scope alongside the string list.
you receive
Annotated designs. Each note names the element, says what happens to it and suggests what to do instead.

qa

Localisation QA

A pass over the built screens looking for strings left untranslated, text that is cut or overlapping, terms used differently from one screen to the next, writing direction problems, and formats that do not match the agreed locale.

you send
Whatever way of seeing the screens your team is comfortable with: a build, a test environment, or recordings and screenshots.
you receive
A report. Each finding, the screen it appears on, and what we suggest doing about it.

code

Optional Code Implementation

Making the agreed changes in the code itself. It is a separate item, and it happens only when it is written into the agreed scope. Without it the work ends with files, annotated designs and the report, and your own team makes the changes.

you send
Whatever your team judges appropriate for an outside contributor to work in, settled case by case.
you receive
The changes, described so that your own reviewers can go through them.

Every one of these is described at greater length, with what it does not cover, on the Services page.

practice

Localisation in practice

These problems are far easier to agree on when you can watch them happen. Everything below is a demonstration built from invented material: no client work appears anywhere on this site.

demonstrationinvented screen · live layout

The same label, carrying the same meaning, written at a different length. Drag the slider, or focus it and use the arrow keys.

+0%
row
one line
label above the field
one row
button
whole label visible

The label still fits the button that was drawn for it, and the row is unchanged.

checkout · delivery

source string: “Save changes”

What the same screen is then read for

  • untranslatedStrings that never reached the file, or reached it and came back unchanged.
  • overflowText cut off, text overlapping, and controls pushed out of the row they belonged to.
  • terminologyThe same idea named one way on one screen and another way two screens later.
  • directionAlignment, reading order and directional icons in a right-to-left layout.
  • formatsDates, numbers, addresses and phone fields that do not match the agreed locale.

layout.direction

LTR and RTL: what turns round, and what must not

Changing the direction of a document changes the order in which a screen is read. It does not turn every element on it into its own reflection, and treating it as if it did is one of the commonest ways a right-to-left layout goes wrong.

schematicsame markup · dir attribute only
dir="ltr"

1,240 · IMG-0184.src

Left to right. The mark opens the bar, the back arrow points to where the reader came from, and the primary control leads the row.

dir="rtl"

1,240 · IMG-0184.src

Right to left, from the same markup. Flow and alignment follow the direction, while the mark, the count and the file reference keep theirs.

mirrored

  • Reading order, and therefore the order of the controls in a row.
  • Text alignment, and the side a label sits on relative to its field.
  • Directional icons: back arrows, next arrows, progress, indentation.
  • The side a panel, drawer or menu opens from.

left alone

  • The mark and any logo: it keeps its own construction.
  • Photographs and illustrations, unless the picture itself implies direction.
  • Numerals, and anything written as code or a file reference.
  • Media controls and other symbols whose meaning is fixed, not directional.

Both panels above are schematic. They show how a layout responds to direction and say nothing about which languages this company works in: none are confirmed, and which ones a project covers is agreed in writing for that project.

formats.date

Local formats, set out for one locale we can check

A format is a decision, not a detail. Below is en-GB in full, because it is the locale this site can state without asking anyone. Every other market is confirmed for that market.

formats.date

The order of the parts

In en-GB the day comes before the month, so 04/09/2026 is 4 September 2026. The same six digits are read in a different order under other conventions, which is why the written format belongs in the scope rather than in an assumption carried over from the locale the product was built in. Where a date has to be unmistakable, the month is spelled out.

formats.phone

The dialling code, and the field around it

The international dialling code for the United Kingdom is +44, and the national number follows it without its leading zero. A field built around that is not automatically a field that holds another country's numbers: length, grouping and whether a leading zero is dropped all belong to the locale. The field opposite belongs to the demonstration, holds no number, and is not a way of contacting anybody.

formats.address

Which fields exist at all

The parts of an address, the order they are asked for in and which of them are optional are the format. A form built for the United Kingdom asks for a postcode and offers an optional county; a form built elsewhere asks for parts this one has no field for, and has no use for parts it does. Translating the labels of the wrong set of fields does not make it the right set.

demonstrationinvented form · en-GB
checkout · en-GB

Delivery date

04/09/2026dd/mm/yyyy

Address line 1

Address line 2 (optional)

Town or city

County (optional)

Postcode

Mobile number

+44

An invented checkout, drawn to show the field set en-GB actually asks for. It is not a form and nothing in it can be filled in.

One locale is on this page, and it stops there. Formats for any other market are confirmed for that market, in writing, project by project. There is no single format that covers several countries at once, and nothing above should be read as one.

markets

Tell us your target market

This site publishes no list of languages, locales or markets. What a project covers is settled with you and written into the scope before work starts, and if the answer for a particular market is no, you will hear that plainly rather than late.

Request a localisation review

deliverables

What you receive

Three things, and which of them arrive depends entirely on what was ordered. The scope names them one by one, so there is never a question afterwards about what was meant to be in the handover.

demonstrationinvented content throughout
translated resource file
btn.save
nav.orders
err.card
hint.postcode

Translated resource files

Your files, returned in the shape they arrived in, with the keys untouched and the strings translated. Anything that could not be settled without more context comes back as a query rather than as a guess.

annotated design
note

Annotated designs

The screens with notes attached to the elements that need a decision: what the translated text does there, and what we suggest instead. Written to be read by a designer and a developer without a meeting in between.

localisation QA report

Localisation QA report

Every finding with the screen it was found on and what we suggest doing about it, so the list can be worked through, argued with, or handed straight to whoever fixes it.

Changes made in the code, and notes on putting them in, are part of the handover only when implementation is in the agreed scope. Otherwise the work ends at the files, the designs and the report, and your own team decides what to do with them.

process

How we work

Five steps, in this order, every time. The second one is the one that matters: nothing begins until the scope, the price and the timescale exist on paper.

  1. brief

    You tell us where you are going

    The target markets, the product, and the designs and language files as they stand, with enough context to know what each string is for.

  2. scope

    We agree the scope in writing

    Languages, the screens covered, which of the four kinds of work are included, what you receive, the price and the timescale. Nothing starts before this is settled.

  3. work

    Translation and adaptation

    The strings are translated against the agreed terminology, and the adaptation work chosen in the scope is carried out on the screens in scope.

  4. review

    The agreed check

    The localisation QA pass runs over the screens in scope, in the way and to the depth the scope describes.

  5. handover

    Handover, and implementation if it was included

    Files, annotated designs and the report come back with the findings. Changes are made in the code only where implementation was written into the scope.

What we need from you at each step, and what happens when the scope changes halfway through, is set out on the Process page.

testing

Testing and usability, described honestly

Localisation work produces opinions about screens. It is worth being clear about what those opinions are worth before you buy any.

When we suggest moving a control, splitting a row or rewording a label, that is a proposal based on what the translated text does to the layout. It is a hypothesis: something that can be put in front of users and shown to be right or wrong. It is not a measurement, and we do not present it as one.

User testing and any assessment of what a change does to conversion are separate work. They need their own scope, their own method and their own agreement, because they answer a different question from the one localisation answers, and answering it badly is worse than not answering it.

We make no claim about studies we have not run, results we have not measured or growth we cannot demonstrate. If a page ever tells you a change will lift your sales, it should be treated with suspicion, including on this site.

agreed.separately

  • What is being tested, and what result would count as an answer.
  • How it is measured, over what period, and by whom.
  • Who recruits participants, and what they are asked to do.
  • What happens if the result says the current design was better.

faq

Questions we are asked

Eight of them, answered without figures: prices, timescales and the number of revisions belong in a written quotation for your project, not on a page written before we have met you.

What do you need from us to start?

The designs or screenshots of the screens in scope, the language files as your team keeps them, and enough context to know what each string does - which control it sits on and what the user is doing at that point. A note on which screens matter most helps as well. We do not ask for passwords or access to your live systems in a first enquiry.

Which languages can you work in?

This site publishes no list. Publishing one before it is confirmed would be a promise rather than information, and promises of that kind are exactly what a localisation supplier should not be making. Tell us the market you are heading for and you will get a plain answer for that market, including a plain no where that is the answer.

Can we order the translation only, or the check only?

Yes. The four kinds of work are ordered separately and priced separately. A localisation QA pass can be ordered on its own, including on screens that are already live and translated, and what to do with the findings is decided afterwards.

How is the length of the translated text taken into account?

It is treated as a property of the design rather than as something discovered at the end. During translation, the length a string has to live within is known and taken into account. During layout adaptation, each control is looked at against the longest label it will now have to hold. During the check, the built screens are read again for anything that was cut, wrapped or pushed out of place in practice.

What is in the localisation QA report?

A list of findings: what was found, the screen it was found on, and what we suggest doing about it. Strings left untranslated, text cut or overlapping, terms used inconsistently between screens, direction problems and formats that do not match the agreed locale. How deep the pass goes, and over which screens, is set in the scope.

Do you make the changes in our code?

Only when implementation is written into the agreed scope. It is a separate item, and without it the work ends with translated files, annotated designs and the report, which your own team then applies. Saying so plainly avoids the common misunderstanding that a localisation order includes somebody editing the product.

How is the price worked out?

From the language, the number of screens and how much of the work you are ordering. It is calculated for your project and set out in a written quotation before anything begins. The quotation gives the full price in pounds sterling with tax included, and nothing is added to it afterwards. This site names no prices, because a price invented for a web page is not a price.

How are timescales and terminology agreed?

Both before the work starts. The timescale goes in the same written quotation as the price and runs from the point at which the last material has arrived, since that is when the work can actually begin. Terminology is agreed as a list first - the terms your product uses and how they should be rendered - and then held to across every screen in scope, which is what stops the same idea being named two different ways in two different places.

request

Request a localisation review

Tell us what the product is, where it is going and what state the material is in. You will get a written answer covering what we would do, what it would cost in pounds sterling and how long it would take.

files

There is no upload on this site. Files would have to be received and stored somewhere, and there is nowhere here to put them, so rather than draw a control that does nothing: attach your designs and language files to the email this form opens, or send a link to wherever they already live.

delivery

The form does not send anything itself. It writes your request out and hands it to the email programme on your device, and you send it from there. The finished text also stays on the page, ready to copy, in case that programme does not open.

or simply write

The form is a convenience, not a requirement. An email covering the same ground is just as welcome: sale@likelocal.sale

If you are weighing up more than one, name them all and say which comes first.

There is no upload on this page. Attach the designs and language files to the email this form opens, or send us a link to wherever they already live.

What you would like us to do

Please do not send passwords or access to your live systems in a first enquiry. Nothing we need at this stage requires them.

Pressing this writes your request out and opens the email programme on this device with it already in the message. You read it over and send it yourself. This page sends nothing, and the finished text appears below either way, ready to copy.