>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #1933988. --> Reported by: [gábor hojtsy](https://www.drupal.org/user/4166) >>> <p><span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/potx/issues/2309105" title="Status: Closed (fixed)">#2309105: Support for Drupal 8 shipped configuration translatables without external schema dependency</a></span> solved extracting default config strings which do not have external dependencies (only use types that they define). That would in practice only work for core. Any contrib module would not work. We still need to solve the problem of parsing configuration where some schema is defined outside of the project being parsed (ie. in external dependencies). Because schema is not versioned, potx will need to store some version(s) of the schema of those projects and parse dependencies of projects to be able to handle configuration parsing.</p> <p>More prior discussion of this at <a href="http://drupal.org/node/1648930#comment-6845334">http://drupal.org/node/1648930#comment-6845334</a> and above.</p> <p>An overview of the code is given here.</p> <ul> <li>At potx start, all available modules are found in the local system, based on Drupal 8's directory structure.</li> <li>During yaml parsing, some metadata is gathered about modules, including module dependency list, config schema files, ...</li> <li>Parsing shipped configs happens at a different pass, and works as follows:</li> <li>First, process the schemas in <code>/core/config/schema</code>. All data types and base definitions exist there.</li> <li>Then, process the schemas for the given module, which includes finding its dependencies and processing them, recursively.</li> <li>Each config file could include its own dependencies. In that case, process them too, but keep it isolated so that it doesn't affect other configs' parsing.</li> <li>For optional config, the whole processed schema should be rebuilt for each config file, since their owning module might be different.</li> <li>Finding the shipped config translatables itself isn't modified here, and involves traversing the config file based on its matching schema.</li> </ul> <p>List of new defined globals:</p> <ul> <li><code>global $potx_callbacks</code> contains the list of functions that should be overriden by l10n_server to allow using a database, and not require extracting the dependency modules themselves.</li> <li><code>global $_potx_module_metadata</code> contains metadata about the modules that are being parsed by potx. Right now, it includes the module's dependencies, and the list of config files (schema, install, optional) in the module. This might later be used for similar dependency resolution in yaml translation extraction too.</li> <li><code>global $_potx_processed_schema</code> contains all the processed schema required for parsing a shipped config file. This might include schema from the module, its dependencies, the real owner (in case of optional config), and the module dependencies in the shipped config itself.</li> <li><code>global $_potx_processed_modules</code> tracks the list of processed modules, so that we don't process a module's schema multiple times.</li> <li><code>global $_potx_module_schema</code> contains the processed schema for a single module. This can be cached, or stored in the database, for using later.</li> </ul> <p>The following globals are defined in <code>potx.local.inc</code>:</p> <ul> <li><code>global $_potx_found_modules</code>: when parsing a module locally, potx should try to find its dependencies in the local file system, based on the Drupal 8 directory structure. The <code>global $_potx_found_modules</code> global holds the list of main directories that can contain modules, e.g. <code>core/modules</code>, <code>themes/</code>, <code>sites/all/modules</code>.</li> <li><code>global $_potx_schema_lookup</code>: When parsing optional config in a module, the module itself might not contain the config's schema. Instead, potx should look through all modules to find a matching schema. To makes this faster (and possible), a lookup table is created from all config matching keys in schema (e.g. block.block.*) and their corresponding modules.</li> <li><code>global $_potx_reverse_lookup_built</code>: Since creating the lookup table is expensive, it isn't built until an actual optional config is parsed. This global is used to track when it's built. Come to think of it, I can probably get rid of this ...</li> </ul> > Related issue: [Issue #2559711](https://www.drupal.org/node/2559711)