Region names are not extracted from theme info files

Realized I created this issue long ago in the wrong project, so I'll be closing #2806065: Theme region names are not making it into PO database as a duplicate of this one. Doh!

That looks like a good test!

Hm. Regions is not like the other keys in that translation patterns file, in that it is an array.

So, looking at what happens in _potx_find_yaml_translatables() in potx.inc, for arrays in YAML... let's see. In either the test info.yml file or in the Bartik yml file, we have something like this:

regions:
  header: Header
  primary_menu: 'Primary menu'
  secondary_menu: 'Secondary menu'

So in the code, it does this, basically [my comments added and a bunch of code removed for simplicity]:

foreach ($yaml as $key => $value) {
  // See if $key is in the translatable list -- which is TRUE for 'regions'. 
    if (in_array($key, $trans_list['keys'], TRUE)) {
       // Figure out the context [code omitted]
       // Save the value as translatable if it's not an array.
      if (!is_array($value)) {
        $save_callback(addcslashes($value, "\0..\37\\\""), $context, $file_name);
      }
   }
...

And then there is a recursive call to the same function if $value is an array, but at that level, the keys are things like 'sidebar_first' and those will not match the keys in the translatable list.

In other words... What we want here is "Extract values for all the keys underneath regions". But that is not what the code does.

Here's a proposed fix... It is already possible in a yaml_translation_patterns.yml file to specify

    top_level_translatables: true

at the file level, and also it is possible to specify a context for each translatable key.

So what I've done is to add the possibility of specifying something similar to top_level_translatables for each key.

Let's see what happens...

Invalid YAML, whoops. How about this? Should also probably fix the coding standards warning.

whoops, that's not quite right either. Need to think about the logic a bit more.

OK, I think this even simplifies the logic a bit. I canceled the other test.

One more fix. Should hopefully take care of the coding standards warnings in the lines touched by this patch, plus fix the test fail maybe/hopefully.

Sorry for all the sloppiness. This patch might fix the last test fails hopefully...

OK, here's a new patch that reorganizes the logic and is hopefully clearer, plus might work this time. :)

Probably I should have installed the module and run the tests on my own machine... oh well.

OK, it's green, with no coding standards violations! Time for an actual review.

Yes, the problem is that the region names for the theme, which are used on the Block Layout page as well as the Regions Preview page that you can see in the screenshot on this issue... Those region names are not being extracted by the POTX string extractor, so they are not on localize.drupal.org to be translated. Some of them are on there because they have been used in PHP code elsewhere in Drupal Core, but not all. This patch should fix the problem, so that the translation teams can translate those terms.

Bump... I added a patch about 6 weeks ago. What can we do to move this forward?

I don't see why this issue would prevent you from translating the User Guide into German. It's only affecting one screenshot.

True, this is a problem for translating the user interface, but I think it only affects a few pages of the User Guide where blocks are being placed in regions.

Here's an attempt at porting the patch. The code for D7 and D8 looks pretty similar, so I basically just copy/pasted stuff from the D7 patch and put it in the equivalent spot in D8... let's see what the bot says (I'm not on my D8 dev machine so I didn't run the test) -- I included the test changes in the patch.

It was close, but not identical. The patch didn't apply, even with "fuzz". But it was easy to figure out where to copy/paste things and how to change one variable name.

The tests pass on the d8 port.