Localization checklist. Application localization Localization of desktop, browser and mobile games

We translate into foreign languages computer programs, games and online applications.

In addition to string interface resources, we will translate the help system, marketing texts, and the website. If necessary, we will qualitatively re-voice or re-shoot the video clip, re-draw the graphics, re-write the texts in the desired language.

All translations are performed by professional native translators. We translate into 68 languages, as well as other language pairs.

Localization of desktop, browser and mobile games

We work with publishers and developers of mobile and game projects, helping to make available applications for iOS, Android, HTML5 in more than 60 languages. In addition to translating the string resources of the applications themselves, we also write and translate descriptions for App Store and Google Play.

Linguistic testing

After the localized version of the application is built, it is necessary that the translator-localizer tests it on the national version of the OS. During such linguistic testing, the localizer will take screenshots of problem areas (not translated, too long lines, wrong encoding or text direction, wrong context) and, together with the developer, will make the necessary changes to the resource files.

If you translated the application yourself or by a third party contractor, you can order linguistic localization testing from us.

Cost calculation

The cost of localization and translation is calculated based on the volume of the text (number of characters with spaces). Check out the translation rates. The calculation does not take into account tags, keys, markup.

The localization process often means more than just setting your app's language for different regions. This also includes the correct time, date, and display format for different regions. If you expect your application to have a chance to go to a wide international audience, you immediately need to think about competent localization of the application, so that later you don’t delve into the code of the entire program and spend a lot of time setting it up for different regions of the planet.

FROM using android The SDK, the language of the localized string resources used, and the time and date format/values will automatically adjust to the region and language environment in which the device is operating. The language is defined by ISO 639-1, the country by ISO 3166-1. That is, we can safely say that Android is compatible with most countries of the world (well, maybe some African tribes do not count :)) and languages.

Language localization

It is worth noting that the only language that will be 100% represented in any Android device is American English, denoted by the code en_US. To produce language localization of your application, you need to its folder res/ invest additional resources that you see fit to add.

To add alternative languages to your application, you need to create folders in the res/ root folder, giving them names like: res/values-<языковой код> or res/values-<языковой код>-r<код страны> . It is worth noting that if you have defined language settings for a certain region, then they, when used in applications in this region, will be priority, that is, they will be more "important" for the application by default and will be applied first. Above their priority can only be the so-called mobile country code MCC. Mobile country code (determined using the mobile network MNC code from SIM cards) defines the preferred resources for a given country.

So, let's learn how to create language localization. Create a new application, or open an existing application that is not too complex. We set the task of localizing our application for Russian-speaking regions and English-speaking ones. For settings Russian language we just use the existing folder res/values/strings.xml and create the string resources we need so much. For English the same language, create a subfolder /values-en in folder res/ resources, and create next file with ads: res/values-en/strings.xml. In this file we created, we will add the English string resources. How the code should look like:

For a file with Russian language resources res/values/strings.xml:

< resources> < string name= "app_name" >My application< / string> < string name= "hello_world" >Hello World!< / string> < string name= "action_settings" >Settings< / string> < string name= "word" >Word< / string> < / resources>

For English localization fileres/values-en/strings.xmlresources will be as follows:

< resources> < string name= "app_name" >My Application < string name= "hello_world" >hello world!< / string> < string name= "action_settings" >Settings < string name= "word" >Word < / resources>

Everything is ready, now when launched in an English-speaking country, the program will automatically use resources from the folder res/values-en/strings.xml and display English text.

It is worth noting that in order for this language localization mechanism to work correctly in your applications, you need for program elements that use text, for example, when setting up android:text="" for objects , to assign text to them, not just by writing a word, like android:text="Hello world!", but with a link to the created corresponding string resource: android:text="@string/hello_world".

If you want to localize strings in the program code itself, if this has not been done in the file layout.xml or other similar interface markup files, then to localize such strings, you need to call the object in the code android.content.res.Resources, which contains all the resources in the application package, and access the required resource from here using the method get.String. Here's how to localize our "Hellow world!" in this manner:

// Connect the required resource: android.content.res . resources res = context. getResources(); String helloWorld = res. getString(R . string. hello_world); // Bind the localized string to the element TextView helloTextView; helloTextView = (TextView )findViewById(R . id. hello_world_textview); helloTextView. setText(helloWorld);

There is another way to localize your application's string resources. It is quite simple, the simplest of all, as discussed here and will be discussed here, but it works just the same. So when you are working on your application in markup files like activity_main.xml, you can right here, without editing resource files, configure language localization. It doesn't matter what mode you are in, Text or Design, we find the following button on the panel:

Click it, select the first item - Add translation, and a window appears in front of us, where it is proposed to select the language you need for localization. We find the desired language from the list, click on it and see a new window:

As you can see, there are 3 columns in the table that appears: key, Defwalt, Russian (ru) (because I chose Russian for localization). The first one displays the string resources we have in the file res/values/strings.xml, in the second - their value in the same file res/values/strings.xml, and the 3rd window will allow us to enter the translation of all existing string resources here. Enter the desired translation, click OK. We see that the file has opened en\string.xml, which means that the program itself created the necessary folder for Russian-language localization. All is ready!

Time and date localization

In many applications there is a need to work with the value of the current time and date. Imagine the disappointment of your users, who were initially so happy with the presence of language localization that they were already ready to buy the full version of the program, and here you are - your program congratulates a resident of Kamchatka on the New Year half a day later than necessary. That's it, goodbye user! Therefore, the localization of time and date, as you can see, is also an important matter, and the Android SDK has tools for setting the date and time to match the location of the device.

Date localization

Date localization setting can be done using the class DateFormat in namespace android.text.format. The following code snippet shows how to get a string with a date value formatted for the locale of the device:

// Get the current time and date: Date currentDate = Calendar . getInstance(). getTime(); // Get the standard date format for the current device localization: java.text . DateFormat dateFormat; dateFormat = android.text.format . DateFormat. getDateFormat(this); // Format the current date according to the location of the device: String formattedCurrentDate = dateFormat. format(currentDate);

If the current location of the device is, for example, the United States, then the local date format will be shown as 11/29/2014 . class DateFormat other date formats can be configured. If instead of command getDateFormat perform, for example, getLongDateFormat, then we get the date in this form: Monday, December 29, 2014.

Time localization

Since time is represented in Android SDK as Date objects, it is also configured by the class DateFormat in namespace android.text.format. Here everything is done in approximately the same way as with setting the date, using the same method. Let's look at the code:

// Set current time and date java.util . Date currentDate = Calendar . getInstance(). getTime(); // Set up the correct time display for the current device localization java.text . DateFormat timeFormat; timeFormat = android.text.format . DateFormat. getTimeFormat(this); // Set the time format according to the localization of the device String formattedTime = timeFormat. format(currentDate);

Application localization

Build resources also come in handy when you want to localize a window. By using resources, you allow controls to change according to the current culture settings in Windows, which is especially useful for controls such as text labels and images that often need to be translated into different languages.

On some platforms, localization is accomplished by providing multiple copies of user interface elements such as string tables and images. In WPF, localization is not as granular. Here, the unit of localization is the XAML file (formally, it is a compiled BAML-pecypc that is embedded in the application). If you want to support three different languages, you will need to include three BAML-pecypca. WPF will choose the appropriate one based on the current culture settings on the machine where the application is running. (More precisely - WPF will use the value of the property to make a decision CurrentUICulture on the thread serving the user interface.)

Of course, such a process would not make much sense if it were necessary to create (and deploy) a universal assembly with all localized resources. This would be no better than creating separate versions of the application for each language, since the application would have to be completely rebuilt every time it needed to add support for a new culture (or needed to customize the text in one of the existing resources). Luckily, .NET solves this problem with satellite assemblies, which work with the application but are stored in separate subfolders.

When you create a localized WPF application, each localized BAML pecypc is placed in a separate subassembly. In order for an application to use this assembly, it is placed in a subfolder under the main application folder, like the fr-FR subfolder for French. The application can then communicate with this subassembly automatically by using probing technologies , which is part of the .NET Framework since version 1.0.

The biggest challenge in localizing an application is the workflow—in other words, how to extract the XAML files from the project, make them localized, compile them into subassemblies, and then bring them back into the application. This is the most confusing part of the "history" of localization in WPF, since no tools (including Visual Studio) that support localization at design time exist yet. Most likely, such facilities will appear in the future, but for now, WPF still allows you to do everything that is necessary to localize an application, just with a little more effort.

Creating localizable user interfaces

Before you start translating anything, you first need to understand how the application will react to content changes. For example, if you double the length of all text in user interface how will the overall layout of the window change? If a truly flexible layout has been developed, no problems should arise. The interface must be able to adapt to dynamic content. Below are some recommended practices to ensure you are on the right track.

Don't use hardcoded width or height values (or at least don't use them with elements that contain non-scrollable text content).

Set for property Window.SizeToContent a Width, Height, or WidthAndHeight value so that the window size can grow as needed. (Again, this is not always necessary; it depends on the window structure, but in some cases it is very useful.)

Use the ScrollViewer element to view large text.

If you want to localize an application into a language that has a significantly different character set, you will need to use a different font. You can do this by localizing the FontFamily property in the user interface, or by using a complex font like Global User Interface, Global Sans Serif, or Global Serif, all of which support all languages.

You may also want to consider how the layout will work with a right-to-left layout (instead of the standard English left-to-right layout). For example, Arabic and Hebrew use a right-to-left layout. You can control this behavior by setting the FlowDirection property on each page or window in your application. For more information about right-to-left layouts, see the Visual Studio help, under Bidirectional Features.

Localization is a complex topic. WPF offers a workable but not yet mature solution. Once you're familiar with the basics, it's worth taking a look at the Microsoft document on WPF localization, which is available at http://wpflocalization.codeplex.com along with sample code. It can be expected that in the future localization support will be improved in design tools such as Visual Studio and Expression Blend.

Preparing the application for localization

The next step is to enable localization support for the project. This requires only one change to be made, and that is to add it to the project's .csproj file somewhere in the first section Next item:

en-US

This will tell the compiler that the default language (culture) for the application should be English (United States) (obviously, you can choose another language if necessary). After making this adjustment, the layout process will change. The next time the application is compiled, a subfolder named en-US will be created. Inside this folder will be a sub assembly with the same name as the application and the extension .resources.dll (for example, LocalizableApplication.resources.dll).

This assembly will contain all the compiled BAML resources for the application that were previously stored in the main application assembly.

Formally, the application is localized not for any specific language, but for a culture that takes into account regional differences. Cultures are identified by two hyphen-separated identifiers. The first specifies the language and the second specifies the country. Therefore, fr-CA means French as spoken in Canada and fr-FR as French as spoken in France. Full list culture names and their identifiers can be found in the Visual Studio help, in the section on the class System.Globalization.CultureInfo.

This implies detailed localization, which can be excessive. Luckily, WPF allows you to localize your application on a language-only basis. For example, if you want to define settings so that they apply to any French-speaking region, you can specify only the identifier fr for a culture. This approach will work unless a more specific culture is available that exactly matches the current computer.

Now, when you run this application, the CLR will automatically look for subordinate assemblies in the appropriate directory based on regional settings computer and download the appropriate localized resource. For example, when running an application on a machine with an fr-FR culture, the CLR will look for the fr-FR subfolder and use the subordinate assemblies it finds there. This means that in order to add support for additional cultures to a localized application, you simply need to add the appropriate additional subfolders and subassemblies, without worrying about the application's original executable.

When the common language runtime starts to probe folders for the presence of a sub assembly, it follows a few simple rules of precedence:

It first checks the most specific directory available. This means that the CLR is looking for a sub-assembly destined for the current language and region (like fr-FR).

If the CLR cannot find such a directory, it will look for a sub-assembly destined for the current language (such as fr).

If it cannot find such a directory, then an IOException is thrown.

This post is an attempt to systematize all available on this moment I have information regarding the localization of applications.

While we are writing programs “for ourselves”, then we somehow don’t think about localization, internationalization, and other troubles. What for? It is unlikely that anyone in their right mind would come up with the thought “Shouldn’t I translate my utility into Hebrew, so that I can work with such a program later?” It is a completely different matter when the program “grows out of short pants” and there is a demand for it in other countries. Then, if the demand is large enough, you can (and should) take on localization - find a suitable tool, hire translators (or translate yourself) and work, work, work. A solution like “Make an INI file” may well be suitable for small programs, but not for serious projects with a developed interface, large quantity forms, resources, etc. - in this case, it is worth finding a suitable ready-made solution. Actually, the main goals of finding a solution for localization that were set for me are to find a solution that will allow:

carry out localization by non-programmers
work with your own translation dictionaries
XE2 support

and, as usual, the solution should be easy to use, cheap, if possible, easy to learn, etc. etc. And since I still decided to go through all the possible options in my search (or rather, the maximum possible number of options), I decided to systematize all the material found and arrange it in this very post. Here you can learn about the existing components of Delphi and about libraries and programs - in general, about everything your heart desires. In general, if you also set out to find in the whole set of proposals for localization the one that will appeal to you, then read on :)

TSILang components suite

Developer: SiComponents
Official site:
Price from $259 to $399. $259 package does not include source code (only DCU and OBJ)
available .
Last release date: 05 May 2012
Delphi XE2 support: available

TsiLang® Components Suite allows you to add support for unlimited languages, and also, create fully localized versions of products based on the base version of the project. All the necessary elements of the user interface are automatically found and added to the list for translation, convenient ways to save and manage translations are provided, and of course, the interface language is switched "on the fly" both while the application is running and in designer mode, which allows you to test the interface even without compiling and running the application.

My test.

For testing, I downloaded and installed latest version components (6.5.4.7) and created a simple application on which I placed Button, Label, OpenDialog, added resource strings and constants. Specially for the OnClick of the button, such a “crooked” handler was created:

procedure TForm19. Button1Click (Sender: TObject ) ; begin ShowMessage("Hello world!" ) ; end ;

Localization with TsiLang is carried out as follows:

1. Run TsiLang expert from the Delphi menu: Tools ->TsiExpert

All forms of the project are displayed here, as well as the components located on these forms. Now choose from the menu File->Languages and edit the list of languages for our application. By default, all languages have names like Language1, Language2 etc. I renamed them like this:

After the “Ok” button was pressed, the TsiLang component appeared on the main (and only) form of the application:

Now we find the “Save Project” button in the Expert Advisor and save our project. TsiLang uses two types of project files:

*.sib - binary file with translations. Developers recommend using this type of file, because. loading of such files is much faster than when using the second type of files
*.sil - text files. The advantage of this file type is that we can transfer this file with the utility “ SIL Editor” to another person for transfer.

I saved my project to a file test.sil.

Now, being in the expert, double-click on the name of the form in the list - the translation editor window will open:

In the left part of the window (in the tree) of the editor there are groups of translatable properties of components and strings and, accordingly, on the right - a table for translation. TsiLang can localize not only properties of type components Caption, Hint, Text etc., but also strings from dialogs, for example, the figure below shows all strings for translation from various dialogs that can be used in the application:

We begin to translate all the lines from Russian into English. When translating each line, the editor in a separate window shows us the length of the original line (in pixels) and the length of the translated line:

In principle, the purpose of this information window is clear - you can control situations when the translated text will not fit into the boundaries of the component. Although, as for me, it would be convenient to add the width of the component itself to this window - so that there would be something to compare the widths of the lines with.

After all the lines are translated, we save our project again. Now sil file should contain text like this:

character sequence #$ is a delimiter that we ourselves can determine when saving the file. In the process of translating strings in the editor, you can see that TsiLang in no way took into account that the pas-file of the form contains both the resourcestring and const sections and even the text string in the OnClick handler. To add these strings to the translation, select the TsiLang expert from the menu:

File -> Source -> With Form - to select lines from the implementation section of the module,
File -> Source -> With Form- to select all string constants and resource strings

As a result, a window with search results will open in which you can add a line to the exclusion list or replace it with a call to the TsiLang function:

Click the “Modify Source” button in this window and get the following message:

We open the pas file and see the following strange picture:

It seemed strange to me that TsiLang perfectly defines string constants in the pas-file and even changes the source itself, but for some reason it is “lazy” to define var itself - well, they would make an additional option in the settings of the translation project like “Define VAR for constants with strings ” and “Change compiler settings”. But that's okay - there is a window with a message and that's bread. Here, what I really don’t understand is where did TsiLang find incomprehensible hieroglyphs in my project? I thought that this might be due to the fact that the pas file is saved in ANSI, but no - I changed it to UTF8, but the problem with hieroglyphs remained ... In general, this is strange.

After the strings have been placed in the translation, you can open the translation editor again and translate the group Strings(fortunately, the lines get into the editor without distortion):

After all the strings have been translated and the sil file has been saved, you can switch languages in your program. In TsiLang, each language has its own integer identifier. For example, in my case the ids were like this:

Russian = 1
English = 2

Now, in order for the interface of my program to switch to English language just paste the following code somewhere:

siLang_Form19. ActiveLanguage := 2

This will cause TsiLang to load strings in the required language from the sil file.
As for working with the translation dictionary, it can transfer to the dictionary (previously created) only already translated strings. To do this, you can use the same translation editor - click the “Add All” button in the editor, which is designed to transfer all translations to the dictionary and get the following window for selecting the necessary transfer options:

select the dictionary file here, click “Ok” and get all the translated strings into your dictionary, which, by the way, looks like this:

Subsequently, this dictionary can be used for automatic transfers lines in their programs. Well, as I said above, for working with SIL files there is a separate utility called SIL Editor, which is designed for translators. For the purity of the experiment, I copied the folder with SIL Editor to a flash drive and launched the program from the “Windows XP Mode” virtual machine:

SIL Editor allows you to translate from dictionaries and manually, as well as, if necessary, add new languages to the translation.

Other features of TsiLang:

Import of dictionaries from doc-, html-, xls-, csv-, po-files
Importing resource strings from executable files
Presence of own components - dialogs for opening files, labels, lists, etc.
Maintaining translation statistics

The review turned out to be quite large, but the tool is worth it. Let's summarize a little:

Advantages:

Just connects to the project - throw the component on the form, call 1 method and the interface is translated
Convenient translation editor - all lines are laid out, what is called "on the shelves", you can quickly navigate the tree in search of the necessary lines for translation
Supports both binary and text files with translations. We created a sil file, gave it to the translator, then resaved it to sib and everything is ready - and the program will work faster and no one else will get into the translation.
Availability of tools for translators (SIL Editor, dictionaries)

Flaws:

“Corrupts” Russian strings in the pas file. Let them be in comments, but, nevertheless, a fact on the face.
In the process of work, incomprehensible errors were found when working with dictionaries. For example, when transferring translated strings to a dictionary, an out-of-range error occurred every other time.
Minor problems with windows. They, of course, do not interfere with life, but nevertheless, it’s not good when you call up a dictionary, and it is minimized in the control panel for some kind of goblin.

In principle, the above shortcomings (with the exception of the second) are not so critical.

DKLang Localization Package

Developer: DCSoftware
Official site: www.dk-soft.org
Price: is free
Last release date: 25.12.2008
Delphi XE2 support: No

I can’t say anything about this localization solution except that it just exists, because. did not even begin to download the archive, despite the fact that the components are free.

First, the date of the last release is alarming - 2008- not the fact that the components will work in XE2 without problems.

Secondly, the package requires additional installation of components TNT Unicode Controls 2.3.0, which in 2012 are already superfluous - Unicode is already supported.

Therefore, if you have something to say about this decision - good or bad - write in the comments, and I will add feedback to the review.

UPDATE: about DKLang Localization Package. Briefly and clearly.

UPDATE 2: DKLang in XE2

EMS Advanced Localizer

Developer: EMS
Official site: www.sqlmanager.net
Price: RUB 2,900.00
Availability of trial version: available
Last release date: January 13, 2012
Delphi XE2 support: available

What developers say about their product:

Advanced Localizer™ is an indispensable component package for Borland® Delphi® that allows you to add language support to your Delphi® applications. Extensive package options Advanced Localizer allow you to quickly and easily localize the properties of the components of each form, create language files with the current values of the properties of the components, manage localization files, and assign components and their properties to be localized. Language of applications using Advanced Localizer, can be switched to another directly during operation without subsequent restart of the application. Advanced Localizer also provides the ability to write descendant applications that use user-specified language files.

Since we don’t have “indispensable” ones, I conducted my small test of these components all on the same small application in 1 form.
My test
Downloaded and installed the component package in Delphi XE2, opened the project. In the Delphi component palette appeared new tab- EMS Advanced Localizer. From this tab, we drop components on the form:

TQLanguageSource
TQFormLocalizer

At TQFormLocalizer in the Source property we specify TQLanguageSource and let's get to work.

First of all, we create files for localized strings - we make two empty files with *.lng extensions (the default extension for EMS Localizer) and call them simply - rus and eng.

You don't have to create these files - they will be created automatically during translation

Now double-click on the TQLanguageSource component to call the language file manager:

We press the only active button and add files:

Now, according to the idea of the developers, a new entry should appear in the manager's list ... but it is not. Here are the values contained in the Languages property of the component:

However, the list of the visual editor is pristine. Well, God bless him with a list - we are trying to translate our application. Double click on the second component (TQFormLocalizer) to call the translation editor:

In the editor, in addition to translating strings, we can also add a new language file, edit an existing language, or select a default language. As you can see in the figure, only the lines contained in the properties of the components get into the editor, and the resource lines and constants remain unnoticed, which can be written down as the disadvantages of these components.

After translating all the strings, you can add an option to the program to switch the interface language. This is done in much the same way as in TsiLang - by indicating the index of the active language:

QLanguageSource1. ActiveLanguage := 1 ;

In this case, if the default language is used (marked as “Original”), then its index is equal to -1, and for the rest it starts from zero and increases in order in the Languages list.

Other features of EMS Advanced Localizer:

Summarize.

Advantages:

The components are easy to use - it took about 5 minutes to figure out what and how it works.
Fairly cheap
It is possible to store translations in the database

Flaws:

No support for dictionaries and, accordingly, auto-translations
Problems in a simple language manager
Translation of constants and resource strings is not supported
No tools for third party translators

In general, my opinion about EMS Advanced Localizer- quite convenient components for working with small projects, but for more or less large projects where support for many languages is required, the work of several people on translation, etc. this set of components, unfortunately, is rather weak.

Korzh Localizer

Developer: KORZH developers tools
Official site: devtools.korzh.com
Price from 149.0 EUR to 649.0 EUR
Availability of trial version: available
Last release date: July 23, 2012
Delphi XE2 support: available .

What developers say about their product:

One EXE file can support multiple languages. Additional languages can be added without recompilation. No need to create many exe files
String data can be stored both in standard resource DLLs and in special language files
During localization, the program code either changes very little (literally a couple of lines), or does not change at all. Localizer does not change the application project, because no additional components are used
A localized project can be run for compilation without Localizer installed
Localizer translates both resources from the VCL and any other resources
Supports storage of translations in the standard Translation Repository and them reuse in future
Supports all third party components and packages (e.g. DevExpress, TurboPower, ElPack, RX, etc.)
The translation process can be carried out using the built-in utility Language manager, freely available for download by translators
Easy migration from Borland ITE (Integrated Translation Environment)

My test

I downloaded a trial, which differs from full version is that the Localizer only translates the first 30 lines from each form/file. Installed After that, a new item appeared in the main menu of Delphi XE2:

I chose “Start project localization” in the menu, as a result, I was asked to choose the main language for the project and specify the folder for storing the language file:

After clicking “Localize mu project!” recompilation of the project was launched, and in the dpr-file of the project were added required modules and calling Korzh Localizer methods:

uses (....) , LocOnFly, (Form18) ; ($R Project16.KLR) ($R *.res) begin LocalizerOnFly. InitReg ; (...) end .

Also, immediately after information message stating that my project is localized started Language Manager:

In the dialog for choosing a new language for localization, there is a wonderful option - “Try to automatically translate via Google”. However, this option does not currently work:

This is not due to the fact that the developers did something wrong there. The reason lies in the fact that Google has transferred the Translate API to commercial rails and, if I'm not mistaken, made access only via OAuth 2.0. So, apparently in the next editions of Korzh Localizer this option will disappear or will be used for more accessible APIs, for example, for the Bing Translator API.

After adding a language for localization, a table appears in the Language Managere for translating the strings found in the project. In addition to what is directly in the project, Korzh Localizer also allows you to localize strings contained in other Delphi modules:

After the translation, Localizer can show you statistics - how many lines are translated, the percentage of translation, etc., however, even here an error was found when switching to the “External Items” tab:

The assistant (let's call it that) offers to select modules for scanning for strings, and also offers two options for storing strings - in a resource file or in a pas file:

I left all settings as default. There were three lines in the module - one in the resourcestring section, the second in const and the third in the button's OnClick handler. As a result, Korzh Localizer determined the following:

After clicking “Next”, the IDE gave a message:

After pressing “Yes”, a new module was added to uses, containing the resourcestring section in which there was one found string. The button's OnClick handler has also changed and looks like this:

procedure TForm19. Button1Click (Sender: TObject ) ; begin ShowMessage(SIgeaaoIeg) ; end ;

The line did not appear in the Language Manager - it may be assumed that such lines will be translated without a manager, or maybe they are somehow cunningly added to the manager - I did not understand this in detail. I just need to check how the localization is going. In order for the project to “speak” in another language, it is enough to select the required language in the main menu:

After that, the IDE again reported that the file had been changed and asked to reload it. Rebooted, built the project and got the application in English:

Other features of Korzh Localizer:

Creation/import/export of repositories. Import and export is carried out in XML or TMX formats.
Supports multiple languages for localization - a separate file is created for each language
Able to work with EXE and DLL files.

Advantages:

Does not require the presence of any components on the form - everything that is needed Korzh Localizer he connects to dpr .
There is a tool for translators
It is possible to create / import / export repositories

Flaws:

While working with the tools, I found various kinds of flaws such as errors (see screenshots above), flaws in the interface, the presence of non-working options (while Google closed access to the API a long time ago, and the release of the localizer was relatively recent). All this creates a feeling of some kind of abandonment of the project.
Resource strings do not get into the Language Manager or somehow so cunningly that you can’t immediately figure out where to click or what to add where.

In general, I would leave Korzh Localizer as a fallback in case nothing better is found . In addition to the disadvantages described above , about one of the reasons for this conclusion was the time it took to get used to working with the tool - of all the tools discussed above, Korzh Localizer took the most time.

GNU gettext for Delphi and C++ Builder toolkit

Developer: dxgettext.po.dk
Official site: dxgettext.po.dk
Price: is free
Last release date: unknown
Delphi XE2 support: No

Despite the fact that there is no support for Delphi XE2, I still decided to download and try this library. Unfortunately, after connecting dxgettext.pas to the project, errors began to appear - somewhere instead of ansiString they specified string, used methods marked as depricated, used incorrect method parameters (maybe such code was compiled in Delphi 2009, but not in XE2). In general, a lot of things got out ... It's a pity. In Lazarus I have used this library a couple of times and I must say I liked it. Of course, for existing projects, it will be quite problematic to implement DXGetText into work, but for new ones it is quite a tolerable and convenient library. There are several utilities for translators, translation memories, etc. In general, if you decide to start a project on Delphi versions before 2009 and you need a library for localization and internationalization of the project - try DXGetText.

i18n package

Developer: Kambiz R. Khojasteh
Official website: www.delphiarea.com
Price: is free
Last release date: August 19, 2012
Delphi XE2 support: No (according to the information on the official site)

i18n Package v1.10 for Delph i is a whole library of components designed for localization and internationalization of projects. Despite the fact that Delphi XE2 is not officially supported, this library was installed in Delphi XE2 without any problems, so I decided to test it a bit.

The package includes over 30 different components that support localization, but, as you understand, I'm interested in another point - can this library be used to localize an existing project with a bunch of forms, dialogs, resource lines, etc.

So, the localization work using the i18n Package is as follows:

Throw the TLocalizer component on the main form
On all other forms (including the main one) we throw a component for translation - TTranslator
To localize dialogs, it is also necessary to place the TMessageBox component on the main form and specify the necessary titles, icons, etc. in it.

Now we need to create a file with newlines. To do this, double-click on the TTranslator component - an editor will open in which you need to select the properties and strings that we will translate:

If you need to internationalize the project, do not touch anything in the “Property Value” field, because adding new languages and translating strings is carried out in a separate utility

After the necessary elements are selected, go to the Export tab, specify the language in which our lines are written (i.e. Russian) and export the lines to the * .i18n file:

The file has been created - you can start translating. The Bin folder of the library contains a special utility called i18n Editor, which is intended for translations.

The program is quite easy to use and I think you will get used to it very quickly. I will only say that i18n Editor is able to “learn” - for this, the program needs to specify the folder in which the ready-made *.i18n files are located and the program will automatically scan them and extract new phrases from them.

After all the necessary strings have been translated, we return to Delphi and specify our file with localizations in the URI property of the TLocalizer component. Now we add the TCultureBox component to the form and specify Localiwer1 in its Localizaer property (if the component has not been renamed).

Now you can run the program and make sure that the translation of the interface is successful:

Advantages:

For its price - $0.0 is quite high quality (works fine in Delphi XE2)

Flaws:

The parser does not detect resourcestring and string constants, and the detected and translated strings from the program code are still not localized.
For each form/module, you need to use your own TTranslator, which is not very convenient. It would be more logical to make a small scanner of the entire project for the presence of lines, as is done, for example, in DXGetText

The general conclusion about the library can be made as follows - for the “price / quality” ratio, it is a wonderful library that allows you to make multilingual support in small projects with virtually no problems. The work of the library with strings not from the properties of the components spoils the impression a little, I think that if the project is alive (and judging by the release, the project is quite alive), then this annoying problem will be solved.

Kryvich's Delphi Localizer

Developer: Kryvich
Official site: sites.google.com/site/kryvich/localizer
Price: is free
Last release date: January 7, 2012
Delphi XE2 support: available

Another free library for localization and internationalization of Delphi applications. According to the authors of the project, with this library, the localization of our applications should go without any problems. Let's check if this is actually the case.

First of all, we need to change the project options. Let's go to the IDE: Project->Options->Linking and install Map File = detailed

Now we build the project and get three files - *.exe, *.drc and *.map. Now we launch the kdlscan.exe console utility, which is located in the library folder. The utility is launched with the parameter:

kdlscan

where is the name of our exe file.

The scanner goes through the project and pulls out resource strings and strings from component properties and puts them into a file with *.lng extension. This file is a regular ini file, so feel free to open it with any editor and translate all the lines as we need.

After the translation, we save the resulting file, for example, with the name english.lng.

Now let's get to work on the project. To support localization, add the uFreeLocalizer.pas module to the uses of the main form, also throw the uStringUtils.pas module into the project folder and write in any convenient place in the program:

FreeLocalizer. AutoTranslate := True ; FreeLocalizer. LanguageDir := ExtractFilePath(Application.ExeName) ; FreeLocalizer. LanguageFile := "english.lng" ;

The first two lines can be written in the dpr file and the localizer module can be connected there. All. You can run the program and check the work.

Advantages:

Very easy to use library
compact

Flaws:

No dictionaries
Scanner does not detect hardcoded strings and constants

In general, the library is quite suitable for projects with a small number of strings for localization. Still, work through the ini-file will make itself felt with a large amount of data.

JVCL (JEDI Visual Component Library)

Developer: JEDI Project
Official site: jvcl.delphi-jedi.org
Price: is free
Last release date: April 11, 2011
Delphi XE2 support: available

Who doesn't know the JEDI project? This giant library is probably known to everyone who has worked at least a little in Delphi. This library contains the component TjvTranslator, which allows you to localize Delphi applications. Judging by the reviews on various forums and blogs, the component is quite convenient and popular, but I somehow did not smile at installing the entire JCL + JVCL set in order to look at the work of one wonderful component. Therefore, you will have to look for advantages and disadvantages on your own. And I'll move on to other components.

C&Pack Component Package (CnVCL)

Developer: C&Pack
Official website: www.cnpack.org
Price: is free
Last release date: November 5, 2011
Delphi XE2 support: available

Another quite popular developer, who gained well-deserved popularity with his product called cnWizards, provided us with a set of components for application localization. These components are included in a separate package - cnVCL and are distributed free of charge.

I’ll note right away that at the moment the latest version of the components available for download is marked as Alpha, so you can’t expect flawless work from this set of components. But, nevertheless, I will make a small overview of the localization components.

So, after installing the cnVCL package, several new tabs appear in the component palette at once:

on the cnMultiLang tab there are 4 components for localization. Three of them: TCnLangManager, TCnLangTranslator and TChHashLangFileStorage or TChIniLangFileStorage must be placed in the application.

I must say that the Alpha version makes itself felt. In order to quickly understand the operation of these components, I decided to run a small demo that comes with the components sources ... it, of course, opened in Delphi XE2, but something is somehow quite strange:

Well, yes, this, in principle, is tolerable - the source code, it seems, is not very “pokorezhin” and it was more or less possible to figure out what and how it works. The essence of the work is:

1. We drop the above three components on the application form (I chose TCnLangManager, TCnLangTranslator and TChIniLangFileStorage)

2. Now choose TChIniLangFileStorage and add to the collection Languages new languages. It should look something like this:

3. Do TCnLangManager in the LanguageStorage property we specify our component CnIniLangFileStorage1

4. Double click on TCnLangTranslator- the editor for translating strings will open:

5. Select the required language in the tree and click “Gen All” - a table with strings for translation should be assembled. For me it turned out like this:

6. We translate the necessary lines, delete unnecessary lines, save the resulting table to a file. As a result, we get an ini file that must be thrown next to the exe file of our project.

7. We write one line in any convenient place in the program:

CnLangManager1. CurrentLanguageIndex := 0 ;

As a result, this action will lead to the fact that the program will be “translated” into the language that has index 0 in LangugeStorage, i.e. in my case - in English. I won’t give a screenshot, I’ll just say that the component worked.

What can be said about the advantages and disadvantages of these components? I think that for now it is not worth drawing any conclusions - after all, the Alpha version and all kinds of bugs, strange behavior, etc. are inevitable here. etc. If work on components continues, then most likely we should have at our disposal simple and easy-to-use components for localization and internationalization of projects. In the meantime, it is very, very early to use these components in serious applications.

TLang for FireMonkey

Developer: Embarcadero
Official website: embarcadero.com
Price: included in Delphi price
Last release date: September 03, 2012
Delphi XE2 support: available

I will not talk about this component and working with it in detail, because. there is already an article in the blog about working with TLang in FireMonkey. The article is called "" - in it you will find the advantages and disadvantages of this component. In Delphi XE3, I did not check the operation of the component.

Multilizer

Developer: Finnish technology company
Official website: www2.multilizer.com
Price: 299 - 2900 EUR
Last release date: unknown
Delphi XE2 support: available

Despite the rather low price of the product, I still decided to see what this product is like. Multilizer is a specialized product that allows you to localize different types applications, files, dlls, etc. Also included in the package is a set of components for Delphi 5 - XE2. I did not install the components, but I decided to try the Multilizer application itself on my application.

It all starts with the fact that we create a new project for localization:

We choose the first option. The next step is choosing a parser:

At the third step, Multilizer asks us to specify a file for parsing (specified exe), performs parsing and displays the scan result:

The next step is to determine the native language of the application and add new languages for localization:

Multilizer also allows you to automatically determine the language, but for some reason it asks for a username and password for the Google account 0_O (though not the keys to the apartment where the money is). I did not check this function of the program.

After the project is created, the translation editor window opens, which looks like this:

Majority mobile applications somehow developed for use in more than one country or region. As a result, developers face the question of localizing string resources for different languages.

Fortunately, Android has a fairly efficient built-in mechanism for this task.

The description of the application localization process is given on the example of Android Studio 2.3

In order to enable regular funds localization of Android, you need to create the appropriate folder and file with resources.

To do this, right-click on the app folder in the project tree and select New - Android Resource File from the drop-down menu. In the window that opens, select the Locale item using the ">>" button or double-click the mouse.

This will open a list of available languages. When you select a language, the corresponding suffix will be automatically added to the name of the folder with resources in the "Directory name" field.

If you need to create a separate localization for a region, then after selecting the main language, you must specify the corresponding region.

In this case, an additional suffix will appear in the folder name, starting with the letter "r" (region).

The name of the localization file ("File name" field) must be specified manually. It is highly recommended to follow Android standards and name localization files strings. This will not cause a name conflict, since the newly created files will be in separate folders nested in the Values folder.

As for the strings.xml file, which is present in the Values folder initially. After adding localizations, string values from it will be used by default if there is no localization for the current language installed in the system.

The localization description itself is absolutely similar to the "normal" strings.xml. The only difference is that string resource values are specified in the respective language.

Below is a simple example.

Contents of strings.xml files used by default and for English American localization:

Multilanguage Application hello world!

< resources >

< string name = "app_name" >Multilanguage Application< / string >

< string name = "hello_world" >hello world!< / string >

< / resources >

Application screenshot:

The contents of the strings.xml file for Russian localization:

Multilingual application Hello world!

< resources >

It is important to note that the installation of the necessary localization in the application is completely automatic and does not require additional actions. From the developer's side, you only need to create the necessary files and fill them with the appropriate data.

The only disadvantages of the standard Android localization mechanism are the inability to set the application language independently of the system as a whole and the need to store resources in text files in XML format. But, in most cases, its capabilities are still enough to satisfy the needs of the development