Document home

Web files and applications

Web Page and Application Localization

Soluling localization tool and service can localize most web applications and pages. Compared to a desktop or mobile applications, web applications are much more diverse. There are dozens of different technologies and frameworks you can use to create web applications. There are also multiple ways you can use a single technology. A typical web application contains markup files, script files, resource files, and data storage. Data storage can be either a database, a rest API, an XML file, or a JSON file. Each markup file can contain embedded scripts, or it can use external script files. They can either be scripts that are run on the server-side (C#, Visual Basic, PHP, Ruby, Java) or scripts that are run on the client-side (JavaScript or C#).

All these items might contain strings that need to be localized. If your application is internationalized correctly, you need, in most cases, only to localize the resource files and sometimes strings in the database. If your application is not properly internationalized, you may need to localize the markup and script files as well.

As you can see, a web application can have strings in several locations and formats. All these diversity impacts to localization, and because of it, there is no single way to localize web applications. The web application can use resource files just like a desktop application, but they can also use databases, text files, and other storages to hold translations. It can be a major effort to localize a large web application. Fortunately, Soluling makes this a lot easier. Soluling supports several kinds of web application localization methods. They are:

Using resource files

This is the most popular way to localize web applications. When using this method, you don't hardcode any strings to markup or code files. Instead, you use the resource files of your web development framework. All frameworks support some kind of string resource files. Angular uses .xlf or .xmb, React uses .json, .NET and Blazor use .resx, PHP uses .po, Rails uses .yaml and Java EE uses .properties. This method is used in most localization tutorials and documentations.

Localized files

Although using resources works perfectly, it faces a few problems. Most obvious is the fact that you no longer can hardcode any strings into your markup or code files (except when working with Angular templates). This makes editing and maintaining of your files more complicated. This is why Soluling supports an additional localization method where you can hardcode all strings into your markup and script files. Soluling reads the original files made by you and creates a localized set of files for each language. Localized files have exactly the same structure as your original files. Only strings, images, and other localizable items have been translated to the target language. You have to just maintain the original files, and whenever you deploy, Soluling will automatically create the localized files.

Using localized markup and resource files

This is the combination of the above two methods. You hard code all text in the markup (e.g., HTML templates), but you don't hard code strings into script files.

Comparing these methods

It is totally up to you what method you use. Soluling supports them all. If you want the same URL to serve all your languages, then you have to use resource files or a combination of localized markup and resource files. If you can have a different URL for each language (e.g.,,, then you can use the localized files method. Using resource files is much more popular than using localized files. The most obvious reason for this is that if you use localized files, you need a localization tool that can safely localize all files, including markups, server-side code, and client-side code. There have been very few such tools. Fortunately, Soluling can safely localize web application files.

Method Pros Cons
Using resource files
  • Commonly used method
  • Same URL serves all languages
  • You have to remove all strings from markup and script files and replace them with resource string identifiers or calls to a resource function or at least mark the strings you want to localize
  • Localization of other data types but strings items (e.g images) is difficult
  • Your markup and script gets harder to read and maintain.
Localized files
  • You can hard code script strings into all markup and script files
  • You can easily translate image, audio and video data
  • Faster on run time
  • Each language need to have different URL
Using localized markup and resource files
  • You can hard code script strings into all markup and script files that are emabbbed into markup
  • Same URL serves all languages
  • Few platforms support this

Supported technologies

Soluling supports the most popular web technologies. Supported technologies are:

Technology Description Supports resources Supports localized files Supports localized markup
Angular Angular resource files (.xlf, .xmb) yes - -
ASP.NET Core Web applications, services and APIs written in ASP.NET Core using Razor Pages, MVC or Web API (.resx, .aspx, .cshtml, .vbhtml, .csproj and .vbproj) yes yes yes (MVC)
ASP.NET Framework Web applications, services and APIs written in ASP.NET using Web Forms, Web Pages, MVC or Web API (.resx, .aspx, .cshtml, .vbhtml, .csproj and .vbproj) yes web site projects yes
Blazor Blazor applications (.csproj) yes - -
Django Django resource files (.po) yes yes yes
HTML HTML files (.htm, .html) including HTML 5 - yes -
Java EE Java EE files (.jsp, .gsp, .properties) yes yes -
JavaScript and TypeScript JavaScript and TypeScript files (.js, .ts) yes yes -
Magento Magento translation files (.csv) yes - -
PHP PHP files (.php, .po) yes yes -
Python gettext/po files (.po and .pot) yes yes -
React React resource files (.json) yes - -
Ruby on Rails Rails files (.yml, .yaml, .erb) yes yes yes
Vue Vue resource file (.json) yes - -

If you use some other web technology, most likely, you can still use Soluling. It is likely that Soluling supports the resource file format of the technology. If you want to use localized files or localized markup method, then add all markup files and code/script files into a Soluling project as separate sources.

Our complete web application sample, Sports, shows how to localize a web client, a server database, and how to implement a locale-aware REST API.

Items that needs to be localized in a web application

Web application can have localizable data in several files and formats. You need to localize strings in markup elements, strings in scripts and strings in databases. The following table contains a list of different item types you might need to localize. The text that need to be localized is marked in red typeface.

Items to translate Sample
Strings in resources Each platfrom has it default strings resource format:
Platform Resource format
Angular .xlf and .xmb
ASP.NET .resx
Blazor .resx
Django .po
PHP .po
Java .properties
React .json
Ruby on Rails .yaml
Vue .json
Strings element in markup
<p>This is a sample.</p>
Images element in markup
<img src="Files.png" />
Server side scripts in markup
<?php echo "This is a sample"; ?> 
Client side scripts in markup
function process()
  document.getElementById("hoursLabel").innerHTML = "This is a sample";
Strings in script file
protected void calculateButton_Click(object sender, EventArgs e)
  if ((Distance <= 0) || (Speed <= 0))
    resultLabel.Text = "You must enter a valid distance and a speed!";
    double time = Distance / Speed;
    uint hours = (uint)time;
    uint minutes = (uint)Math.Round(60 * (time - hours));
    resultLabel.Text = "Driving time is";
    hoursLabel.Text = String.Format("{0} hours", hours);
    minutesLabel.Text = String.Format("{0} minutes", minutes);
Text in database
[Id][Name ][FieldPlayers][Goalie][Origin ][Description]
0   Soccer  10            1       England  Soccer is a sport played between two teams of eleven players with a spherical ball
Text in XML data file
<?xml version="1.0" encoding="utf-8"?>
  <sport id="soccer" name="Soccer" fieldplayers="10" goalie="1" origin="England">
    <description>Soccer is a sport played between two teams of eleven players with a spherical ball.</description>
Text in JSON data file
    "id": "soccer",
    "name": "Soccer",
    "fieldplayers": 10,
    "goalie": true,
    "origin": "England",
    "description": "Soccer is a sport played between two teams of eleven players with a spherical ball."

Using resources to localize web pages and applications

This is the most common way to localize web applications. The main idea is that you identify all those strings that need to be translated, and you replace the hardcoded strings with resource strings. This is typically done by using a platform-specific resource file format and by calling a get resource function of the platform. The function returns the right string matching the language that is currently selected.

HTML elements

A typical markup file contains strings in three element types: HTML elements, server-side scripts, and client-side scripts. Most often, a string is a part of the HTML element. For example, the following line shows a paragraph.

<p>Hello World</p>

The above string is hardcoded, and if you run the markup file, it always renders the above string. To use a resource element, add Hello World into a resource and replace the hardcoded strings with a script that gets the resource item.

<p><?=GetResource("Hello World")?></p>

Even above script looks like PHP it is not real PHP but it shows a generic pattern. In PHP you would use

<p><?=gettext("Hello World")?></p>

In ASP.NET you would use


In Blazor you would use


In JSP you would use


Even the get-resource function is different (gettext, GetLocalResourceObject, or GetString), and the markup syntax also differs (<%...%> or <?....?>) the method is very similar in all three platforms.

Angular uses a different method where you just tag the elements you want to localize with the i18n attribute.

<p i18n>Hello World</p>

Angular's approach has two huge advantages: First the impact to the template is minimal compared to the above methods. Second you don't have to manually create or mainting the resource file but Angular's i18n-extract tool will do that for you.

Using proprietary string storages

Some applications do not use resource files to store localized strings but use a home-brewed method that uses either databases, text files, or XML files to store translations. If you use such a method, you can easily use Soluling to localize your strings.

Using localized files to localize web pages and applications