Support for Drupal 8 shipped configuration translatables with external dependencies (in effect contrib)

I just came here from your interesting blog post http://hojtsy.hu/blog/2014-may-19/drupal-8-multilingual-tidbits-15-confi...

So, based on comment #3, this issue has nothing to do with Drupal 8, but only Drupal 6?! I'm sure I'm missing something.

An alternative, I suppose, logically at least, would be to upgrade localize.drupal.org to Drupal 7?

Started working on this in #2309105: Support for Drupal 8 shipped configuration translatables without external schema dependency. That should support extracting shipped configuration translatables from Drupal 8 core.

adding "infrastructure blocker for Drupal 8.0.0" tag, since this blocks the drupal 8 core issue: #2267715: [meta] Drupal.org (websites/infra) blockers to a Drupal 8 RC1, so that the infrastructure blockers to d8 release (in issue queues outside of the core queue) is accurate. Remove the blocker tag when this issue is fixed, and update 2267715.

Trying to get a handle on release blockers prior to 8.0.0 and what (if anything) the community can do to help things along in preparation of https://events.drupal.org/losangeles2015/sessions/plain-drupal-english-g...

Is this still an issue anymore given herom's work in #2309105: Support for Drupal 8 shipped configuration translatables without external schema dependency? If so, could the issue summary be updated with an outline of where to start?

Marking 7.x due to localize.drupal.org getting upgraded to d7.

I just started working on this again.
Here's a WIP patch. It's not ready for review, but it does handle external dependencies for core/contrib modules on a local drupal install.

The remaining work is handling optional dependencies, allowing l.d.o to change part of its behavior (on fetching dependencies), adding comments, and writing tests, hopefully for next week.

Adding a database is a good idea. The problem is that while parsing all modules on l.d.o, a module might be parsed before its dependencies. So, the dependecy's schema in database might be out-of-date. In that case, l10n_server needs to fetch the dependecy's tar.gz and update the schema in database.

Here's a simple scenario:
Module B depends on Module A. Module A has previously released v8.0-1.0, and its schema is extracted and stored in the DB.
Now, both Module A and Module B release a new version. If l10n_server requests parsing Module B before Module A, then when loading Module A's schema as a dependency from DB, the schema would be outdated.

I agree that we need a database, but it should also store version information, and when loading dependecies' schema should check whether a new version is released and update it if necessary.

Well, there is definitely a trade-off between correctness and speed. Unfortunately I don't have any numbers to know how big the trade-off would be (since we are going to extract and update Module A's schema anyway, only later in the process).
Assuming we don't check for latest schema for dependencies, once a module's schema gets updated, some of its dependent modules might not see the new schema and miss a few strings on the first cron run after that. But that will be fixed/propagated on the second cron run.

So, for the sake of moving forward, I will leave that part out; No need for talkback with l10n_server or fetching dependencies' tar.gz files.

Updated the patch to use the database for storing and fetching dependency schemas, which allows simpler integration with l10n_server, per Gábor's suggestion.

There are a few bits of work remaining:

• Handling optional dependencies.
• Single module extraction. Right now, the code needs to find all the dependencies in the given path (basically, the drupal root). So, if the path to a module is given, the shipped config extraction doesn't work.
• Adding comments and explaining the code.
• A few tests.

The code is not ready for review yet. But about the points in #20:
indentations fixed. bad IDE config.
1. fixed.
2. The comment meant that without handling dependencies, there needed to be some basic defaults. Now that dependency handling is implemented, the todo is fixed.

Here's a new patch. Finally ready for review.

Changes since last patch:

• Fixed handling dependencies defined in config files themselves.
• Extracting translatables from a single module using drush is fixed: drush finds other possible locations for the dependency modules in the drupal folder hierarchy.
• Tests are not added, but it's been tested on 50+ real-word cases (core modules), and it's working correctly. Hopefully, someone else can come up with a full test-case for this.
• Fixed handling optional config.

Handling optional config turned out to be harder than I imagined. I added another table (potx_schema_reverse_lookup) to help with that. Since the real owner/provider of an optional config is not explicitly defined, dependency resolution cannot be used there. The real owner module should have been already processed in an earlier run of potx (even locally). Than means, for example to extract all translatable from core, drush potx should be called twice on the /path/to/drupal/core

Fixing test fails. They were mostly from the tests themselves: Bad sequence definition in test schema files, missing .info.yml for test module, missing base /core/config/schema files since default translatable definitions were removed, and a single fail (translatable string "1") which was actually related to yaml translatable extraction (unrelated here) that I disabled.

I successfully achieved to extract labels of custom ECK entities from their exported configuration like this example :

Filename: eck.eck_entity_type.a_sample_eck_type.yml

id: a_sample_eck_type
uuid: 92c9047a-b4bb-468d-8000-e4376b95a7be
label: 'A sample ECK type'

But, I think we're missing hook_update_N() for the newly added tables.

Added hook_update_N()

1. That code is only for dependency resolution. I agree that themes should be added too, but can anything depend on a profile?

2. The database requirement wasn't necessary; it was only added so that integration with l10n_server would be a lot easier (and I incorrectly thought this was something you asked for, hence my comment in #22). The dependecy modules still need to be found though, since config files aren't standalone very much (I assume they are all going to rely on core modules' schemas to some degree).

So, I can remove the database, but add a --dependencies-path=/path/to/modules command-line argument, or require that modules should be parsed inside a working drupal installation with all dependencies to extract their shipped config translatables.

Here is a new patch. It addresses the points in #29, I think.
The database tables are removed, and the way it's going to work with l10n_server is a lot more clear (6 functions to override).

I'll add some information, including what each new global does, and a high-level explanation of how the code works, in 1-2 hours.

I rewrote a lot of the patch, and failed to rebase the old patch on HEAD, so, no interdiffs, sorry.

Added explanation about the new globals to the issue summary. high-level explanation of the code is next ...

Ok, done. Ready for review now.

Committed. Yay!