1C:Professional training course. Lesson 5-2

Lesson 5-2

The Application Language

The application, we are developing in this course, speaks English. What if we’ve got a potential client, working in starships repair market, who is considering buying our application as soon as it speaks his native language - Klingon?

OK, let’s do it.

The first thing that comes to mind is replacing all text resources of the application with the Klingon analogs. This way we will get another version of the application - the Klingon one. Sounds reasonable so far. But what do we do when we want to develop a new version with additional functionality? We have two independent applications - English and Klingon. So we need to make all the changes twice, spend almost twice as much time and get at least twice as many errors because of all this mess.

So, the direct translation of the application from one language to another is a bad idea. The only thing that works in a long run is a multi-lingual application that contains string resources in all necessary languages within the same application.

This is how it works in 1C:Enterprise.

The first thing we need to do is add the Klingon language to the languages list in the Common section of the configuration.

After this, all strings and texts that can be visible to a user will have two representations - English and Klingon. So you will be able to add a Klingon synonym to every string resource. For example, here is how you add a Klingon name to the Customers catalog.

This is the Employee catalog properties before we add a new language to the application:

Note, that there are two look-alike fields: Name and Synonym. You are to use the Name when you address the catalog in source code (Catalogs.Employees…). The Platform will use the Synonym when the catalog-related command is shown in the interface. Needless to say that these two fields can have different values.

This is the same form after we add the second language to the application:

Note, that the Synonym field now has a zoom icon. Pressing it will open the separate form where you can define the synonyms in all application languages. In our case, this form has two synonyms but there can be any number of them when we add more languages to the application.

Basically, this is how we make the translation - we give a synonym in every language to all strings visible in the interface.

OK, how do we make the application showing the interface in the language the current user speaks? Easy. All we need to do is specify the language in the user information form (Administration \ Users).

So, every time this user runs the application the interface will be shown in Klingon.

To make the process clearer let’s see how to translate the interface of the entire starting page of our application.

Application messages

Application metadata is not the only place showing texts to users. Using the source code we can specify string literals (i.e. explicitly defined string constants) put them to various forms and show this forms to a user. Probably, the most common example is this:

	 MessageText = “Some message text”;

This piece of code will show a user a message box with the text we explicitly hardcoded in the application.

Let’s see how we can specify the synonyms in this case.

This is the resulting piece of source code we got.

//6. Prepare the error message and display it.
MessageText = 
		"en = 'There is not enough materials. See the list of deficits below:'; 
		|kl = 'pa'' ''oHbe'' yap Hap ''u''. Hutlh tInwI'' pagh tetlh vIlegh:'"
	) + MessageText;

Translating the entire application

To translate the entire application we need to add target language synonyms to:

  • All metadata objects including:

    • Objects’ and attributes’ names
    • Forms elements’ visual representation
  • All string literals that can be shown to a user

For a real-life system, this can be almost mission impossible. How not to miss a single attribute? How to find all string literals in the source code? Fortunately, the Platform has a simple and powerful tool that solves the problem.

After you select this menu item, the tool setup form will be opened.

Leave the first tab settings as they are, switch to the Modules tab and select “Search in NStr functions in modules” checkbox.

After you click “Find” the tool will gather all string resources from the entire application and output them as a table.

The first column shows the exact place where this string was taken from. Second and third columns are English and Klingon versions of the string. Some of the strings are already translated (we did it earlier) others need the translation to be done.

The great thing about this table is that you can put translations directly in this list, and they will go to the correspondent place in the application in real time.

As an example, I translated the Prices information register name in the table.

As soon as did that the translation automatically went to the information register.

As a matter of convenience you can export the table content to the spreadsheet (for example, Excel), make the translation there and then upload the texts to the table (“Fill texts…”).

The Platform Language and the Application Language

Take another look at the table on the top of the Lesson. There are two cells painted red. It means that you can translate the application interface to any language you want, but this is not the end of the story. A significant part of the interface is shown by the Platform and on the Platform’s current language. Therefore, if there is no target language in the list of languages supported by the Platform, you cannot provide users with a complete native-language solution.

Other speakers

There are some other speakers capable of showing texts to your application user. Two most important of them are Operating system and DBMS.

Here is a simple example of Windows dialog that will be opened from 1C:Enterprise application. Say, you want to store the pictures of your clients in the infobase. To implement this functionality you added an attribute Picture (type ValueStorage) to the Customers catalog, created an item form with “Select picture” button and then call the operating system file selection dialog with this code

	Notification = New NotifyDescription("FileSelected", ThisObject);

Then, this is what a user will see.

File selection dialog isn’t declared in the application or the Platform. This is the standard operating system (Windows 8.1 in this case) dialog called by the Platform. So, its content (including the language of all texts) is defined by the OS and there is nothing we can do about it on the 1C side.

Another example of the OS speaking with 1C user is OS error messages that can arise as a result of some user action. If you don’t handle the exception in the application code, the message will be intercepted by the Platform and shown to the user as a part of 1C error message.

The same is true for the DBMS. For example, if two 1C users are trying to write the same piece of data to MS SQL Server database, one of them can get this error message.

Part of this text starting from the second line is formed by the MS SQL according to its language settings.

The bottom line is that if you don’t want your 1C user to see anything but his native language, you need to secure the following:

  • 1C:Enterprise platform supporting the target language
  • Application translated to the target language
  • Operating system and DBMS working in the target language

 Lesson 5-1 | Course description | Lesson 5-3 

1C:Enterprise Developer's Community