mrLexndr Multilingualism: Website Translation via GPT

What this solution does

The mrLexndr module translates sites on the 1C-Bitrix platform, covering the interface, information blocks, catalog, SEO fields, and checkout process. Translated text is stored in the database directly alongside the original within the same element, without creating site copies or modifying language files. This allows content managers to edit texts without duplicating information blocks.

The solution works on sites that were not originally designed with multilingual support in mind. Labels from template language files are automatically pulled from the dictionary without rewriting calls, and properties without a language suffix automatically receive language pairs.

The module translates the following content types:

Interface phrases: button labels, menu items, tooltips, layout block text, and email text. Each phrase is registered once and displayed in the visitor's language.

Phrases from language files: all content that templates and components output using the standard GetMessage() function from files in the lang/*.php directory.

Information blocks: names, previews, descriptions, properties and their values, property labels, sections, trade offers, and Highload-block directories.

SEO: title, description, alt, and image title templates for each language, with inheritance by section.

Store: product names and properties on the storefront and in the cart, order properties, payer types, payment system and delivery service names, and units of measurement.

The mrLexndr module ensures the site interface is translated into the visitor's language, displaying search results, breadcrumbs, and month names correctly. The Bitrix core stores payment system and delivery service names as a single text string without dedicated translation fields. The module transfers these entries to a dictionary and translates them as standard phrases, ensuring that the checkout process in English appears entirely in English rather than partially.

There are no limits on text length or formats. Plain strings, such as product titles or button labels, are translated directly. HTML markup used in product descriptions and news articles is preserved intact; the module automatically repairs unclosed tags to prevent page layout disruption.

For the sprint.editor block editor, the field is a JSON structure containing block definitions, which cannot be translated as plain text to avoid corrupting key names. The module processes such fields in a dedicated format, translating only labels, headers, and text values. If the node count does not match the original after translation, the entire record is discarded. Support for this format is included out of the box.

The mrLexndr module enables website translation via GPT without length restrictions. Articles containing up to forty thousand characters are processed in full without being split into fragments. The system optimizes costs by sending identical lines within a batch for translation only once, while lines containing no letters—such as SKUs, numbers, and codes—are not sent at all, eliminating charges for their translation.

Using machine translation is optional. The module functions as a full-featured translation repository even if no budget is allocated for automated translation. Language fields are created, language switching operates correctly, and content substitution on the storefront proceeds as expected. Texts can be filled manually via the item card, dictionary, or through CSV import and export. This approach aligns with projects where translation is performed by an in-house editor or an agency: the module provides structure and tools without dictating the source of the content. Machine translation is engaged only when manual work becomes too time-consuming.

The solution is ready for use on an existing site without requiring template rewrites.

The mrLexndr Multilingual module enables site translation via GPT without altering the existing architecture. If the site previously displayed labels using GetMessage with a code and stored text in lang/ru/*.php files adjacent to the template, the module preserves this scheme. It scans language files in specified directories once, builds a dictionary, and returns translated text from that dictionary when the same GetMessage function is called for selected languages. Editing a phrase in the dictionary immediately updates the text displayed on the site.

The module does not rewrite calls in templates nor delete original language files, allowing a return to the previous behavior at any time. If a template uses an outdated method for connecting a language that cannot be intercepted, the system displays the file name and a ready-made single-line replacement. The module does not insert this replacement into template files automatically, as they remain under the user's control. Matches of codes with third-party files are listed in a separate report: until they are manually resolved, the phrase continues to function in the original mode.

The mrLexndr module provides automatic website translation using artificial intelligence technologies. For information blocks, element names, previews, and descriptions are always translated. Properties are processed based on the presence of a language suffix: if a property is named TITLE_RU, a corresponding pair TITLE_EN is automatically created. If a site was developed without translation support and properties have base names such as BRAND or MATERIAL, they must be marked in the module settings. Once marked, the system will translate all text and list properties, creating pairs with the _EN suffix. Information blocks containing no properties with suffixes are identified by the system automatically.

In the new code approach, text strings are placed directly within templates. This uses a specific function call where the text in the base language is specified as the second argument. Upon the first page display, the phrase is automatically added to the dictionary with the original text. Fields for other languages remain empty, correctly reflecting the status of missing translation and allowing the machine translation system to process these entries accurately.

Layout and programming are performed in Russian as if multilingual support were not required. The site begins functioning immediately upon launch, and the dictionary fills automatically. Decisions to add languages can be made at any time without requiring a separate phase to move all template labels into language files.

Variables are inserted by name to preserve the phrase structure: calling LANG_VAR('DAYS_LEFT', ['COUNT' => 5]) generates the text 'Remaining #COUNT# days'. Fragments assembled from parts in another language are not translated, as the word order differs.

The module does not include copies of standard Bitrix components. Instead, it inserts translations directly into the data received by the component by adding a single line to the template's result_modifier.php file: IblockHelper::substituteStandardFields($arResult). A copy of a standard component functions only until the next core update, after which it must be manually repaired with every update. The shopping cart and checkout process change more frequently than other elements, causing their copies to break most often. Therefore, the module translates the checkout process using events, eliminating the need to modify its template.

If elements are selected manually, the code line is unnecessary: translation is applied automatically during selection.

Translation costs are predictable. The queue tracks changes but does not perform translations itself. Charges are incurred only when you press the button. Consequently, mass synchronization with 1C involving thousands of items does not result in unexpected bills.

mrLexndr is a module for automatic website translation using GPT. Translation is performed field by field: you pay only for the field you edit, such as a title, and do not pay again for the description.

Bulk translation runs in the background. It is started with a single button; the tab can be closed while the status is displayed above the table, showing the progress and current step. Before each paid action, the system checks for the possibility of pausing. The task can be cancelled at any time, and already translated data is preserved. If the service fails to respond in time, the step is deferred rather than marked as an error; the next step uses the ready translation without a duplicate charge.

The option to retranslate already translated items is highlighted in a red banner and requires separate confirmation upon launch, preventing accidental payment for duplicating the entire catalog. Balance and payment history are visible in the admin panel, where funds can also be topped up.

To ensure translation accuracy, a brief project description is sent to the model before each action. This prevents ambiguity, such as the word 'application' having dozens of translation options depending on context. A glossary allows you to define fixed terms that the model uses without alteration, for example: Company in English = About Us, Sberbank = Sberbank.

The mrLexndr module automatically handles AI model rejections. If the model returns a standard refusal, such as a statement about being unable to discuss a topic, which can happen even with harmless texts regarding border queues or customs restrictions, the system makes three consecutive attempts: a standard translation request, a retry with strict phrasing constraints, and a fallback to Yandex Machine Translation. Fields translated by the external service are added to a separate list because the glossary was not applied to them, requiring manual review.

The verification tool detects hidden errors such as broken links, unclosed tags, or truncated text. Standard checks often miss these issues because the original text remains unchanged, leading the system to consider the translation complete even when a significant portion of the content is missing from the page.

Manual editing takes precedence over automation. A translation saved by a human will not be overwritten by the machine queue until the original text is modified.

Content Manager Workflow

Switch the administrative panel language and open a product card. The fields display the translated text, and saving records this translation while leaving the original untouched. A yellow banner at the top of the screen indicates the current mode to prevent confusion.

The mrLexndr module provides website multilingual support using GPT. Phrases output via the LANG_VAR() function can be edited directly on the page: clicking a phrase opens a built-in editor, and the result is immediately visible in the layout. Text length constraints are only visible in the editing mode, as a phrase that looks normal in a list may not fit on a button.

The translation dictionary is exported to CSV and can be uploaded back. You can send a single language to a translator and upload only that column without overwriting data in other columns.

Translated pages are indexed correctly by search engines. The search bot receives a ready-made HTML page with translated text; no content is swapped via scripts in real time or overlaid on top of the original.

Title and description templates are translated separately for each language, preventing language versions from competing in search results. Macros {=this.name} and {=this.property.CODE} automatically insert translated values. If the model loses a macro during translation, the template is not saved. Hreflang markup and the sitemap file are configured using standard Bitrix tools.

The mrLexndr Multilingual module uses a single external address, api.mrlexndr.com. Communication with this service occurs only during translation, viewing the balance screen, or topping up the account. No requests are sent from public site pages to the service.

The translation request includes the text strings to translate, target languages, format, selected engine, glossary, site description, and domain. The balance request contains only the Bitrix license hash and domain. There is no telemetry: visitor data, visit statistics, installation details, and site content other than translatable strings are not transmitted externally.

Setting up keys for Yandex or Google is not required. The site is identified by the Bitrix license hash, and keys are stored on the service side, making it impossible to extract them from the module settings. The service address is verified against a list of allowed hosts, preventing configuration substitution and the transfer of the license hash to an unauthorized server.

All operations that modify data are performed via the POST method with session token and write permission checks. Background translation verifies the permissions of the user who initiated the process, rather than running as the system. Service console scripts are not included in the delivery. All translations remain the property of the user.

Module removal is performed via a wizard with mandatory confirmation. Translated data is never deleted regardless of settings: the dictionary and status table remain intact. Since this is content rather than service data, it cannot be restored from an external source. If the module is reinstalled, the translations will be available without re-translation and without a second payment. The checkbox on the first step of the wizard, enabled by default, controls the module settings themselves: the language list, glossary, site description, and selected engine.

Translations are stored in standard Bitrix objects, not in a proprietary format. Data is kept in language properties of elements (such as NAME_EN, PREVIEW_TEXT_EN), custom section fields, and a highload block containing the dictionary. These data can be read via the standard Bitrix API even without the module installed.

The module does not modify template language files. After removal, GetMessage() calls automatically revert to the original texts from those files. Only calls to LANG_VAR() and IblockHelper within templates remain in the project code. Removing them restores original Russian values while the site continues to function correctly. If this dependency is undesirable, it is recommended to create a custom wrapper function; in this case, the module name will be known in only one project file. A separate documentation page covers this scenario.

For developers

The mrLexndr module provides website multilingualism using GPT. The public interface includes LANG_VAR(), Lang::get(), and IblockHelper. For cases where phrase codes come from data rather than templates, Lang::peek() is available to read values without auto-creating entries, preventing dictionary clutter.

The system implements approximately twenty-five event handlers. The 'Stand Check' screen runs a comprehensive diagnostic with a single click, verifying the presence of handlers, database schema integrity, and configuration consistency. It also displays an installation passport containing the module, PHP, and database versions, the module directory path, available Bitrix modules, supported translation languages, and the status of scheduled agents. Missing handlers do not generate explicit errors but cause the queue to stop filling.

Custom components function identically to standard ones: translations are seamlessly inserted into the element array already assembled by the component.

Documentation is available in a dedicated section on the developer's website. It covers the entire range of topics, from initial installation to the internal structure of the SEO storage and a complete list of module messages.

Environment Requirements

PHP version 8.2 or newer is required. This is a strict requirement because part of the module classes are declared as readonly, a syntax construct that did not exist prior to version 8.2.

The mrLexndr module provides website translation powered by artificial intelligence, integrating with core Bitrix components including the main module, Highload blocks, Information blocks, and the Online Store module. To translate phrases from language files via the GetMessage() function, the main module version 23.0.0 or newer is required. The module can be installed and function on older core versions, but the phrase interception feature will remain disabled.

The service requires an outgoing secure connection to the translation service. In the absence of a network, the local dictionary and manual translation substitution on the storefront continue to work, while automatic machine translation becomes unavailable.

The module does not support sites where language versions are implemented outside of standard Bitrix languages, such as through separate folders or domains without language binding. In such cases, the system will serve the same language across all pages.

Ready-made solutions based on the Aspro template are not currently supported. Aspro implements multilingualism through a multi-site architecture, and its template resides in the /bitrix/templates/ directory, where updates overwrite necessary files, preventing the persistence of changes in result_modifier.php. Users with Aspro templates should contact the developer before purchasing.

Text entered directly into templates without using GetMessage(), as well as JavaScript phrases (BX.message), are not processed by the module. Direct editing of text on the website page is only available for LANG_VAR() variables.

The supported translation engines are Google Gemini and Yandex. DeepL is not supported.

Re-translating already translated text fully replaces it, including any manual edits; previous versions are not preserved and can only be restored from a backup.

Machine translation is charged from the balance based on actual usage. No quota purchases or minimum top-ups are required. Translating a site with a thousand products into one language via Google Gemini costs from 500 rubles. The balance can be topped up with a card directly within the module interface. For invoicing, please contact support.

A demonstration of the module on a live test environment is available before purchase, including answers to questions about your project. The module translates the Bitrix site interface, information blocks, catalog, SEO fields, and checkout forms. Translated data is stored in the database alongside the original within the same element, without creating site copies or language files. Duplicating information blocks is unnecessary, and text editing is available to content managers.

The following interface phrases are translated: button labels, menu items, tooltips, layout block text, and emails. Each phrase is registered once and displayed in the visitor's language.

The mrLexndr module provides translation for infoblock content including titles, previews, descriptions, properties and their values, field labels, sections, trade offers, and Highload-block catalogs. SEO settings allow templates for title, description, alt, and image title attributes on each language with inheritance by section. In the store section, product and property names on the catalog and in the cart, order properties, payer types, payment system and delivery service names, and measurement units are translated. Users of the English version see search results, breadcrumbs, and month names in their language.

The Bitrix core stores payment system and delivery service names as a single text string without dedicated translation fields. The module moves these entries to a dictionary and translates them as standard phrases, ensuring that the checkout process in English appears entirely in English rather than partially. There are no limits on text length or formats. The module distinguishes three content types and handles each differently. Plain strings such as product names, button labels, or short fields are translated directly. For HTML content like product descriptions or news text, the markup is returned intact. Unclosed tags are automatically repaired regardless of settings to prevent page layout breakage.

The mrLexndr Multilingual: site translation via GPT module is designed for page builders, specifically for the sprint.editor field, which is a JSON structure of blocks. Direct translation of this field as plain text is impossible as it would corrupt key names and service values. The module processes data in a special format, translating only labels, headings, and text content. If the node count does not match the original after translation, the entire record is cancelled. Support works out of the box with no additional configuration required.

There is no limit on the length of translatable text: articles up to forty thousand characters are processed in full without splitting. The batch size affects only the number of elements sent in a single request. Duplicate strings within a batch are sent once, while strings containing no letters (such as SKUs, numbers, and codes) are not sent at all, eliminating unnecessary costs.

Using machine translation is optional. The module functions as a full translation repository even without machine translation. Language fields are created, language switching works correctly, and substitution on the storefront proceeds as standard. In this scenario, texts are filled manually via the element card, dictionary, or CSV import/export.

The mrLexndr Multilingual: site translation via GPT module by developer mrLexndr implements a localization approach similar to that of an in-house editor or agency. The system provides structure and tools regardless of the text source. Automatic translation is activated only when manual processing becomes too time-consuming.

Developers can write text directly within the template code without needing to pre-extract phrases into language files. The source text is specified as the second argument of the LANG_VAR function. Upon the first page render, the phrase is automatically added to the dictionary with the provided text, while fields for other languages remain empty. This accurately reflects the status of missing translation, and these specific fields are selected by the machine translation system.

The primary benefit is the ability to design and program in Russian as if multilingual support were not present initially. The site functions from the first minute, the dictionary populates automatically, and decisions regarding additional languages can be made at any time once texts are collected in one place. There is no separate phase required to move all template labels into language files.

Variables are inserted by name to preserve the integrity of the phrase. For example, calling LANG_VAR('DAYS_LEFT', ['COUNT' => 5]) generates the record '5 days left'. A construction where translatable parts are concatenated with a variable using the dot operator, such as LANG_VAR('LEFT') . $n . LANG_VAR('DAYS'), is not translated because word order differs in other languages. The translator processes only the complete phrase. When the same code appears multiple times on a page, it results in a single database query rather than multiple ones.

If the project already uses Bitrix language files, the module automatically imports them. It scans the /local/templates, /local/components, and /local/php_interface directories, collects all $MESS arrays, and adds entries for new codes to its dictionary. Existing codes are skipped to prevent overwriting data. Old language files can remain in place; as long as the template calls $MESS, it continues to read them, allowing for a gradual migration without a single risky step.

The module does not include copies of standard Bitrix components. It does not replace components with its own versions but inserts translations directly into the data received by the component. This requires adding a single line to the template's result_modifier.php file: IblockHelper::substituteStandardFields($arResult).

The mrLexndr module provides website translation using GPT. Copies of standard components function until the next core update; after an update, restoring them requires intervention by the developer who implemented the module. The shopping cart and checkout process change more frequently than other elements during version updates, so their copies are the first to break. The module translates checkout events, eliminating the need to modify templates entirely. When elements are selected manually, translation is applied automatically during selection without adding code lines.

Translation costs are predictable. The task queue records changes but does not perform translation independently. Charges are deducted only when the button is pressed. This prevents unexpected costs during mass data exchange with 1C involving thousands of items. Data comparison occurs per field: if only a title is changed, payment applies only to the title, while unchanged descriptions incur no charge.

The Stop button is verified before each paid action. It halts both background jobs and browser-based processes, even if the tab has been closed. Translation resumes from the same point after stopping. Balance and operation history are visible in the admin panel, where account top-ups are also managed.

Before each translation, the model receives project context consisting of several sentences about the website. Without this context, the word 'application' can be translated in a dozen different ways depending on neighboring words. The glossary defines terms that the model does not select but uses exactly as specified by you: for example, [EN] About Us = About Us, Sberbank = Sberbank.

The module automatically handles model refusals. Sometimes instead of a translation, the response is 'I cannot discuss this topic,' which can occur on harmless texts about border queues or customs restrictions. In such cases, the module makes three consecutive attempts: a standard translation, a retry with a strict formulation, and a machine translation via Yandex Translate. Fields translated by the machine are placed in a separate list because the glossary was not applied to them, and they require manual review.

Verification detects corrupted translations, such as lost links, unclosed tags, or truncated text. Standard checks never notice these issues because the original content has not changed, so from their perspective everything is translated correctly, even though half the text may be missing on the page.

Manual editing is more effective than machine processing. A translation saved by a human will not be replaced by the machine translation queue.

How the content manager works with this

The mrLexndr Multilingual module enables website translation via GPT. When switching the admin panel language and opening a product card, fields display the translated text; saving records only the translation while leaving the original untouched. A yellow banner at the top indicates the current mode to prevent confusion.

Interface phrases can be edited directly on the website page: clicking a phrase opens a small editor, and the result is immediately visible in the layout. Text length is visible only in this context, as a phrase that looks normal in a list may not fit on a button or may break the grid in a narrow column.

The translation dictionary can be exported to CSV and re-imported. Users can export all languages, send a single language column to a translator, and upload only that column without overwriting the others.

Translated pages are indexed correctly. Search engines receive a ready-made HTML page with translated text; no content is swapped via scripts in real time or overlaid on the original.

Title and description templates are translated separately for each language, ensuring language versions do not compete in search results. Macros {=this.name} and {=this.property.CODE} insert translated values; if a model loses a macro during translation, the template is not saved. The hreflang markup and sitemap file are configured using standard Bitrix tools.

Security: What leaves your server

The only external address accessed by the module is api.mrlexndr.com. Requests contain only the strings to be translated, selected languages, format, the chosen engine, glossary, project context, and the site domain. The module contains no telemetry. Visitor data, visit statistics, installation details, and site content are not transmitted outside, except for the strings being translated. Until translation is initiated, the module makes no external requests.

There is no need to configure Yandex or Google keys on the site: the site is identified by the Bitrix license hash, and keys are stored on the service side, so there is nothing to steal from the module settings. Any actions that modify data are performed via POST with session token and write permission verification, preventing unauthorized changes through links in emails. Service console scripts are not included in the delivery.

All translations remain your property.

The module is removed via a two-step wizard. Translations are never deleted: the dictionary and status table remain intact. This is content, not service data, and cannot be restored from elsewhere. If you reinstall the module, the translations will be preserved, so you will not need to pay for them again. The checkbox on the first step of the wizard, enabled by default, controls the removal of module settings: the language list, glossary, context, and selected engine.

Translations are stored in standard Bitrix objects, not in a proprietary format. This includes language properties of elements (NAME_EN, PREVIEW_TEXT_EN), custom section fields, and a Highload block containing the dictionary. These data can be accessed via the standard Bitrix API even without the module installed.

After the module is removed, calls to LANG_VAR() and IblockHelper remain in the project templates. Removing them restores the original Russian values while the site continues to function. If this dependency is undesirable, create your own wrapper function: in this case, the module name will be known in only one project file. A separate documentation page covers this scenario.

For developers

The public interface of the module includes the LANG_VAR(), Lang::get() functions, and the IblockHelper class. A standard practice is to hide the module behind a wrapper so that project code does not reference its name; this scenario is described in detail in a separate documentation section.

For cases where the phrase code comes from data rather than a template, and there is no need to pollute the dictionary, the Lang::peek() method provides reading without auto-creation.

The module contains approximately twenty-five event handlers. The Stand Check screen displays their status and generates an installation passport: module version, PHP version, installation directory, available modules, target languages, and the status of scheduled agent execution. If a handler is missing, no explicit error is generated; the queue simply stops filling.

A custom component functions identically to the standard one: the translation is automatically inserted into the array of elements that the component has already collected.

Full documentation is available in a dedicated section on the developer's website. It covers the entire process from initial installation to the internal structure of the SEO storage and lists all module messages.

Environment Requirements

PHP version 8.2 or newer is required. This is a strict requirement because part of the module classes are declared as readonly classes, a feature that does not exist in versions prior to 8.2.

The mrLexndr module operates with the main and Highload blocks of Bitrix. For translating information blocks, it uses the "Information Blocks" component, and for the store catalog, it uses the "Online Store" component.

Connection to the translation service is established via the HTTPS protocol. Dictionary functions and manual translation substitution on the storefront work offline, while automatic machine translation requires an internet connection.

Language Version Limitations

The module functions correctly only when using the standard Bitrix language structure. If language versions of the site are implemented via separate folders or domains without binding to system language settings, the module will display the same language on all pages.

Supported Translation Engines

The module integrates with Yandex and Google Gemini. DeepL support is not available.

Template Integration

To enable the module, a call line must be added to the template of the standard component. The documentation does not provide ready-made recipes for commercial builds such as Aspro, as the working principle is independent of the template, while the exact insertion point depends on the specific template version you are using.

Important Warning

Enabling the overwrite function for existing translations is an irreversible action. Data recovery is possible only from a backup.

Pricing and Payment

The module costs 99,990 rubles. Machine translation is paid separately from the user's account based on actual usage. Purchasing quotas or making a minimum top-up is not required. Translating a site with a thousand products into one language via Google Gemini costs approximately from 500 rubles. Balance top-up is performed directly within the module interface using a bank card.

mrLexndr is a module for multilingual support on Bitrix sites that uses GPT for automatic translation. A demonstration on a live test stand is available before purchase to review the module's functionality and discuss your project specifics.

The module translates the interface, information blocks, catalog, SEO fields, and checkout forms. Translated text is stored in the database directly alongside the original within the same element, eliminating the need for site copies or language files. This approach removes the requirement to duplicate information blocks and allows content managers to edit texts directly.

Interface phrases are translated, including button labels, menus, tooltips, layout block texts, and emails. Each phrase is registered once and displayed in the visitor's language.

Information blocks are fully translated, covering titles, previews, descriptions, properties and their values, property labels, sections, trade offers, and Highload-block directories.

SEO fields include title, description, alt, and image title templates for each language, with inheritance support by section.

The store is fully translated, including product and property names on the storefront and in the cart, order properties, payer types, payment system and delivery service names, and measurement units.

Search results, breadcrumbs, and dates are also localized. A visitor on the English version sees search results and month names in English.

The Bitrix core stores payment system names and delivery service names as a single text string for all languages, without dedicated fields for translation. The mrLexndr module transfers these entries into a dictionary and translates them as standard phrases. Consequently, the checkout page in English appears entirely in English rather than partially translated.

Using machine translation is optional. The module functions as a complete translation repository even if no budget is allocated for automated translation. Language fields are created, language switching works correctly, and content substitution on the storefront operates as expected. Texts can be filled in manually via the element card, the dictionary, or through CSV import and export. This approach aligns with projects where translation is handled by an in-house editor or a specialized agency: the module provides the structure and tools without restricting the source of the text. Machine translation is enabled only when manual work becomes too time-consuming.

Developers can write text directly in the code. There is no need to pre-export phrases into language files. Text in the base language is written directly in the template as the second argument of the LANG_VAR function, for example: LANG_VAR('SUBMIT_BTN', 'Submit request').

On the first page render, the phrase is automatically added to the dictionary with the original text. Fields for other languages remain empty, which honestly reflects the absence of a translation; these empty fields are exactly what the auto-translation system targets for filling.

This allows developers to design and code in Russian as if multilingual support were not present. The site functions from the first minute, the dictionary populates automatically, and decisions about adding languages can be made at any time once texts are collected in one place. There is no separate phase for moving all template labels into language files.

Variables are inserted by name to keep the phrase intact: LANG_VAR('DAYS_LEFT', ['COUNT' => 5]) generates the record "#COUNT# days left". Concatenation like LANG_VAR('LEFT') . $n . LANG_VAR('DAYS') is not translated because word order differs in other languages; the translator sees the complete phrase only. Using the same code twice on a page results in a single database call, not two.

No copies of standard components are included in the package.

The module does not replace Bitrix components with its own copies. It injects translations directly into the data received by the component using a single line in the template's result_modifier.php file.

The mrLexndr module provides website translation using GPT. Standard fields are injected via the IblockHelper::substituteStandardFields($arResult) function. Unlike copies of standard components that require manual repair after every core update, this module translates the checkout process through events. This eliminates the need to modify cart and checkout templates, which often change between versions and break when copied. If items are selected manually, translation is automatically applied during selection without additional code lines.

Translation costs are predictable due to queue operation. The queue records changes but does not perform translation independently. Funds are deducted only when the user presses the button. This prevents unexpected charges during mass exchange with 1C involving thousands of items. Data comparison occurs per field: if only the title is changed, only the title translation is charged, while the description is not billed again.

The Stop button is verified before each paid step. The process halts both in the background and during browser execution, even if the tab is closed. Translation resumes from the same point after stopping. Balance and operation history are visible in the admin panel, where account top-ups are also managed.

Before each translation, the model receives project context consisting of several sentences about the website. Without this context, the word 'application' can be translated in a dozen different ways depending on neighboring words. The glossary defines terms that the model does not select but uses exactly as specified by you: for example, [EN] About Us = About Us, Sberbank = Sberbank.

The module automatically handles model refusals. Sometimes instead of a translation, the response is 'I cannot discuss this topic,' which can occur on harmless texts about border queues or customs restrictions. In such cases, the module makes three consecutive attempts: a standard translation, a retry with a strict formulation, and a machine translation via Yandex Translate. Fields translated by the machine are placed in a separate list because the glossary was not applied to them, and they require manual review.

Verification detects corrupted translations, such as lost links, unclosed tags, or truncated text. Standard checks never notice these issues because the original content has not changed, so from their perspective everything is translated correctly, even though half the text may be missing on the page.

Manual editing is more effective than machine processing. A translation saved by a human will not be replaced by the machine translation queue.

How the content manager works with this

The mrLexndr Multilingual module enables website translation via GPT. When switching the admin panel language and opening a product card, fields display the translated text; saving records only the translation while leaving the original untouched. A yellow banner at the top indicates the current mode to prevent confusion.

Interface phrases can be edited directly on the website page: clicking a phrase opens a small editor, and the result is immediately visible in the layout. Text length is visible only in this context, as a phrase that looks normal in a list may not fit on a button or may break the grid in a narrow column.

The translation dictionary can be exported to CSV and re-imported. Users can export all languages, send a single language column to a translator, and upload only that column without overwriting the others.

Translated pages are indexed correctly. Search engines receive a ready-made HTML page with translated text; no content is swapped via scripts in real time or overlaid on the original.

Title and description templates are translated separately for each language, ensuring language versions do not compete in search results. Macros {=this.name} and {=this.property.CODE} insert translated values; if a model loses a macro during translation, the template is not saved. The hreflang markup and sitemap file are configured using standard Bitrix tools.

What leaves your server

The only external address used by the module is api.mrlexndr.com. The request includes the text to be translated, target languages, format, the selected engine, glossary, project context, and the site domain. Visitor data, visit statistics, and site content other than the translatable strings are not transmitted externally.

There is no need to configure keys for Yandex or Google: the site is identified by the Bitrix license hash. All operations that modify data are performed via the POST method with session token validation and write permission checks. Service console scripts are not included in the delivery package.

For developers

The public interface consists of LANG_VAR(), Lang::get(), and IblockHelper. It is standard practice to hide the module behind a custom wrapper so that project code does not know its name; a separate documentation page covers this scenario.

Read operations without automatic creation are also available via Lang::peek(). This is used when the phrase code comes from data rather than a template, and there is no need to clutter the dictionary.

The module utilizes approximately twenty-five event handlers. The 'Stand Check' screen displays their status and generates an installation passport containing the module version, PHP version, source directory, available modules, target languages, and the status of scheduled agent execution. If a handler is missing, no error is thrown; the queue simply stops filling.

A custom component functions identically to the standard one: the translation is inserted directly into the array of elements that the component has already assembled.

Documentation is available in a dedicated section on the developer's website. It covers the entire process from initial installation to the internal structure of the SEO storage and a complete list of module messages.

Requirements

PHP 8.2 or newer. This is a strict requirement because part of the module classes are declared as readonly classes, a feature that did not exist in versions prior to 8.2.

Bi Modules

For “mrLexndr Multilingualism: Website Translation via GPT”, General iT can perform integration, configuration and a final check after installation.