Web files and applications Web pages and applications

Soluling localization tool and service can localize most web applications and pages. Compared to 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 server side (C#, Visual Basic, PHP, Ruby, Java) or scripts that are run on client side (JavaScript).

All these items might contain strings that need to be localized. If your application is properly internationalized you need in most cases only to localize the resource files and sometimes strings in the database. If you 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 this diversity impacts to the localization and because of it there are no single way to localize web applications. Web application can use resource files just like 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 hard code 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 uses .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 few problems. Most obvious is the fact that you can no longer hard code 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 additional localization method where you can hard code 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 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 that the same URL to serve all your languages then you have to use resource files or combinarion of localized markup and resource files. If you can have different URL's for each language (e.g. http://www.mysite.com/en, http://www.mysite.com/de, http://www.mysite.com/fr) then you can use the localized files method. Using resource file is much more popular than using localized files. 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 has 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 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
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)
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 -
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 .xmb and .xlf
ASP.NET .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
<script>
function process()
{
  document.getElementById("hoursLabel").innerHTML = "This is a sample";
}
</script>
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!";
  }
  else
  {
    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"?>
<sports>
  <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>
  </sport>
  ...
</sports>
Text in JSON data file
{
  "soccer":
  {
    "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 hard coded 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 as a part of HTML element. For example following line show a paragraph.

<p>Hello World</p>

Above string is hard coded and if you run the markup file it always renders the above string. To use resource the element add Hello World into a resource and replace the hard coded strings with a server side 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

<p><%=GetLocalResourceObject("Hello_World")%></p> 

In JSP you would use

<p><%=resourceBundle.GetString("Hello_World")%></p> 

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 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.

Script files

 

Images

 

Embedded scripts

 

Using proprietary string storages

Some applications do not use resource files to store localized strings but use home brewed method that use 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