[Ibochkarev]

Follow-up to #662, from the review comments on that pull request.

Summary

All four remarks on en/extending-modx/internationalization.md are addressed. The Russian page follows.

1. The syntax of the tag

The example of a placeholder was written as

[[!%userinput=`amazing`]]

which is not a valid tag. The parser splits a tag on the first ? (core/src/Revolution/modParser.php:406), so without it the value stays part of the name — modLexiconTag would look for an entry called userinput=amazing``. The old example of the page had the same defect in the namespace property, where the name was written as namespace\_name: the backslash is not an escape in the syntax of a tag, so the namespace was looked up with the backslash in it.

The example is now

[[!%key? &userinput=`amazing`]]

2. The optional properties

The topic and the language can be left out — the topic falls back to default, the language to the one of the request. The namespace falls back to core as well, so it has to be given for a lexicon outside the core namespace; without it the tag looks in the core only (core/src/Revolution/modLexiconTag.php, getContent()).

3. The topics of the JavaScript connector

The page states that connectors/lang.js.php takes a comma-separated topic parameter. The basis is now named: the connector reads $_REQUEST['topic'], splits it by commas and loads every coordinate with modLexicon::load(). The templates of the core ask for the topics the same way — manager/templates/default/header.tpl requests ?ctx=mgr&topic=topmenu,file,resource,….

4. The lexicons of the settings

The label of a setting is the key setting_<key>, and its description is setting_<key>_desc. The core keeps its labels in the setting topic (core/lexicon/en/setting.inc.php, 540 entries), a Component outside the core namespace keeps them in the default topic — that is also the topic the manager writes a translated label into, because modSystemSetting::updateTranslation() picks the topic by the namespace of the setting (core/src/Revolution/modSystemSetting.php:41).

The Settings grid loads both topics of the namespace of the setting (core/src/Revolution/Processors/System/Settings/GetList.php:121-128), so a key with the setting_ prefix is found in either of them.

Also

The example of modLexicon::load() is rewritten: every argument is a coordinate, there is no separate parameter for the namespace ($topics = func_get_args()).

The description of the frontmatter of both locales is quoted, and the stray quote at its end is gone.

Checks

• markdownlint-cli@0.18 (the version used by CI): 0 issues
• EN/RU parity: the same headings, the same code blocks and the same tables
• The links of both pages resolve

[Mark-H]

Where does this concept of manually including /connectors/lang.js.php to load extra lexicon topics from? That's the biggest issue still present. That's how core works yes but not how people extending modx should be loading their lexicons.

[Ibochkarev]

You are right, and the page no longer tells the reader to call the connector.

Where the concept comes from. connectors/lang.js.php?topic=… is the manager's own mechanism: the header of the manager page asks the connector for the topics of the page (manager/templates/default/header.tpl:23 — ?ctx=mgr&topic=topmenu,file,resource,{$_lang_topics}), and the connector reads $_REQUEST['topic'], splits it by commas and loads every coordinate with modLexicon::load(). The response replaces MODx.lang.

How a Component does it. The page declares the topics and the manager loads them:

• a controller names them in getLanguageTopics() — core/src/Revolution/modManagerController.php:533; the core controllers override it (controllers/default/context/index.class.php:70 returns ['context']);
• a page that needs a topic beyond those of its controller adds it with addLexiconTopic() — modManagerController.php:1027.

Both load the topic and put it into _lang_topics, which the header hands over to the connector. The order works out: prepareLanguage() runs at the start of render(), and process() runs before the header is rendered (modManagerController.php:162,180,203).

The page now says that a Component does not call the connector itself — the manager does. The Russian page follows.

[Jako]

I have added a comment about loading the lexicons with the lang.js.php

[Jako]

To add multiple lexicons, the parameter of getLanguageTopics can contain an array of topics instead of a string.

[Ibochkarev]

Fixed — the example returns a list now, and the page says that the method returns the list of the topics of the page:

public function getLanguageTopics()
{
    return ['mycomponent:default', 'mycomponent:settings'];
}

The code behind it: modManagerController::prepareLanguage() takes the return value of getLanguageTopics(), loads every topic of the list with modLexicon->load() and hands the list over to the header of the page through _lang_topics. The core controllers use the list the same way — for example return ['user','access','policy','context','setting']; in the controller of a user group.

One detail worth knowing, since the wording can be read both ways: every element of the list has to be a string with one topic. A nested array would not work — modLexicon::load() skips everything that is not a string, and implode(',', $languageTopics) would flatten it with a notice.

The Russian page follows.