No ways to configure module-relative path for included module translation .po files

I proposed a fix for this in the MR, please review. If it's okay, I can extend the tests to check this feature.

Have not reviewed yet but MR should be pointed at 11.x

thanks!

Reworked MR to the 11.x branch, please review.

murz → closed merge request !9936

Thanks for reporting, think next step would be to get test coverage added.

liam morland → made their first commit to this issue’s fork.

Another approach would be to make a %project_root token available for use in interface translation server pattern.

Hi,
I'm in the same situation, and MR !10167 works perfectly for my modules.

Note that — though I'm not sure if it's considered best practice — I'm experiencing the same issue with my themes as well.
Would it be possible to extend this fix to themes too?
Just for reference, I tested the following code on my project (based on the MR), and it works as expected:

    // Check for the `theme://` prefix in the translation server pattern and
    // replace it to the current module path.
    if (
      isset($data['info']['interface translation server pattern'])
      && str_starts_with($data['info']['interface translation server pattern'], 'theme://')
    ) {
      $themePath = \Drupal::service('theme_handler')->getTheme($name)->getPath();
      $data['info']['interface translation server pattern'] =
        str_replace(
          'theme://',
          $themePath . '/',
          $data['info']['interface translation server pattern']
        );
    }

Thanks!

@johnatas, good point about themes! So, maybe let's use a more general term extension:// instead of module/theme then? Because, as I see in the Drupal Core, both modules and themes are named with a general term "extension" in functions, that work with both types.

Another approach would be to make a %project_root token available for use in interface translation server pattern.

In the context of the Drupal installation with many modules, the %project_root usually means the Drupal installation root, not the module/theme root directory. And for that, we already have the default behavior, which searches for files from the Drupal root.

So, I think extension:// would be the best name for this.

@murz,
Yeah, that approach sounds good to me.
Now that I think about it, would this also make it possible to extend the functionality to profiles as well?
If needed, I can work on a patch with this approach in the next few days.

Yes, profiles, as I suppose, are a subset of extensions too. @johnatas, and yeah, would be great if you can update the MR, cuz I want too, but too busy with other urgent tasks :(

And seems it's better to switch to the service "extension.path.resolver" and use the method ExtensionPathResolver::getPathname(string $type, string $name) but there we have to know the extension type again, it looks like the first idea with having "module://", "theme://" and "profile://" was good :)

I’ve updated the merge request with the "extension" approach.
It works for both modules and themes.

However, it’s much more complex for profiles and theme engines, since using ProjectInfo()->processInfoList() isn’t possible in those cases.

Having never created a custom profile or theme engine myself, I’m not sure if they would even be concerned by custom translation handling?
It would be a shame to invest a lot of effort unnecessarily ;)

Looks good to me, thank you! So, the last step seems is to write tests.

About theme engines and profiles, I don't see cases when they can need translations, and profiles seems to be replaced by recepies, so I believe we can go as you've done now.

Hi @murz,

Sorry for the delay — I’ve just rebased the branch, which fixed the failing test jobs.
Is that what you were referring to? Or were you talking about writing new tests for the new code?

Thanks.