Localisation 5 August 2026
The Difference Between Static and Dynamic Website Localisation
Does a site keep its text in files or in a database? That single question settles from the outset how long the translation process takes, which tools it needs and how updates will be handled.
Before you start translating a site, there is a technical question to answer: where does this site get the text you see on screen? The answer concerns more than the developers. Where the text sits determines directly which tool will be used to extract it, how many people the process will involve and how the updates six months from now will be managed.
Contents
The distinction between static and dynamic websites is one of the two fundamental distinctions that determine complexity in web localisation; the other is the distinction between front end and back end (Jiménez-Crespo 2024, pp. 176-177). On a static site the structure stored on the server is much the same as the structure that appears in the browser. On a dynamic site, by contrast, the page is assembled from a database the moment the request arrives.
Below we set out how the two structures work, how they change the translation workflow and which questions you should ask when you request a quotation. The aim is not to teach code; it is to put the buyer of translation in a position to ask the right question.
How does a static website work?
Static sites carry the logic of the early days of the WWW. Each page sits on the server as a separate HTML file; when a user calls up the address, that file is sent as it is. If the content rarely changes, the structure is fast and predictable. From a localisation point of view its clearest advantage is that the text to be translated is countable and fixed.
Sites of this kind can be downloaded with mirroring tools such as HTTrack, or preserved in archives such as the Wayback Machine (Jiménez-Crespo 2024, p. 177). In other words, the source files can be gathered in one go. The translator opens the files in an ordinary translation memory tool, the tags are protected and only the text that will be displayed is edited. The files are then moved into the new language folder.
Against that, static sites call for links to be redirected by hand, folder names to be reorganised and images with text baked into them to be handled one by one. The real limitation, though, is updating: if a single sentence changes on the source site, the file goes back to the translator and is uploaded to the server again. The longer the cycle, the wider the content gap between languages grows.
How does a dynamic website work?
On a dynamic site the page is not sitting there ready in advance. When a user calls up an address, the server sends a query to the database, pulls the content, merges it with a template and sends the result to the browser as HTML. The request carries not just the address but also information such as location, language preference and earlier interactions (Jiménez-Crespo 2024, p. 177).
This structure is built on a server language such as PHP, Python or Ruby together with a database such as MySQL. Management is usually handled by a content management system such as WordPress, Drupal or Joomla. The text to be translated no longer sits in a file but in records, which leaves the extraction work to plugins and connectors.
From a localisation point of view, this means the link between page count and workload is broken. A product template is a single file, yet it feeds thousands of product records. The fixed wording in the template is translated once; the product descriptions move along a separate stream. Mixing the two streams is one of the most common budgeting mistakes.
The distinction between client side and server side
Dynamic sites divide in two among themselves. On the client side the code is written in HTML, CSS or JavaScript and runs inside the browser; its access to the operating system is limited. On the server side the code runs on the server and the developer can use whichever programming language is preferred (Jiménez-Crespo 2024, p. 177).
AJAX is a client-side technique that updates only part of a page without refreshing the whole of it. Maps, video lists and tabbed content work this way. The consequence for localisation is this: the text in these sections may not appear in the page source and can easily be missed in a visual check.
On the server side, the text mostly comes from inside PHP files or from the database. The user can see only the HTML output that is produced, not the code. That makes it hard to work out from the outside where the source text is kept. When you are defining the scope of a translation, asking the developer for a content inventory is far safer than guessing.
Front end and back end: where is the text really?
The front end is the layer you see on screen, and it is the main target of localisation. The back end is the layer that governs how the site works, the files, the forms and the way data is stored. The book also calls these two the “surface” and “deep” structure (Jiménez-Crespo 2024, p. 176).
The back end is assumed to hold no content for localisation; in fact accessibility labels and the metadata that search engines read live there. If you set the translation scope by eye alone, page titles, image alternative texts and form error messages can be left in the source language. Gaps of this kind are usually noticed only after the site has gone live.
Fortunately this layer is not hard to see. When the source code is displayed from the browser’s developer menu, a good part of the back end becomes readable. A quick scan of the source code before localisation brings to light most of the text that needs translating but has not made it onto the list.
How do static and dynamic sites change the cost?
The per-word translation rate is similar in both structures. The difference shows up in preparation, integration and maintenance. On a static site setup is cheap and updating expensive; on a dynamic site setup takes more effort and updating is cheap. The table below sums up this balance.
When you decide, it is sounder to look at the total cost over two years rather than the one-off cost. On a site that is updated several times a year, the engineering expense that piles up with a static structure can overtake the initial investment in a dynamic setup before long. Conversely, on a campaign page that will never change, heavy infrastructure is an unnecessary burden.
| Criterion | Static site | Dynamic site |
|---|---|---|
| Where the text lives | Inside HTML files | In database records |
| Extraction method | Direct transfer of the files | Plugin, connector or XLIFF export |
| Link redirection | Mostly by hand | Largely automatic |
| Update burden | Files exchanged again at every change | Only the changed records are queued |
| Where it suits | Small brochure and campaign sites | Catalogue, blog and shop sites |
Which structure suits which project?
If there are few pages and the content rarely changes, a static structure is still a reasonable choice. There is no point in building heavy infrastructure to open a fifteen-page corporate brochure site in two languages. The real risk here is not technical; it is that scope risks go undocumented.
On a site that carries a product catalogue, a blog or user reviews, by contrast, content flows constantly. In a structure like that, dynamic infrastructure and a continuous localisation workflow are all but obligatory. Content management systems mostly offer ready-made solutions for multilingual management, and this has pushed costs markedly down across the industry (Lynch 2006).
There is a third case in between: sites that look static but whose pages have been duplicated one by one by hand. These are the most laborious group, because the repeated text is scattered across the files. On a site like this, simplifying the structure before translation begins may save more in the long run than the translation budget itself.
Questions to settle before the quotation
For a localisation quotation to be accurate, the supplier has to know the structure of the site. Otherwise the quotation looks at the word count, misses the engineering share, and extra items appear as the work goes on. The answers to a handful of questions close off most of the uncertainty at the outset.
What infrastructure does the site run on? Is there a content management system, and which version? How much of the text is in templates and how much in records? Is there text embedded in the images? Which file do the forms and error messages come from? These five questions are enough to draw the scope correctly on most projects. For a detailed preliminary review you can reach us through our contact page.
The Türkiye context
In Türkiye the sites of small and medium-sized businesses are generally dynamic structures built on off-the-shelf themes. That is a good starting point for opening up to several languages; some themes, however, embed the Turkish text straight into the template file. On a site like that, menu and button labels sit not in the database but in the code, and automatic extraction skips them.
The second point concerns the structure of the language. Because Turkish is agglutinative, forms such as “Ürün”, “Ürünler” and “Ürünlerimiz” cannot be derived from a single source string. Pluralisation templates that come from English mostly give broken results in Turkish. In sentences assembled dynamically, the problem becomes more visible still.
The third is legal text. Forms that collect data from users require a privacy notice and explicit consent fields under KVKK. These texts cannot be a word-for-word translation of the English version; they are rewritten in line with local legislation.
What does this mean for you?
If you are opening your site to a foreign market, documenting the structure before you ask for a translation quotation both speeds the work up and cuts down the surprises that come later. The sequence below is a practical starting point that works on most projects.
- Note down in writing the infrastructure of the site and the content management system.
- List the pages to be translated; decide whether you will leave campaign and archive pages out of scope.
- Collect images and videos with embedded text in a separate list.
- Do not forget form fields, error messages and automated e-mails.
- State the update frequency; a site that changes monthly needs a different workflow from one that changes once a year.
Once you have prepared this list, the quotations you receive become comparable. You can find the scope of our services on our translation services page, and for a sample scoping exercise you can use the quotation form.
This article is for general information only and is not legal advice.
Frequently asked questions
How do I tell whether my site is static or dynamic?
The most practical method is to look at the address bar and the source code. If the address contains characters such as a question mark and an ampersand, or if the site is managed with a content management system, it is most likely dynamic. If the pages end with a fixed .html extension, the odds are that it is static.
Is a static site cheaper to translate?
If the volume of text is the same, the translation fee will be similar. The difference lies in the preparation and delivery stages: on a static site link redirection and folder organisation are done by hand, so the engineering share rises, whereas on a dynamic site this work is largely automated by a plugin or a connector.
Can a translator break the code on a dynamic site?
Not with the right setup. Translation tools protect the tags and the script code in HTML and XML files and show only the text that will appear on screen. The risk arises where text is copied and pasted by hand outside the tool.
How are product descriptions translated if they are in the database?
The content management system can export these records in an interchange format such as XLIFF, or send them to a translation platform through a connector. Choosing this route rather than screenshots or manual copying prevents the work being repeated at the next update.
Sources
- Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, pp. 176-178.
- Microsoft (2003). Computer Dictionary, 5th edition, p. 564.
- Lynch, C. (2006). An assessment of content management systems and the costs of multilingual sites.